3

I am trying to apply lifecycle ignore_changes rule against parameter in resource resource "aws_servicecatalog_provisioned_product" as shown below.

resource "aws_servicecatalog_provisioned_product" "example" {
  name                       = "example"
  product_name               = "Example product"
  provisioning_artifact_name = "Example version"

  provisioning_parameters {
    key   = "foo"
    value = "bar"
  }

  provisioning_parameters {
    key   = "key2"
    value = lookup(var.parameter_group, "key2", "test2")
  }

  provisioning_parameters {
    key   = "key3"
    value = "test3"
  }

  tags = {
    foo = "bar"
  }

  lifecycle {
   ignore_changes = [
    tags["foo"],
    aws_servicecatalog_provisioned_product.provisioning_parameters.example["key2"]
   ]
 }
  
}

variable parameter_group {
  description = "Parameters map required for modules. 
  type        = map(any)
  default     = {}
}

when i am running the plan i am getting below error

│ Error: Unsupported attribute
│ 
│   on modules/example_provision/main.tf line 28, in resource "aws_servicecatalog_provisioned_product" "example":
│  28:        aws_servicecatalog_provisioned_product.provisioning_parameters.example["key2"]
│ 
│ This object has no argument, nested block, or exported attribute named "aws_servicecatalog_provisioned_product".

I would like to ignore the changes made to this parameter value. The Ignore on tags is working fine but as soon as i add my second line which is aws_servicecatalog_provisioned_product.provisioning_parameters.example["key2"] the error starts to come in.

looking for suggestion/help here :)

Regards

Mahi
  • 343
  • 1
  • 6
  • 19
  • 2
    I don't think you need the entire resource name, rather the argument whose value will be ignored, i.e., instead of `aws_servicecatalog_provisioned_product.provisioning_parameters.example["key2"]` it should be only `provisioning_parameters`. – Marko E Sep 26 '22 at 15:58
  • @MarkoE Comment --> answer. – Matthew Schuchard Sep 26 '22 at 17:02
  • hi @MarkoE thanks for your suggestion but by this way any further changes to any parameter will be getting ignored, i would like to have a dynamic way to handle this only for a specific parameter – Mahi Sep 26 '22 at 18:44

2 Answers2

8

ignore_changes can only ignore changes to the configuration of the same resource where it's declared, and so you only need to name the argument you wish to ignore and not the resource type or resource name:

  lifecycle {
    ignore_changes = [
      tags["foo"],
      provisioning_parameters,
    ]
  }

The provisioning_parameters block type doesn't seem to be represented as a mapping (the provisioning_parameter blocks don't have labels in their headers) so you won't be able to refer to a specific block by its name.

However, the provider does declare it as being a list of objects and so I think you will be able to ignore a specific item by its index, where the indices are assigned in order of declaration. Therefore in your current example the one with key = "key2" will have index 1, due to being the second block where Terraform counts up from zero:

  lifecycle {
    ignore_changes = [
      tags["foo"],
      provisioning_parameters[1],
    ]
  }
Martin Atkins
  • 62,420
  • 8
  • 120
  • 138
  • thanks for suggestion, since multiple developers will be working on the same file. Do you think if we can have some solution of dynamic reference to the provisioning_parameters this would be preventing any error if the position of parameter is changed by a manual error – Mahi Sep 26 '22 at 18:51
  • If you can't predict statically which of the elements is the one to ignore then I think your only option will be to ignore the entire list of objects. There is no mechanism for making a dynamic decision about what to ignore. – Martin Atkins Sep 27 '22 at 17:37
3

And, to expand on Martin's answer:

if you're looking to ignore all possible changes to some resources you could use:

  lifecycle {
    ignore_changes = all
  }

But have to caution you of 2 implications..

  1. terraform will ignore all changes to your resources hence it could potentially ignore the change that you want. I'd normally use this when I work on subset of resources in my module and don't want to be distracted by any other changes that might get triggered.

  2. lifecycle block does not work as part of module block, only on individual resources.

OlegG
  • 927
  • 9
  • 11