Delighted to announce our latest Kubernetes superpowers! https://www.pulumi.com/blog/new-kubernetes-superpowers/

@broad-dog-22463 does the operator also track the resources in the stack and “reconcile” again when I would manually delete one?

@white-balloon-205 / @breezy-hamburger-69619 thoughts on this?

Hi @broad-dog-22463 - I've been using Helm 3 with Pulumi already. What's the difference now?

@limited-rainbow-51650 support for automatically refreshing on a schedule is coming soon! (It was part of the initial design doc, but didn’t make the cut for this initial launch - but has been requested several times already so is something I expect we’ll add support for very soon).

I see, thanks 🙂

Super excited for the operator!

Will the operator support monorepos (i.e., a monorepo with multiple Pulumi.yaml) or is the expectation that one would create multiple stack resources for each stack in the monorepo and simply use a different

repoDir

?

Will the operator support monorepos (i.e., a monorepo with multiple Pulumi.yaml) or is the expectation that one would create multiple stack resources for each stack in the monorepo and simply use a different 

repoDir

?

You will in general want to have one

Stack

resource in Kuberetes for each Pulumi stack you want to manage. The code (project) for those stacks can come from any repo and any directory in that repo - so it's totally fine to have a monorepo that houses all your code. I've used the operator for example to deploy two stacks out of our

pulumi/examples

repo (which is very much a monorepo!), each at different commits.

@white-balloon-205 follow up question on the monorepo one: if I layer my code in multiple stacks, can the operator “notify” from a lower stack to a higher stack to re-run pulumi?

follow up question on the monorepo one: if I layer my code in multiple stacks, can the operator “notify” from a lower stack to a higher stack to re-run pulumi?

There's currently not a direct way to do this - though it's something we've talked a lot about! It's very natural to model in the Operator, but we haven't come up with quite the right way to model it in the Kubernetes resource model yet. It's also something we're looking to address more deeply as part of https://github.com/pulumi/pulumi/issues/2309 and https://github.com/pulumi/pulumi/issues/2209. Would you mind opening an issue in the Operator repo with your use case where we can discuss further? https://github.com/pulumi/pulumi-kubernetes-operator

Does or will the operator allow storing/tracking Pulumi stack state in Kubernetes similar to how helm does it or will we still have to use an external state store?

Does or will the operator allow storing/tracking Pulumi stack state in Kubernetes similar to how helm does it or will we still have to use an external state store?

Not yet - and it's in many ways an orthogonal feature that we want to support independently of the Operator as well - but it's something we're definitely interested in supporting. Interestingly though - I have personally found when using the Operator that the Pulumi Console becomes even more valuable - as it becomes the primary interface to view what updates are being performed, what the details (and detailed logs!) of those updates are, etc. So although you can definitely still manage state in other backends or in the Kube cluster itself - there is even more incremental benefit to being able to store state inside the Pulumi service to provide richer insight into everything the Operator is automating on your behalf.