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

Automation API support for pulumi-refresh --preview-only #244

Open
PhilBroderickCrezco opened this issue Mar 18, 2024 · 3 comments
Open
Labels
area/automation-api kind/enhancement Improvements or new features

Comments

@PhilBroderickCrezco
Copy link
Contributor

Hello!

  • Vote on this issue by adding a 👍 reaction
  • If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Now that the CLI supports the preview-only flag for pulumi refresh (pulumi/pulumi#15330), it would be great to have that available for the .NET Automation API. I was going to take a stab at this myself as it should be relatively straightforward, however looking into the code, the --skip-preview flag is hardcoded into the args:

I thought it best to open a discussion on how we expect this to work.

To give a bit of background: we currently use the Automation API to create/manage some of our microstacks, but we are unsure on the best workflow for incorporating pulumi refresh into this. By it's nature, the Automation API isn't always going to prompt for manual approval, hence the --skip-preview flag I presume, but we want to be able to manage state drift between Pulumi and our Cloud Provider (Azure).

Now, there are certain state differences, especially in Azure, that we are happy to apply (timestamp changes to modified dates etc), but others we don't want to auto apply and at least prompt users/tooling that there has been drift. My initial thoughts were that this would be possible with the RefreshAsync method and the ExpectNoChanges flag, but with the presence of the --skip-preview flag, the changes do get applied, and then Pulumi throws a CommandException, which is obviously too late to do anything about as the state as been updated.

I'd be interested to hear what is the recommended workflow for state drift/applying refreshes. Is this something that we should always just be doing, no questions asked, say before or after an update? Should we always run a refresh pre-update and abort on any changes, or at least get a set of eyes on the proposed changes first? Does it make sense to run refreshes out of process, say on a schedule? It's hard to find a recommended approach for this, especially when dealing with the Automation API.

Affected area/feature

Automation API

@PhilBroderickCrezco PhilBroderickCrezco added kind/enhancement Improvements or new features needs-triage Needs attention from the triage team labels Mar 18, 2024
@komalali
Copy link
Member

Hey @PhilBroderickCrezco thanks for the issue! Lots of great questions. I'll tackle them one at a time.

Here's some prior art for adding preview-only support to automation api (in Go):

Essentially, if we're doing a preview-only refresh we'll want to replace the --skip-preview with --preview-only. I think it's fair to create a separate method for this as we have done in Go.

We also added a Refresh option to Stack.Up() et al to roll the refresh/update command into one - something else that might be worth porting over to .NET: pulumi/pulumi#15350

I'd be interested to hear what is the recommended workflow for state drift/applying refreshes.

I think this is really going to depend on your workflow, the kinds of resources you have, the kind of drift you expect, etc. For instance, you might have resources that you expect to update outside of pulumi, in which case you'd probably want to mark those properties as ignoreChanges to avoid spurious diffs.

There are certainly cases where folks would always want to understand the drift, and other cases where folks just want to keep the pulumi program as the source of truth and always want the drift written over.

Let me know if that helps or you have any other questions.

@PhilBroderickCrezco
Copy link
Contributor Author

Hi @komalali thanks for the response. That Go PR was the one that prompted me to raise this issue in the first place!

There are certainly cases where folks would always want to understand the drift, and other cases where folks just want to keep the pulumi program as the source of truth and always want the drift written over.

All makes sense and as we've come to the conclusion of; it feels like it needs to be dealt with on a case-by-case basis and no one answer fits every scenario.

We also added a Refresh option to Stack.Up() et al to roll the refresh/update command into one

I wasn't aware of this - that would certainly be useful to have.

For instance, you might have resources that you expect to update outside of pulumi, in which case you'd probably want to mark those properties as ignoreChanges to avoid spurious diffs.

Yes there certainly are, and this is exactly where we use ignoreChanges.

Essentially, if we're doing a preview-only refresh we'll want to replace the --skip-preview with --preview-only. I think it's fair to create a separate method for this as we have done in Go.

Agreed. If you'd be alright with it, I wouldn't mind taking a stab at implementing this and opening a PR. Based on the Go implementation, it doesn't seem too complex now that we've got a shared understanding of how it should work. This is something we'd be very keen to use in our Automation API programs very soon.

@komalali
Copy link
Member

If you'd be alright with it, I wouldn't mind taking a stab at implementing this and opening a PR.

@PhilBroderickCrezco Yes please, would love to review a PR for this!

@cleverguy25 cleverguy25 added this to the 0.103 milestone Mar 18, 2024
@Frassle Frassle added area/automation-api and removed needs-triage Needs attention from the triage team labels Mar 26, 2024
@cleverguy25 cleverguy25 removed this from the 0.103 milestone Apr 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/automation-api kind/enhancement Improvements or new features
Projects
None yet
Development

No branches or pull requests

4 participants