Consider adding preview

[metral]

Consider thinking through if pulumi preview is useful and needed in an operator, and how it would work.

e.g. Do we store preview links in CR statuses, or hook up GitHub PR webhooks to provide the Pulumi GitHub app preview-in-a-PR capability, or is this not needed at all for an operator?

[nesl247]

I haven't used the operator yet, but have started looking into it. If I understand what this ticket is about, we absolutely need the previews in PRs/MRs. This is essential functionality to be able to see what is changing.

[tedchang77]

This is functionality we would definitely need in order to adopt the operator in production.

[dspitzer]

Without a means of checking the changes beforehand we are also unable to use the operator in production. I’d love to have a way to authorize the changes in the Pulumi SaaS console.

[liamawhite]

FWIW, we work around this by generating local stack configs using the automation API. This won't solve all use cases though.

interface StackArgs extends LocalProgramArgs {
    config: { [key: string]: string }
}

async function createConfig(args: StackArgs) {
    const stack = await LocalWorkspace.createOrSelectStack({
        stackName: args.stackName,
        workDir: args.workDir,
    }, { secretsProvider: REDACTED })

    // Ensure secrets provider is set, for some reason this doesn't occur in createOrSelectStack
    const stackSettings = await stack.workspace.stackSettings(stack.name)
    if (stackSettings.secretsProvider === undefined) {
        await stack.workspace.saveStackSettings(stack.name, {
            // Only override secretsProvider to prevent accidentally deleting other things
            ...stackSettings,
            secretsProvider: REDACTED,
        })
    }

    const configMap: ConfigMap = {}
    Object.entries(args.config).forEach(([key, value]) => {
        configMap[key] = { value }
    })

    await stack.setAllConfig(configMap)
}

[viveklak]

Curious to hear what the desired experience here would be from the standpoint of the operator?

As such the operator is designed to reflect the desired state for a stack backed by a git repository. While this fits into a CI/CD landscape, modeling all CI/CD workflows might be an over-extension. Certainly providing a reasonable preview experience by running the equivalent of pulumi preview and providing the output seems well within the operator's domain. However, modeling an entire approval workflow would seem to better fit a distinct construct/controller entirely. Assuming the stack CR allows a mechanism to request a preview or preview + apply and stack CR exposes preview information, an approval workflow could be crafted in code written against the kubernetes API on top of that. Would that be a reasonable compromise?

We are planning to release support for "constrain to preview" - https://github.com/pulumi/pulumi/issues/2318 this quarter, as per the public roadmap which would enable providing stronger guarantees on previewed vs. final state.

[viveklak]

However, modeling an entire approval workflow would seem to better fit a distinct construct/controller entirely.

Support for #158 would make it simpler to model higher order workflows.

[liamawhite]

Reading through #2318 I agree that I think it makes sense to build it at a layer above similar to something like Atlantis

[sfc-gh-alytvynov]

@viveklak since most git repos used with the operator are managed services with their own approval workflows (e.g. GitHub PRs), I don't know if this feature request should include an operator-managed review workflow.

In our case, all we need is a preview link posted in a GitHub PR after every commit to see the diff, same as you see the file diff for stacks. Then, approval happens on the PR, change gets merged and operator applies it from the main/master branch.

[squaremo]

all we need is a preview link posted in a GitHub PR after every commit to see the diff

@sfc-gh-alytvynov Do you see this as something built into the operator, or an integration with the operator (or you don't care so long as it works)? Flux has something like this -- https://fluxcd.io/docs/components/notification/provider/#git-commit-status -- which won't work for this purpose as it stands, but could be adapted or emulated.

[sfc-gh-alytvynov]

@squaremo something built into the operator would be strongly preferred. I'd rather not set up yet another system and deal with provisioning access/credentials for it, which the operator already has.