pulumi-aws 5.22.0 and above keep updating aws:route53/resolverEndpoint:ResolverEndpoint even when there's nothing to update
#791
Comments
aureq
added
kind/bug
thomas11
added
resolution/wont-fix
|
Unfortunately, this is due to a backwards-incompatible change (a valid bug fix) in the upstream Terraform provider. It would probably be hard to work around this on the Pulumi side. The unnecessary update should only occur once, though. |
|
Hi @thomas11 I'm reopening this issue since it feels the experience isn't great. If I create a brand new stack with My own outputs here... |
|
Unfortunately, no fix yet but here is some debugging information. The hypothesis is that the issue is caused by this upstream change. Possibly because in the schema, Stepping through in the debugger shows that in
|
|
I'm having the same issue. It was suddenly introduced into my project when upgrading to the latest pulumi_aws pip module. It took a bit of debugging because i'd made changes to this same resource and didn't expect it to be an upstream unrelated bug. Changes are being made even when there are no actual code changes were made: I understand this is actually an upstream Terraform issue/bug but this is a version-stopper anyone using this resource |
|
Hi folks just noting that we've been trying to have a look at this as a possible bridge issue. This PR reproduces in the unit test #788 I'm still investigating a bit to get a better hold of how these diffs are processed. Confirming that reverting 2197a6c2c7a0ff306cec3432acb9f5680866f034 change to endpointHashIPAddress does make this work. If there's any indication that it's truly an upstream issue, like an upstream ticket or indication that this same program when run with Terraform CLI works correctly, that'd be wonderful. |
|
So it appears that the bridged provider is calling So in fact the bridge is calling into TF SimpleDiff method which does down to a endpointHashIPAddress call with an empty "ip" sometimes. Now, that's a little suspicious. The IP is available in the state. Unfortunately I'm a bit more familiar with Plugin Framework than the sdk-v2 methods. IN the PF world, for Computed+Optional attributes, the PlannedState structure is resolved by recursively merging the data from State ant Config, and I'd expect the IP data from State flow in and be made use of before a diff attempt is made. How does it work with sdk-v2 methods? I'm not entirely sure yet SimpleDiff is supposed to be called differently, and TF CLI calls it differently in this case, in which case it's a TF bug, or it's an issue inside SImpleDiff. More on this next week. |
|
I have some new information indicating this is a bridge bug. Here are the versions of Pulumi provider with which I can reproduce the issue and the corresponding versions of the TF provider: However if I use The TF definition I'm using to repro: terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "4.39.0"
# version = "4.42.0"
# version = "4.53.0"
}
}
}
provider "aws" {
profile = "devsandbox"
region = "us-east-1"
}
resource "aws_vpc" "repro_2294_vpc_us_east_1" {
cidr_block = "10.42.0.0/16"
enable_dns_hostnames = true
}
resource "aws_subnet" "repro_2294_subnet0_us_east_1" {
vpc_id = aws_vpc.repro_2294_vpc_us_east_1.id
cidr_block = "10.42.0.0/24"
availability_zone = "us-east-1a"
}
resource "aws_subnet" "repro_2294_subnet1_us_east_1" {
vpc_id = aws_vpc.repro_2294_vpc_us_east_1.id
cidr_block = "10.42.1.0/24"
availability_zone = "us-east-1a"
}
resource "aws_internet_gateway" "repro_2294_inet_gateway_us_east_1" {
vpc_id = aws_vpc.repro_2294_vpc_us_east_1.id
}
resource "aws_ec2_managed_prefix_list" "repro_2294_prefix_list_us_east_1" {
name = "prefixlist"
address_family = "IPv4"
max_entries = 5
entry {
cidr = aws_vpc.repro_2294_vpc_us_east_1.cidr_block
description = "Primary"
}
}
resource "aws_security_group" "repro_2294_sec_group_us_east_1" {
vpc_id = aws_vpc.repro_2294_vpc_us_east_1.id
name = "sg1"
ingress {
description = "INGRESS-TCP"
from_port = 53
to_port = 53
protocol = "tcp"
prefix_list_ids = [aws_ec2_managed_prefix_list.repro_2294_prefix_list_us_east_1.id]
}
ingress {
description = "INGRESS-UDP"
from_port = 53
to_port = 53
protocol = "udp"
prefix_list_ids = [aws_ec2_managed_prefix_list.repro_2294_prefix_list_us_east_1.id]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}
resource "aws_route53_resolver_endpoint" "repro_2294_resolver_endpoint_us_east_1" {
name = "rendpoint"
direction = "INBOUND"
security_group_ids = [aws_security_group.repro_2294_sec_group_us_east_1.id]
ip_address {
subnet_id = aws_subnet.repro_2294_subnet0_us_east_1.id
}
ip_address {
subnet_id = aws_subnet.repro_2294_subnet1_us_east_1.id
}
} |
t0yv0
added
the
p1
|
For users tracking this as pulumi-aws issue: please use v5.29.1 or higher that currently works around the specific problem with ResolverEndpoint, this issue is tracking fixing the root cause to future-proof other resources. |
t0yv0
removed
the
p1
AaronFriel
added
the
p1
t0yv0
removed
the
p1
|
The root cause is now fixed in pulumi-terraform-bridge #844 under a feature flag. Feature-flags de-risk the rollout since the change involves Diff method and has a potential of unintentional consequences such as unexpected replace plans on provider upgrades. The tentative plan for gradual rollout is in #866 |
|
Cannot close issue without required labels: |
What happened?
As reported by a customer in Zendesk #2189
Running the Python program below, the provider always update the
aws:route53/resolverEndpoint:ResolverEndpointresources even when there's no code changes.During the preview, the diff taken from from the Pulumi service is like this
When applying the update, which takes 6m30s, the diff from the Pulumi service is this
But downgrading to 5.21.1 and applying the update, everything is then fine and the diff is a lot cleaner.
After trying with different versions, here are the versions affected:
Steps to reproduce
Follow the steps below to easily reproduce this issue:
source venv/bin/activate.fishor whatever works for your shell.pip install pulumi-aws==5.21.1pulumi upand deploy all the changes.pulumi upa 2nd time, there shouldn't be any changes ✅pip install pulumi-aws==5.25.0pulumi upand now some changes are pending ❌pip install pulumi-aws==5.20.0pulumi up, only the provider version is to be updated. ✅Expected Behavior
Version 5.22.0 and above should behave the same way as 5.21.1 and earlier version, as in, not update/recreate resources when no code changes have occurred.
Actual Behavior
In version 5.22.0 and above, despite no changes, the stack is being updated and new resources are created/destroyed.
Output of
pulumi aboutAdditional context
Here is the code I crafted to reproduce the issue.
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).
The text was updated successfully, but these errors were encountered: