Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bridged resources are not replaced when a nested property is updated on a collection with ForceNew #2753

Closed
VenelinMartinov opened this issue Dec 16, 2024 · 2 comments
Labels
kind/bug Some behavior is incorrect or out of spec resolution/by-design This issue won't be fixed because the functionality is working as designed

Comments

@VenelinMartinov
Copy link
Contributor

VenelinMartinov commented Dec 16, 2024

What happened?

Under both TF and Pulumi, a resource is not replaced when updating a property of an element in a ForceNew collection.

Example

[ 
  {nested: val2},
  {nested: val3},
  {nested: val1},
]

to

[ 
  {nested: val2},
  {nested: val4},
  {nested: val1},
]

Does not trigger a replacement of the resource, even if the containing collection is ForceNew.

AWS example by @t0yv0 here: #2726 (comment)

data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["099720109477"] # Canonical
}


resource "aws_instance" "example" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t2.micro"

  root_block_device {
    volume_size = 8
  }

  ephemeral_block_device {
    virtual_name = "ephemeral0"
    device_name  = "/dev/sde"
  }

  ephemeral_block_device {
    virtual_name = "ephemeral3" # tweak this
    device_name  = "/dev/sdf"
  }
}

Related TF discussions hashicorp/terraform-plugin-sdk#1314 and hashicorp/terraform#34691

Note also that the SDKv2 Schema validation is slightly off in a related way: #2723 (comment)

Output of pulumi about

.

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

@VenelinMartinov VenelinMartinov added the kind/bug Some behavior is incorrect or out of spec label Dec 16, 2024
@pulumi-bot pulumi-bot added the needs-triage Needs attention from the triage team label Dec 16, 2024
@VenelinMartinov VenelinMartinov added resolution/by-design This issue won't be fixed because the functionality is working as designed and removed needs-triage Needs attention from the triage team labels Dec 16, 2024
@VenelinMartinov
Copy link
Contributor Author

Closing as intended.

In TF collections of plain elements are replaced when the number of elements changes or one of the element changes.

Collections of objects are replaced when the number of elements changes. Changing a property of an element does not trigger the collection to be replaced.

@t0yv0
Copy link
Member

t0yv0 commented Dec 16, 2024

Collections of objects are replaced when the number of elements changes

Couple of additional information here.

  1. I've confirmed that current Pulumi provider matches TF behavior on the ephemeral_block_device example.

  2. The same instance example can be used to try lists of MaxItems=1 objects, for example:

  private_dns_name_options {
     enable_resource_name_dns_a_record = true
  }

I have confirmed that both Pulumi and TF generate update plans when tweaking these.

So then, it would indeed appear that collection-level ForceNew on List[{"x": X}] and Set[{"x": X}] does not trigger replacements. when an element's property changes, but it would trigger replacements for simple types like List[string].

Indeed this appears to be by-design we need to match.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Some behavior is incorrect or out of spec resolution/by-design This issue won't be fixed because the functionality is working as designed
Projects
None yet
Development

No branches or pull requests

3 participants