https://pulumi.com logo
#announcements
Title
# announcements
b

broad-dog-22463

08/12/2020, 12:14 PM
Delighted to announce our latest Kubernetes superpowers! https://www.pulumi.com/blog/new-kubernetes-superpowers/
pulumipus 8bit 7
partyk8s 13
🍺 2
🚀 13
🎉 18
😎 6
l

limited-rainbow-51650

08/12/2020, 12:33 PM
@broad-dog-22463 does the operator also track the resources in the stack and “reconcile” again when I would manually delete one?
b

broad-dog-22463

08/12/2020, 1:26 PM
@white-balloon-205 / @breezy-hamburger-69619 thoughts on this?
f

famous-kite-69533

08/12/2020, 1:27 PM
Hi @broad-dog-22463 - I've been using Helm 3 with Pulumi already. What's the difference now?
w

white-balloon-205

08/12/2020, 2:25 PM
@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).
💯 1
@famous-kite-69533 nothing new today on Helm 3 - that and Kustomize support were part of the “a couple other things we released in the last few months” section - but wanted to call them out as part of overall recent recent work on Kubernetes ecosystem support in Pulumi.
f

famous-kite-69533

08/12/2020, 2:56 PM
I see, thanks 🙂
m

millions-judge-24978

08/12/2020, 3:07 PM
Super excited for the operator!
p

prehistoric-account-60014

08/12/2020, 3:44 PM
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
?
w

white-balloon-205

08/12/2020, 3:54 PM
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.
👍 1
l

limited-rainbow-51650

08/12/2020, 4:25 PM
@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?
w

white-balloon-205

08/12/2020, 6:04 PM
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
f

fast-dinner-32080

08/12/2020, 6:32 PM
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?
w

white-balloon-205

08/12/2020, 7:04 PM
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.
👍 1