Best way to upgrade/migrate provider state when merging resources

I wish to know if there is an elegant way to upgrade state when two resources are to be merged? The way I understand state upgrades, is that it is a per-resource process.

My current train of thought is:

  • have the “child” resource save its state into the providers private state, be marked as depreciated, and never show any plan diffs.
  • have the “parent” resource read the saved data from the provider private state and incorporate it into its new attribute that has taken over the job of the old “child” resource
  • next major release remove the old “child” resource

I have never worked with the private state and hope it is “cross resource available”, however this all feels a bit “hacky”, is there a better way to do this?

Private state is per-resource, it’s “private” in the sense that Terraform does not attempt to interpret or change the data it contains.

If the configured resources you want to combine are really part of the same real-world resource, there must be some data in the desired final resource which can identify the object in its entirety. You may not even need to really “merge” anything, so long as you can read all the necessary information from the remote API, just make sure the combined resource has the minimal data necessary to make the remote API calls.

You are completely right, I think I am going code blind, not sure why I thought I had to pass info between them when I can and already do read the info from the API. Thanks hehe :sweat_smile:

Btw the private provider data, that could be shared between resources by having it be, or contain a pointer so all resources would end up reading the same memory space right? Not that I need it anymore, but its good to understand how it works.

There is no shared memory between Terraform and the providers. The private data is just raw bytes (bytes in the protobuf, []byte in Go) that are transferred and stored with the resource instance, which can be interpreted however the provider wants.

That’s not to say the provider can’t internally store things about instances it’s previously seen, but that only works within the one provider process used during a single phase of Terraform’s execution, and must rely on the configuration to ensure that the resources are seen in the order you expect.