[fix](modules/vmseries): added lifecycle ignore_change for boot_disk

[jochristian]

Potential fix for #49

Description

To fix the issue with image change I haved added a lifecycle ignore_changes = [boot_disk.0.initialize_params.0.image]
for the vmseries module.
While might be solved in a better way. I have not found any better ways now.
As already known referencing a module does not currently support lifecyle options,

Motivation and Context

Changing the image variable for a newer version of PANos should NOT destroy what has already been created by terraform. This will fix this issue

I can't see any reasons why this should be an part of the module.
Why would you want terraform to destroy an already created infrastructure using this module?
And if this is what you really want the destroy should be done with changing some other variables (region, number of vm's etc).

How Has This Been Tested?

I tested in my own environment where I changed my current PANos image to something else.
With this fix terraform does not destroy any already created vm-series created.

Screenshots (if appropriate)

Types of changes

lifecycle was added in the vmseries modules under google_compute_instance.

Checklist

• I have updated the documentation accordingly. Not sure how this can be documented?!
• [ x] I have read the CONTRIBUTING document.
• [ x] I have added tests to cover my changes if appropriate.
• [ x] All new and existing tests passed.

[pavelrn]

@jochristian What is the solution for the users, that would like to re-deploy VM-Series when the disk image changes?

[jochristian]

@jochristian What is the solution for the users, that would like to re-deploy VM-Series when the disk image changes?

Well you could do a terraform destroy? Since this is what will actually happen with the "old" solution?

My question is. What is the solution for users that want this to be solved:
You have a huge deployment, but you want to keep the VM-Series that is already deployed.
But at the same time you want to create new VM-Series but with the new image. Currently this is not supported since terraform will destroy what has already been deployed.

[pavelrn]

Well you could do a terraform destroy? Since this is what will actually happen with the "old" solution?

-destroy is usually used to destroy everything, that is likely undesired. The use of -destroy step might be complicated if you are running Terraform from the pipeline.

What is the solution for users that want this to be solved

You can use a local copy of the module with the lifecycle block, until Hashicorp comes with a better solution like applying lifecycle block with some conditions.
We will also discuss internally if adding lifecycle with ignore_changes = [boot_disk.0.initialize_params.0.image] is something that should be in the module by default.

[jochristian]

Well you could do a terraform destroy? Since this is what will actually happen with the "old" solution?

-destroy is usually used to destroy everything, that is likely undesired. The use of -destroy step might be complicated if you are running Terraform from the pipeline.

What is the solution for users that want this to be solved

You can use a local copy of the module with the lifecycle block, until Hashicorp comes with a better solution like applying lifecycle block with some conditions. We will also discuss internally if adding lifecycle with ignore_changes = [boot_disk.0.initialize_params.0.image] is something that should be in the module by default.

Yes, that is what we did previously.
But this introduces "technical debt", keeping the modules updated when you release new updates.

So yes, local modules is of course a solution. But we would prefer to use the modules that Palo Alto keeps updated.
Of course we lock our modules with

module "vmseries" {
source = "PaloAltoNetworks/swfw-modules/google//modules/vmseries"
version = "2.0.10" <<<---

So we don't loose control on new changes :-)
Regarding terraform and support for this. This has been a feature request for several years already.
"Not holding my breath"

[jochristian]

@pavelrn

After thinking some more about this.
There is one thing that would force redeployment off the VMseries. And that is changing the name of the VM.
Maybe creating something around that, would be a feasible way to fix this in environments where you want to do a redeployment when changing the image? But at the same time also have lifcecycle for the boot disk.