-
Notifications
You must be signed in to change notification settings - Fork 159
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
pulumi keeps reporting changes with AWS:CLOUDFRONT distribution when none happened (Typescript) #2095
Comments
When using v6.29.0 of this package, the results are slightly better:
pulumi:pulumi:Stack: (same)
[urn=urn:pulumi:ringo::4969::pulumi:pulumi:Stack::4969-ringo]
~ aws:cloudfront/distribution:Distribution: (update)
[id=<redacted>]
[urn=urn:pulumi:ringo::4969::aws:cloudfront/distribution:Distribution::cdn]
[provider=urn:pulumi:ringo::4969::pulumi:providers:aws::default_6_29_0::67ee5990-60c8-49fe-a222-8be2b3080e68]
~ origins: [
~ [0]: {
~ connectionAttempts: 3 => 2
~ connectionTimeout : 10 => 10
~ domainName : "bucket-<redacted>.s3.eu-west-1.amazonaws.com" => "bucket-<redacted>.s3.eu-west-1.amazonaws.com"
~ originId : "arn:aws:s3:::bucket-<redacted>" => "arn:aws:s3:::bucket-<redacted>"
~ s3OriginConfig : {
+ __defaults : []
~ originAccessIdentity: "origin-access-identity/cloudfront/<redacted>" => "origin-access-identity/cloudfront/<redacted>"
~ originAccessIdentity: "origin-access-identity/cloudfront/<redacted>" => "origin-access-identity/cloudfront/<redacted>"
}
}
]
Resources:
~ 1 to update
6 unchanged Although I redacted a number of property values, the old and new values didn't differ. |
I've confirmed that this same issue occurs with Terraform and it looks like there is an upstream issue hashicorp/terraform-provider-aws#10526 |
In my current understanding the original issue as stated is fixed but the comment by @ringods still reproduces on latest, and is caused by pulumi/pulumi-terraform-bridge#186 which we really should fix, I'm marking this blocked for now. |
One possible workaround we could take here specifically for this resource is that we could exclude the following parameters from the element key computation, diverging from how upstream provider handles it:
If we do this, changing connectionAttempts will not change the identity of the origin struct anymore and the diff will be clearer. The underlying assumption is that these were added upstream in a hurry without thinking through the implications, and in fact, added in error to the Set function identity computation. |
I was able to get a better repro showing a diff on every run const bucket = new aws.s3.BucketV2('chall-web-bucket', { });
new aws.cloudfront.Distribution('chall-distro', {
enabled: false,
viewerCertificate: {
cloudfrontDefaultCertificate: true,
},
restrictions: {
geoRestriction: {
restrictionType: 'none',
},
},
defaultCacheBehavior: {
defaultTtl: 0,
maxTtl: 0,
cachedMethods: ['HEAD', 'GET'],
allowedMethods: ['HEAD', 'GET'],
targetOriginId: 'chall-origin',
viewerProtocolPolicy: 'https-only',
forwardedValues: {
queryString: false,
cookies: {
forward: 'none'
},
}
},
origins: [
{
customHeaders: [{
name: 'key',
value: 'value',
}],
originId: 'chall-origin',
domainName: bucket.bucketDomainName,
connectionTimeout: 10,
connectionAttempts: 3,
s3OriginConfig: {
originAccessIdentity: "",
},
},
{
customHeaders: [{
name: 'key',
value: 'value',
}],
originId: 'chall-origin2',
domainName: bucket.bucketDomainName,
connectionTimeout: 10,
connectionAttempts: 3,
customOriginConfig: {
httpPort: 80,
httpsPort: 443,
originReadTimeout: 30,
originKeepaliveTimeout: 5,
originSslProtocols: ['TLSv1.2'],
originProtocolPolicy: 'https-only',
},
},
{
customHeaders: [{
name: 'key',
value: 'value',
}],
originId: 'chall-origin3',
domainName: bucket.bucketDomainName,
connectionTimeout: 10,
connectionAttempts: 3,
customOriginConfig: {
httpPort: 80,
httpsPort: 443,
originReadTimeout: 30,
originKeepaliveTimeout: 5,
originSslProtocols: ['TLSv1.2'],
originProtocolPolicy: 'https-only',
},
},
],
}) Every diff shows something like
|
This is very helpful to have a repro, thanks so much! At a glance there's a few things still involved here: pulumi/pulumi-terraform-bridge#186 is in play obfuscating the actual diff pulumi/pulumi-terraform-bridge#1927 (and enrolling the resource in the PlanResourceChange flag) may be worth trying here as it fixed some very similar-looking issues with WafV2 resources |
I was able to reproduce this in Terraform as well so there is probably an upstream issue. |
Actually the issue goes away if I provide a const bucket = new aws.s3.BucketV2('chall-web-bucket', { });
const id = new aws.cloudfront.OriginAccessIdentity('identity', {
comment: 'chall-id',
});
new aws.cloudfront.Distribution('chall-distro', {
enabled: false,
viewerCertificate: {
cloudfrontDefaultCertificate: true,
},
restrictions: {
geoRestriction: {
restrictionType: 'none',
},
},
defaultCacheBehavior: {
defaultTtl: 0,
maxTtl: 0,
cachedMethods: ['HEAD', 'GET'],
allowedMethods: ['HEAD', 'GET'],
targetOriginId: 'chall-origin',
viewerProtocolPolicy: 'https-only',
forwardedValues: {
queryString: false,
cookies: {
forward: 'none'
},
}
},
origins: [
{
customHeaders: [{
name: 'key',
value: 'value',
}],
originId: 'chall-origin',
domainName: bucket.bucketDomainName,
connectionTimeout: 10,
connectionAttempts: 3,
s3OriginConfig: {
originAccessIdentity: id.cloudfrontAccessIdentityPath,
},
},
{
customHeaders: [{
name: 'key',
value: 'value',
}],
originId: 'chall-origin2',
domainName: bucket.bucketDomainName,
connectionTimeout: 10,
connectionAttempts: 3,
customOriginConfig: {
httpPort: 80,
httpsPort: 443,
originReadTimeout: 30,
originKeepaliveTimeout: 5,
originSslProtocols: ['TLSv1.2'],
originProtocolPolicy: 'https-only',
},
},
{
customHeaders: [{
name: 'key',
value: 'value',
}],
originId: 'chall-origin3',
domainName: bucket.bucketDomainName,
connectionTimeout: 10,
connectionAttempts: 3,
customOriginConfig: {
httpPort: 80,
httpsPort: 443,
originReadTimeout: 30,
originKeepaliveTimeout: 5,
originSslProtocols: ['TLSv1.2'],
originProtocolPolicy: 'https-only',
},
},
],
}) |
Ok after looking into this more I think this should be changed to an enhancement. There were two possible issues being tracked here:
The first issue I believe is fixed since it can no longer be reproduced. For #2 this is the way that Terraform works and it doesn't appear that there is a way to change it (See this comment). And actually our handling of it is slightly better than Terraform. In Terraform if we change a single property of a single |
@corymhall My suggestion is to keep this issue as a bug, but to actually close it, while moving the enhancement in a separate issue. It's a good practice against scope creep, and also on the way we track customer requests. What do you think? |
@mikhailshilkov make sense to me! |
@corymhall Great! To double-check: will you open the new issue? Please link these two together once you do. TY! |
I believe Present clearer diff for single element changes to sets· pulumi-terraform-bridge/186 is the relevant enhancement ticket |
What happened?
Created an aws::cloudfront distribution, it provisioned correctly.
Later, when coding other resources and executing
pulumi up --diff
to provision them, pulumi detected changes to cloudfront where none happened, and the changes detected are updating values that are equal between themselves.I created a second cloudfront distro. executed
pulumi up --diff
and got the new distro changes shown AND the same non existing changes to the first cloudfront distro again.Immediately after all changes applied when creating the second cloudfront distro, and without making any change to any file, I did again
pulumi up --diff
.Both distros now show the same non existing changes, at same environment variables, with the same values respective of each distro.
when I hit
yes
to apply changes it uploads those "changes" and the cloudfront distros redeploy.pasting here the origins snippet from the typescript code
pasting here the changes detected by
pulumi up --diff
:REDACTED corresponds to our client name and is the same string
as you can see it detects is has to update:
Steps to reproduce
pulimi up --diff
4.1 connectionAttempts: 3 => 3
4.2 connectionTimeout: 10 => 10
4.3 domainName: domain-string-123 => domain-string-123
4.4 originId: origin-id-abcd => origin-id-abcd
Expected Behavior
nothing changed => nothing should be updated
Actual Behavior
nothing changed => pulumi shows non existing updates and applies them causing resources to redeploy
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).
The text was updated successfully, but these errors were encountered: