Change resource after configuration without apply

Im creating a resource that I need to provision with SSH and then move to different network. It is possible to change network interface in the config file and then terraform apply, and my resource will be modified. Is it possible to perform this step with out manually changing in the config file? Perhaps with some null-resource??

Hi @e.felding,

The main idea of Terraform is that you describe a desired state and that if the desired state changes over time you would change the configuration to reflect that, and so I think generally-speaking the answer to your question is no and you may be better to seek a different solution to meet this requirement.

However, “change the configuration” can potentially mean something other than literally editing .tf files. Those files really serve as a program for generating the configuration that Terraform will use, and so there are some other ways to cause Terraform to see a different desired state even though the source files are unchanged. For example:

  • If you declare an input variable in your root module then you can assign it a different value for each run. That means you can in theory have a variable that you’ll override on your initial run to select the initial bootstrapping state, and then run again without overriding that variable to converge on the “stable state” that you will use once the system is running.
  • You can use a data source to generate a different desired state based on the state of some other object that is managed elsewhere. This means that you can get a similar effect to the previous point but put the flag about initial bootstrapping in some network-accessible service, rather than directly in the planning options, and then change that setting once you have completed the bootstrapping process and are ready to converge on the stable state.

Some people with requirements similar to yours choose to use Terraform as only a part of the solution, making use of its ability to integrate with remote APIs and converge on a desired state but wrapping it in some other custom scripting which then takes the responsibility for changing the desired state over multiple runs using mechanisms like what I described above. In that case Terraform will be just an implementation detail of your automation rather than something to be run directly, but for some situations it can still be simpler or more reliable than programming the underlying APIs directly.