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.

[picpromusic]

From my point of view it would be cool to support the feature to provide an proved plan file like https://www.pulumi.com/blog/announcing-public-preview-update-plans/

But I only have unclear picture of how this would match the idea of reconciliation done by an kubernetes-operator/controller. If something changes on the target-side how do you want to create and provide a new plan with approach that is outside of the operator-system.

Maybe this would work: The operator provide an event and write the plan to an configmap-style updateplan-customresource whenever it detects drift. And an approver has to "sign" it of by annotating the cr or something similar?

Signing could be done via kubectl or by your ci/cd which could prepare a pr/approval-request in your system of choice based on the updatePlan-content based on the event that could be monitored. Approving your pr then writes back the same updatePlan just with the annotation.

The updatePlan could/should reference the resource version of your pulumi-stack cr to make it easier to find matching updatePlans. My gut feelings says that this should maybe an requirement(should) and not optional(could). But I am unsure how often the resource version of the stack-cr is updated and if this is under control of the pulumi operator.

[fghso]

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?

Seems reasonable to me. There are many ways the approval mechanism could be implemented, as long as the primitives are there, so it makes sense to leave it as something to be built upon PKO's foundational capabilities.

For me, at least, the main point in having preview would be to enable the basic flow of preview/apply using Kubernetes only. So, the same way we can execute preview/apply using Pulumi CLI only or via GitOps only (based on the CLI or automation), it would be nice to be able to execute preview/apply using PKO only. This would also enable other custom automations in k8s on top of PKO, not only approval.