Clean up provider resource meta once done

[pegerto]

Hi all,

What is the best way of closing resources in a provider after the provider end? Take for example a provider that uses a client that requires a Close(), I want to connect during configure and close at the end of the execution of the provider.

Is there any prefered way? or introduce a closeFn at the schema.ProviderResource sounds interesting?

Thanks

[pegerto]

Thanks for the labeling @apparentlymart

[jessefarinacci]

This would be valuable to me as well. There are several actions my custom provider should take when terraform is done, but before it exits, such as remote close of client resources created during ConfigureFunc. Any advice? Thanks!

[apparentlymart]

At present there is no way to do this. Once Terraform is finished with a provider, it just sends it a signal to shut it down. While on some platforms it would in principle be possible to intercept that signal and take some action based on it, I believe (IIRC) that on Windows there is no such opportunity, and so in practice this approach is not feasible.

To address this would require a new RPC function between Terraform Core and the provider which can be used as an alternative to the signal-based approach used today. I believe we tried this during the v0.12 development cycle (while we were changing the plugin protocol anyway) but found some technical challenges that required further investigation. I don't have those details to hand right now, but hopefully we can dig them up in future when it's time to think about this problem some more.

Our plugin protocol versioning strategy would allow this to be only a minor (non-breaking) protocol change if we implemented it as follows from the perspective of Terraform Core:

• Try to call Close (or whatever we decide to call it) via RPC.
• If the response indicates success, just wait for the provider process to exit and then terminate.
• If the response is a "not implemented" error, that indicates an older plugin that doesn't support this mechanism; in that case, send the same signal we're sending today to shut it down the old-fashioned way, with no opportunity for cleanup.

It's important to note that if this feature is implemented it should only be used for undoing any actions that were taken in ConfigureFn. It may also seem attractive to use it to implement other functionality, such as an explicit "commit" of various staged operations, but that would not be an appropriate model for that sort of thing because the contract for resource type implementations is that they are ready to use as soon as the Create or Update method returns. You can see some more discussion about these other use-cases in #63.

[paddycarver]

I believe this is a duplicate of #63. I'm going to close it to track the discussion there. If you believe this is in error, please reply to this issue with more information and we can reopen while we investigate. Otherwise, please subscribe to #63 for updates on this topic.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.