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

pulumi refresh causes later pulumi diff/ups to destroy CF logging bucket grants #62

Open
ryanjjung opened this issue Dec 2, 2024 · 1 comment
Labels
bug Something isn't working wontfix This will not be worked on

Comments

@ryanjjung
Copy link
Collaborator

In the CloudFrontS3Service class, we grant the S3 canonical user the ability to control the logging bucket. When the distribution is created and the logging config set, AWS comes along and updates those grants to allow the CF service the ability to manage log files there. Those grants are not managed by Pulumi (and they should not be, they are automated on the AWS side). Instead, we need to ignore changes to these grants. Otherwise, when a pulumi refresh is run, those grants will be added to the state and subsequent ups will want to destroy them.

@ryanjjung ryanjjung added the bug Something isn't working label Dec 2, 2024
@ryanjjung ryanjjung added this to the v0.0.9 milestone Dec 2, 2024
@ryanjjung
Copy link
Collaborator Author

I'm not sure there's a way around this. I tested through this problem by:

  1. Fixing other unrelated issues that showed up in the preview to isolate this problem.
  2. Adding an ignore_changes option, which had no effect (more on this later).
  3. Manipulating the state manually to remove the grant outputs from the state file.
  4. Running a pulumi preview, which no longer wanted to remove the grants from the bucket.
  5. Running a pulumi refresh with the ignore_changes option in place, which wanted to add the grants back into the state. This would have led to the recreation of the problem and necessitated another state hack to resolve, so I did not proceed. However, this informs my current conclusion:

This cannot be done at this time.

The docs on ignore_changes say:

Pulumi ignores a property by using the old value from the state instead of the value provided by the Pulumi program when determining whether an update or replace is needed.

And also:

The ignoreChanges option only applies to resource inputs, not outputs.

When you do a pulumi refresh this updates the state to include the actual state of the resource (which includes the grants created by AWS/CloudFront) as outputs in the Pulumi state. But the inputs have not changed (since we do not create/define these grants). So the next time you run a preview or up command, Pulumi detects a difference between the inputs and outputs of the resource. The ignore_changes option tells Pulumi that it should consider the state (declaring no grants) as the truth, which would mean destroying the grants.

Furthermore, the docs read (emphasis mine):

Ignored properties will still be used from the program when there is no previous value in the state, most importantly when creating the resource.

So I believe that this is not actually a benign change, but something that will prevent the grants we do define in code from being created when a new environment is built. I reverted my changes because of this.

pulumi refresh does not apparently respect ignore_changes. I scanned issues in the pulumi github project and in the pulumi-aws project, but didn't come up with anything. I suspect this is actually by design and working as expected. That is, Pulumi is correctly ignoring changes to my inputs (of which there are none) and not ignoring changes related to the outputs, which is what the refresh command is updating.

@ryanjjung ryanjjung removed this from the v0.0.9 milestone Dec 2, 2024
@ryanjjung ryanjjung added the wontfix This will not be worked on label Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant