broad-dog-2246308/12/2020, 12:14 PM
limited-rainbow-5165008/12/2020, 12:33 PM
broad-dog-2246308/12/2020, 1:26 PM
famous-kite-6953308/12/2020, 1:27 PM
white-balloon-20508/12/2020, 2:25 PM
famous-kite-6953308/12/2020, 2:56 PM
millions-judge-2497808/12/2020, 3:07 PM
prehistoric-account-6001408/12/2020, 3:44 PM
white-balloon-20508/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 differentYou will in general want to have one?
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
repo (which is very much a monorepo!), each at different commits.
limited-rainbow-5165008/12/2020, 4:25 PM
white-balloon-20508/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
fast-dinner-3208008/12/2020, 6:32 PM
white-balloon-20508/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.