Has anyone ever seen `terraform plan -out=p && terraform apply p` do something that wasn't visible in the plan?

[Tim Visher]

Has anyone seen or even heard of `terraform plan -out=planfile && terraform apply planfile` taking actions that weren't visible in the plan?

Note *not* `terraform plan && terraform apply -auto-approve`. Specifically the application of a previously generated plan _file._

Thanks in advance!

--

In Christ,

Timmy V.

https://blog.twonegatives.com
http://five.sentenc.es

[Bartosz Dopke]

Hi there,

Yes, I did. For example it was something which was not implemented yet in Terraform but did exist on Microsoft Azure.

Terraform didn't handle (or still does not handle) snapshot policy for NetApp Volumes. Therefore, when policy was attached to volume in a portal, every change in a code was deleting it not showing a change in a plan.

[Tim Visher]

Hi Bartosz,

On Mon, Apr 12, 2021 at 4:37 AM Bartosz Dopke <bartos...@gmail.com> wrote:

Yes, I did. For example it was something which was not implemented yet in Terraform but did exist on Microsoft Azure.

Terraform didn't handle (or still does not handle) snapshot policy for NetApp Volumes. Therefore, when policy was attached to volume in a portal, every change in a code was deleting it not showing a change in a plan.

 Just to be sure I'm understanding what you're describing here:

1. You declared an Azure resource in terraform. The provider didn't expose a particular property of the resource. We'll call this unexposed_A_resource
2. You applied the resource (thus creating it in Azure)
3. You updated the resource in the Azure console to modify the unexposed property to be what you wanted it to be.
4. You updated an _unrelated_ resource in your terraform code. We'll call this unrelated_B_resource.
5. You ran a plan, saving it to a file, that showed an update to unrelated_B_resource and nothing else.
6. You ran an apply, and terraform claimed to run an update on unrelated_B_resource _and_ unexposed_A_resource, destroying your console modification to unexposed_A_resource in the process.

Do I have that right?

Or are you saying:

1. …
2. …
3. …
4. You updated a terraform managed property of unexposed_A_resource
5. You ran a plan that showed that it would modify the terraform managed property of unexposed_A_resource but _didn't_ mention the console managed property of unexposed_A_resource.
6. You applied the plan and it claimed to modify unexposed_A_resource and you then discovered that the console managed property of unexposed_A_resource had been modified

Or are you saying something else?

FWIW scenario 2 would be unsurprising to me. Many resources are exposed as simple maps and are updated with a PUT that destroys anything not in the PUT. There's nothing the provider can do at that point other than document the behavior.

Scenario 1 would be _very_ surprising to me. :)

[Bartosz Dopke]

It went like that:

1. I created netapp volume in a terraform code without assigning snapshot policy to it (not available in Terraform).

2. I attached a snapshot policy to it in Azure Portal.

3. I did a change in netapp volume in a terraform code not related to snapshot policy (change touched export policy rules).

4. Terraform plan showed that only thing in netapp volume which will be changed is export policy rules.

5. After terraform apply, the result is that export policy rules are changed and snapshot policy association has been deleted.

[Stuart Clark]

On 13/04/2021 09:43, Bartosz Dopke wrote:
> It went like that:
>
> 1. I created netapp volume in a terraform code without assigning
> snapshot policy to it (not available in Terraform).
> 2. I attached a snapshot policy to it in Azure Portal.
> 3. I did a change in netapp volume in a terraform code not related to
> snapshot policy (change touched export policy rules).
> 4. Terraform plan showed that only thing in netapp volume which will
> be changed is export policy rules.
> 5. After terraform apply, the result is that export policy rules are
> changed and snapshot policy association has been deleted.
>

That does sound fairly expected.

Presumably the API call used to edit the export policy rules also
controls the snapshot policy, so when Terraform called that API with the
new settings it did not include the snapshot policy details (as
Terraform knows nothing about that feature) causing Azure to remove it.

If the APIs worked differently (separate calls for snapshot & policy
settings) this wouldn't have happened. The only real fix is for
Terraform to start supporting the config for snapshots, otherwise every
time you run an apply that does some other change to the volume it will
be deleted (if the plan doesn't need to touch the volume for other
reasons you are safe).

--
Stuart Clark

[Tim Visher]

On Tue, Apr 13, 2021 at 4:43 AM Bartosz Dopke <bartos...@gmail.com> wrote:

It went like that:

1. I created netapp volume in a terraform code without assigning snapshot policy to it (not available in Terraform).

2. I attached a snapshot policy to it in Azure Portal.

3. I did a change in netapp volume in a terraform code not related to snapshot policy (change touched export policy rules).

4. Terraform plan showed that only thing in netapp volume which will be changed is export policy rules.

5. After terraform apply, the result is that export policy rules are changed and snapshot policy association has been deleted.

Wonderful. Then all remains right in the world.

That is unfortunate for you but it still leaves my mental model of how terraform works intact. :)