My use case
PLease could you advise what is missing?
Hi @VatslauX,
If you have changes in the configuration, and are only using terraform apply -refresh-only, then you are never applying those changes. The -refresh-only flag means you want to only update the current state to match the values read by the provider. You must plan and apply without -refresh-only in order to apply any additional changes.
I repeated with next order:
terraform plan -refresh-only -out=tfplan -no-color
No changes. Your infrastructure still matches the configuration.
Terraform has checked that the real remote objects still match the result of your most
recent changes, and found no differences.
terraform apply tfplan - no changes
> terraform apply tfplan
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
terraform plan - old changes still detected
Plan: 10 to add, 5 to change, 0 to destroy.
Unless I’m misunderstanding what you are trying to do, you need to remove the -refresh-only in order to apply changes to want. This example still uses the -refresh-only flag, which tells terraform not to apply any changes from the configuration.
apply will push local changes(pulled before) to remote server again.
I don’t need to create same objects on remote server.
I need just to accept all changes into local state without any real actions.
Sorry, I don’t understand what you are trying to do here. If your goal is just to update the state to match the real objects, then what you are doing with -refresh-only is correct. If you have changes you want to apply to those objects, then you can’t use -refresh-only.
If you are looking for something else, then you will have to create a more complete example showing what exactly that is.
Let me add some details.
I have high mutable configuration (Dynatrace)
And it is leads that it will a lot of changes on remote via UI admin or even automatically by vendor.
This leads the traditional model of work with Terrafrom when you have state (local or remote) as the source of true - is not valid.
The state is an arbitrary backup wich needs to be updated after review from relal remote changes which will in conflict with state.
I am looking for workflow
How to update state with accepting changes without invoking provider with will indeed try to push difference back to server
Then a plan using -refresh-only will give you a way to review the changes between the saved state and the most recently read state from the provider.
If the the state of the remote resources diverges from the configuration because of these outside changes, then any plan without -refresh-only is going to try and revert those changes. There is no real other workflow for this, because Terraform’s goal is to ensure the real state matches the desired state defined by the configuration.
Maybe I am misleading the documentation
but this flow:
This won’t modify your real remote objects, but it will modify the [Terraform state](State | Terraform | HashiCorp Developer).
And this I am expecting.
state should be modified without real actions.
And terraform shows me that.
terraform apply tfplan - no changes
> terraform apply tfplan
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
But plan again to detect changes,
for me looks like a bug when the state was not really modified.
If those changes contradict what is in the configuration, then yes, a plain terraform plan will always show those changes regardless of whether the stored state is updated or not. The configuration is the “desired state” which Terraform wants to achieve, so anything which does not match that configuration can result in a change in the plan.
The only way to do this would be to continue to use -refresh-only, however that obviously prevents making any further changes from Terraform. By allowing changes outside of Terraform, Terraform no longer can be responsible for those changes, and effectively no longer manages those resources.
If the possible attribute changes are reasonably small and known ahead of time, you could add ignore_changes to the applicable attributes in the config, which would prevent Terraform from trying to revert those.
Thank you!
I will need to rethink about this strategy looks like it can be a workaround for me