I have a provider that needs to trigger replication on the backend server if any of its resource types change.
I have been looking at performing this with a specific resource, however it would need to be daisy-chained to all the other resources declared by the provider (this could potentially be hundreds) and as such maintaining this depends_on list is error prone.
Is there a better way of doing this with the sdkv2?
I was also wondering if this would be something that would be sensible to add to the (StopProvider) flow of a hybrid sdkv2/plugin-go provider? Also is the StopProvider called when both muxed servers are stopped (i.e all resources have been processed by both)?
I think hashicorp/terraform#2430 is tracking this feature request. I’m pretty sure StopProvider isn’t really meant for this. It’s called when Terraform would like the provider to stop whatever it is that the provider is doing. This does not necessarily mean completion, or successful completion, of the resources in question.
In your case, it may make sense to make replication triggering a field on every resource, and trigger replication after every create/update/delete. It may make sense to make the replication configuration a provider-level field and trigger replication after each change, treating each change as atomic (as Terraform does).
I was afraid you were going to say about the provider depends_on, that’s certainly been something that’s been on the wish list for awhile.
Doing the replication after every resource isn’t really ideal for my use case (long story). The biggest problem is making part of a single apply. Even if support for provider scoped depends_on was added I suspect it would still need multiple plan/applies to pick up the change required.
It would be nice if there was a means of adding some sort of hooks to various parts of the lifecycle for a provider (what i hoped StopProvider could have provided) - is it worth adding a feature request for this?
This is a thing we hear a lot, and are definitely thinking on and trying to figure out. I think hashicorp/terraform-plugin-sdk#63 is where we’re tracking those conversations at the moment. @apparentlymart has a really good explanation in there as to why this is trickier than it may appear.