Run Automatically on OCIRepo Updates

[rawkode]

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

When using OCIRepo as a source, the operator should run updates whenever the OCIRepo has been updated.

When using a 5m sync on both OCIRepo and Stack, this can lead to 10m before Pulumi eventually runs the sync.

Affected area/feature

OCIRepo Source

[squaremo]

The operator should notice when a Flux source is updated, and queue Stacks that use it, after #348. Do you have evidence to suggest it's not working in this particular case (or in general!)?

For the OCIRepo, that's Flux's responsbility -- it's not clear to me from https://fluxcd.io/flux/components/notification/receiver/ whether you can set up a webhook receiver to poke an OCIRepo or not, but that's how you'd do better than polling.

[rawkode]

Does the status of the Stack get updated to queued and/or running?

Perhaps I'm just not getting enough information to know that my stack update is happening

[squaremo]

Does the status of the Stack get updated to queued and/or running?

The operator sets a condition Reconciling=True on the Stack object while it's running the stack (or if it failed a run and has requeued it to try again). Also: if you set the arg --zap-level=debug on the operator deployment you will get more in the logs about why it's running or not running a stack. It's a bit cryptic still but you may be able to interpret.

[rawkode]

@squaremo Could we have k get stacks show that it is queued and running too, please?

[squaremo]

Could we have k get stacks show that it is queued and running too, please?

Broadly, yes -- I agree that would be really useful.

There's no observable queued state, either the operator has seen it and it's running, or the operator hasn't seen it. There is a Reconciling=True (RetryingAfterFailure) condition that indicates it's been requeued, though.

I filed #396 for improving the output of kubectl get stack in the way you're suggesting.

[rawkode]

Perfect. Thanks, @squaremo

[pulumi-bot]

Cannot close issue without required labels: resolution/

[squaremo]

I'm also happy to close this one (I'll sort out the labels to make pulumi-bot happy) -- do you want to make sure the operator works as expected with respect to OCIRepo objects, by looking at logs or conditions, though?

[rawkode]

I'll update my logging parameters and confirm, but I suspect this issue can be closed.

I can re-open if I can confirm the behaviour is broken.

Thanks for your help

[squaremo]

no-repro seems like the closest to "works for me" :-D