Add support for targeted applies on import blocks only

[eric-at-cmd]

Terraform Version

N/A

Use Cases

• Currently when using import blocks one must do a plan and an apply in order to import the resource into State.
• Challenge I have is that if a developer has created a resource manually and wants to import it my preference is to use an Import block so that the applies on prod infrastructure can go through pull request approvals, linting, lower environments etc.
• Currently in many of our repos if you want to use import blocks you need to define them, submit PR for approval, merge and then do it again once the CICD process has done the terraform apply to import the resources.
• Don't want a bunch of unnecessary import blocks sticking around in the codebase after they have executed so would prefer that import blocks do not stick around permanently.
• Would be good to have the optional of targeting applies specifically for import blocks that can be a reusable CICD action.
• Using targeted applies just for the imported resources is not feasible if trying to do it through pipelines.

Attempted Solutions

• Its possible to do a targeted apply only on the imported resources but this is not feasible for doing this via pipelines.

Proposal

No response

References

No response

[jbardin]

Hi @eric-at-cmd,

Thanks for filing the issue. Can you explain further, perhaps with an example, what you are suggesting here? You are asking for targeted applies for imports, but then follow up saying that it is already possible but not feasible.

In order to plan and apply the import, there needs to be some sort of configuration given. The legacy import command does this by accepting a simple tuple of name and id as arguments, but that has many limitations which is why the configuration driven approach was adopted. After a resource is imported, the import blocks are no longer active in the configuration and can be removed at any later time. This can often be handled via a temporary file dedicated to the imports which could even be cleaned up as part of an automated process.

[eric-at-cmd]

Thanks @jbardin what I want is effectively be able to execute the import blocks in a file without actually applying any changes into the resources that file is declaring.

An example of why this would get used is sometimes a developer might replace or add new non-root EBS volumes on EC2 Instances and then want to bring those resources into Terraform State.

Currently with how we're set up if we were going to do this via import blocks someone would need to:

1. Checkout a new branch
2. Add import blocks for the new resource
3. Create Pull Request and request a review
4. Merge it and then a terraform apply will be done through either gitlab ci or github actions

Sometimes can end up with difficulty getting the green-light to get the apply performed, most of the time it's not an issue but some stakeholders can be really resistant to running a terraform apply which can change infrastructure just to effectively update the state file.

The legacy terraform import command is used in some cases on my end because of this, it would be a lot easier to be able to use import blocks and be able to give people the peace of mind that it will not modify their infrastructure as part of doing that.

[jbardin]

The intent with most of the operations in Terraform is that apply is the operation which updates the state. This specifically allows for the inspection of the plan before the changes are made, to ensure that no unexpected changes are going to be made. The first thing that comes to mind here is to have a policy that allows plans which only contain import changes to have a faster review or bypass that process.

Because a plan has to be created and applied, what would be the desired workflow for your import scenario?

[eric-at-cmd]

While I acknowledge working this way probably isn't optimal its still something that comes up for us sometimes.

The issue with the current way it works is that for some stakeholders it is challenging to get approval to do this apply because the intention is to update the state so that it matches the deployed infrastructure. Yet, it is done through the same operation that can execute destructive changes.

A lot of the time its not an issue, but being able to tell someone "This command has no capability of destroying or modifying any of your infrastructure" is a big help in communication to these stakeholders. Having it also justifies adding it as a Standard Change in a CAB for organisations that operate like that.

Because a plan has to be created and applied, what would be the desired workflow for your import scenario?

I'd say workflow wise it'd be the same as you'd expect from any plan/apply its just that it will only run import commands and not execute any changes, adds, or removes.

[jbardin]

Thanks for the extra info @eric-at-cmd. I'm not sure what Terraform would do to satisfy the stakeholders in this case. In order to use import blocks you will need to complete a plan, and the command to apply a plan is always apply. The apply command can only do what was outlined in the plan, so policy decisions will always come down to checking the actions in the plan.

Even if a special plan flag to limit changes only to import actions were added, it would still require inspecting the plan to verify it was created with the options claimed. For example, one option here might be for Terraform to include import actions with -refresh-only. The user could then create an import plan via terraform plan -refresh-only -out planfile which would not modify any resources and only update the state. That is still a "normal" plan file however, and if approval is required there is no difference in the process, one needs to inspect the plan to make sure it only contains import actions.

If the users are already allowed to run ad-hoc commands, then you are already trusting the user to not run anything destructive, and perhaps terraform plan -refresh-only would suffice?

[rhysxevans]

So I have a similar issue, however I think a refresh-only type option would probably cover my use case

Essentially I need to

1. Import all resources as is
2. This may lead to drift, however at import time there are no changes
3. This means any new resources can go out and be manged va ths code
4. I could then work with relevant teams, to work out relevant change windows to apply the actual change, where the drift has occured

I hope I have understood the request and the proposed, solution correctly