Azure / Azure-Verified-Modules

Azure Verified Modules (AVM) is an initiative to consolidate and set the standards for what a good Infrastructure-as-Code module looks like. Modules will then align to these standards, across languages (Bicep, Terraform etc.) and will then be classified as AVMs and available from their respective language specific registries.
https://aka.ms/AVM
MIT License
317 stars 65 forks source link

[Question/Feedback]: Terraform Lifecycle - Ignore Changes #667

Open Dipak-Mistry-WTW opened 6 months ago

Dipak-Mistry-WTW commented 6 months ago

Check for previous/existing GitHub issues

Description

Pretty sure this is going to be a no but is there any way of being able to add lifecycle ignore_changes into the module so we can specify a list when calling the module?

matt-FFFFFF commented 6 months ago

Hi,

The lifecycle block must be added to the resource by the module author.

Are you able to give an example of the use case you're looking for?

Dipak-Mistry-WTW commented 6 months ago

We have a third party solution that applies a set of tags based upon region, cost centre, and a multitude of other tags for internal reporting. This solution also adds our worldwide office IP addresses to all resources that support networking like storage and key vault. For example, in our current modules all resources that support tagging and firewalls have:

  lifecycle {
    ignore_changes = [tags["internaltag1"], tags["internaltag2"], tags["internaltag3"], tags["internaltag4"], tags["internaltag5"], tags["internaltag6"], tags["internaltag7"], network_acls, ]
  }

Currently whilst trying to use the AVM It's trying to delete the values that have been populated by the other means. Is there any way we could pass through blocks within the lifecycle blocks on resources. I know that the lifecycle block only supports literal values as per lifecycle block but I am hoping that someone really clever has come up with a stateful workaround and I could pass into the module a block that would populate the module's lifecycle block.

tarunfeb27 commented 4 months ago

I would also like to request to add as an input possibility (lifecycle ignore_changes) in the modules in general. The tags could be a common requirement for several modules as tags may be applied via inheritance from resources groups/azure policies. An example of a tag(very commonly used ) is: created_on = formatdate("YYYY-MM-DD hh:mm:ss ZZZ", timestamp()) Which is IMO important to ignore.

There would be other cases where ignore_changes is required but would case by case, i.e. ignoring customer_managed_key rotation of resources, ignoring ssl_certs in application gateway etc.

A user controlled list for this would be a great help.

mbilalamjad commented 4 months ago

@matt-FFFFFF just double checking on the next actions on this one before it could be closed

wesleykey commented 4 months ago

Agree that the ability to pass a list of tags to ignore would be useful. When Azure Policy is used to apply tags at the resource group level which filter down to resources, the plan flags the tags as changes making large plans more difficult to interpret.

ronak-agarwal commented 4 months ago

We have similar requirements where we use azure policy DeployIfNotExist to create private endpoints entry in DNS zones, so we would like to ignore below in all AVM modules like Storage Account, Key Vault etc

lifecycle { ignore_changes = [ private_dns_zone_group ] }

matt-FFFFFF commented 1 month ago

We have similar requirements where we use azure policy DeployIfNotExist to create private endpoints entry in DNS zones, so we would like to ignore below in all AVM modules like Storage Account, Key Vault etc

lifecycle {

ignore_changes = [

  private_dns_zone_group

]

}

This has been fixed in the Key Vault module and now our recommended guidance for module authors. Please raise issues on each module if this hasn't changed.

matt-FFFFFF commented 1 month ago

It's not possible to have the ignore changes block populated by variables. It must be static.

Hence it's not possible to implement a user defined list of attributes to ignore. Until this changes upstream in TF then there's nothing we can do I'm afraid.