Ordering issue when deleting config store linked to compute service

[joeshaw]

Terraform Version

Terraform v1.6.4 via Terraform Enterprise

Affected Fastly Terraform Resource(s)

Please list the affected resources, for example:

• fastly_service_compute
• fastly_configstore

Expected Behavior

I have a compute service which has a resource link to a config store. In a tf update, I am unlinking the store and deleting it. I expect that the service would be updated first to remove the link, then the config store would be deleted.

Actual Behavior

The config store is attempted to be deleted first, and errors because there is an existing link to a service.

I think the issue is a lack of an implicit dependency between the service and the resource.

Steps to Reproduce

1. Create a config store resource (not sure if this also applies to KV or secret stores)
2. Add some entries to the config store
3. Create a compute service
4. Link the resource to the compute service
5. Delete the resource link, config store entries, and config store. Try to apply the plan, and you should get an error as it tries to delete the resource before updating the service to remove the resource link.

[kpfleming]

That's going to be tricky, because the Config Store can't be deleted until after the new service-version (which does not reference it) has been activated. It's not sufficient to just clone the 'active' service-version and remove the Config Store link; that service-version has to be made inactive before the existing link will become inactive itself.

[jmoney]

FYI i'm noticing the same issue in a PR i've written but for compute@edge acls: #972

the last bit i have is if i remove the fastly acl in the same terraform apply as removing the resource block, terraform tries to delete the acl before the service and it needs to be the other way around, update the service before removing the ACL

[kpfleming]

There cannot be an automatic dependency between the resource block for the store (Config Store, KV Store, ACL, etc.) and any service, because the store can be used by multiple services, including services not managed by Terraform. As a result, Terraform may choose to modify the service and delete the store simultaneously, or modify the service after deleting the store.

If your configuration is such that you can guarantee that the store is only used by services in the same Terraform configuration, you can use the depends_on meta-argument to explicitly tell Terraform of the dependency. Configuring the store to be dependent on all services which have links to it will cause Terraform to make all changes to those services (including activation) before making any changes to the store. You will need to ensure that the list in the depends_on meta-argument is kept synchronized with the services that have resource links to the store.

[kpfleming]

After thinking about that some more, I suspect that the addition of depends_on would have to be done only when the store is going to be deleted; having depends_on in the store's resource block while there are resource links to it in service resource blocks would create one or more circular dependencies. I can't think of a simple solution to this problem.