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
Add support for bulk imports #22227
base: main
Are you sure you want to change the base?
Add support for bulk imports #22227
Conversation
I should probably write tests for this before it is merged, but I'd like feedback on what I have first. |
In general, this feature would be much appreciated! It's a proposal that's been spotted on the backlog before, and I imagine it will help a lot of users onboarding to Terraform, so thank you! Agree that tests (and documentation for terraform.io) are good to add before merging this. website/docs/import/index.html.md would be a good spot for such docs, and since this adds options, something in usage: website/docs/import/usage.html.md I hope @apparentlymart will pardon a tag on this since he has ideas surrounding this, and likely more feedback, so that this ends up on a path towards something we merge, but I'll put some of the thoughts discussed here so you might respond @tmccombs :) Martin pointed out* that the approach of zero arguments reading from standard input can be confusing for users. In general, Terraform (the software) tries to give feedback on what it expects to do, or error if it can't, and that sort of approach (immediate feedback). A prior proposal (not on GitHub) suggested that users define a file that would be used to define the resources to import, and this was an example:
If your current approach was modified from reading lines of standard input to reading a file with the following information, ideally with a flag pointing to the file, that seems more in line with the Terraform approach:
For example:
Where file is something like this in the first pass:
But would be more understandable in another format, most likely, so that the file (
|
The idea of using HCL for this was coming from some broader ideas around import, such as being able to import by more than just a single string id (instead, arguments similar to data sources) and resolving the fact that right now there's no way to give Terraform any information during import about dependencies, and so imported objects can later fail to destroy properly due to incorrect ordering. However, I'm open to moving forward with something that just directly addresses this one problem (performing a set of import operations all at once with a single, atomic state write); the other parts of this have bigger design questions associated and so it would be a shame to block solving this aspect of it on having to resolve the bigger problems. With that said, this would be my suggestion for how to move forward here:
|
Thanks for the feedback. I will change it to use a seperate flag, and add some documentation and tests. |
I've added documentation and a unit test. |
I changed the import format to use JSON instead, because I realized there are resource ids that contain spaces, and I didn't want to re-invent a new escaping mechanism. |
Is there anything blocking this on my side? I realize approvers are busy, but want to make sure this isn't getting held up because I missed something. |
Requesting @apparentlymart's thoughts :) |
cc4e4d3
to
b9f0e14
Compare
@tmccombs could you rebase?
In such a case you could write |
well, that was more difficult than I would have hoped, but it has been rebased. |
I now think a better approach for this might be to support an I'll see if I can put together a PR. |
@tmccombs FYI: https://github.com/apparentlymart/terrafy, especially you can checkout the https://github.com/apparentlymart/terrafy/blob/main/docs/quirks.md. |
See also: #30015 |
21394f9
to
4daeeed
Compare
Hi all, Pull request #30015 is pretty similar. Many thanks. |
Fixes #22219