-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MoveState clarification and removed+import blocks alternative #1058
Comments
Hey there @lantoli 👋🏻 , thanks for filing the issue! I'll try to answer each question:
Yeah the There is a related issue on the Terraform core side about configuration of providers that you might be interested in (a lot of it I'm pulling over here): hashicorp/terraform#35922
I believe that would work in the exact same way as
I don't know the exact technical detail behind why
I think that's a good idea to add to our docs, I'll mark that down to get that added to our next release. Overall, I think the missing piece from your request that we can't solve on the provider side is the |
thanks @austinvalle for your answers. Can you confirm if we should expect the same behavior in HCP (Terraform cloud offering) and TFE (Terraform on-premise offering)? About hashicorp/terraform#33474, do you know if there is any estimate? This is critical for us. |
No problem!
Yes I would expect the same to be true (refactoring operations running before the initial refresh) regardless of where your provider is executed. ATM, I can't think of any gotchas or caveats for HCP or TFE that would be a concern here.
I don't know anything about the status of that unfortunately 🙁 |
Module version
go list -m github.com/hashicorp/terraform-plugin-framework/...
github.com/hashicorp/terraform-plugin-framework v1.13.0
Use-cases
Here at MongoDB we want to help customers migrate easily from an old resource type to the new resource type. It's important to note that many of the customers have these resource inside modules. Also they often have some security restrictions that prevent them from using Terraform commands that change file state directly such as "terraform state rm" or "terraform import".
Attempted Solutions
We have some resources in TPF, but these resources are in SDKv2, not in TPF yet. One solution would be to migrate the destination resource to TPF and implement MoveState. This will work but we'll need to introduce some breaking changes in the destination resource because the SDKv2 to TPF migration.
About MoveState, the transformation logic we need to do to go from the old resource schema to the new one is complex. Doing some tests we've found that
Read
is called in the destination resource just afterMoveState
(Read is probably called because the new resource being declared in the Terraform files) so the state written in MoveState is overwritten by Read. Can you confirm that we can skip doing the transformation logic, and just read the identifiers from the source schema and set them in the destination to set the attributes to identify the resource soRead
can later fill the destination state? (the state must be valid, e.g. all values have to be known or null, but we've found that it's ok to use somefake
values except for the id attributes as the state will be filled correctly by Read).Another solution would be to use a combination of
removed
andimport
blocks so we don't need to upgrade resources to TPF. Can you confirm if this would be a valid alternative to MoveState? One issue we've found is thatimport
can not be used inside modules.Proposal
Allow use of
import
block inside modules. A problem we've found is that import can only be used from root module, do you know why this restriction exists? Would it be possible to improve Terraform to allow import inside module code? For instance removed and moved blocks work fine inside a module, don't know why import doesn't.We get this error: "An import block was detected in "module.atlas_basic". Import blocks are only allowed in the root module"
However we can do the same thing having the import block in the the root module, importing the resource inside the module, problem is that this has to be done in each module client code, instead of the import block being centralised in the module code:
Also we propose to clarify
MoveState
doc to explain the MoveStat / Read operations and there is no need to do a full transformation logic provided this is working as in our assumptions.Thanks.
References
The text was updated successfully, but these errors were encountered: