Hey all 🙂 We are currently trying Pulumi Operator v2 in our platform. We have been using Pulumi forever now and we made an improvement request back for the previous Operator: https://github.com/pulumi/pulumi-kubernetes-operator/issues/515 We would be interested in the reasons for not automatically removing the worker pods after the stack processing? We have hundreds of stacks and we are not keen on having hundreds of dangling job pods idling around most of the time. In the release notes it says: "The pod is not discarded at the end of a stack operation, instead it remains in-place unless the stack is deleted. We’re considering introducing the option to clean up the workspace pod after each operation to enable you to make a trade-off decision between performance and efficiency. Please let us know if this is something you’d like to see!" So, I want to officially let you know that this would be an awesome addition 🙂 If it isn't possible, maybe you can let us know the reasons for this design choice.

Thanks for feedback! We just didn't quite fit it in for the v2 workstream yet, but part of the reason for the new version was to make this easier! We have an issue open here Option to retain or delete the workspace after successful sync· pulumi-kubernetes-operator/694 feel free to drop some upvotes there. (Or if you're inclined to contribute we'd be happy to review a PR!)

@miniature-twilight-47355 Awesome, I left my thumbs 🙂

Thanks again @nice-kangaroo-60271 for bringing this up, and we'll get to it soon. The Stack controller is already designed to provision a Workspace on-demand, and it is a straightforward enhancement to have the Stack controller implement a retention policy upon reaching a steady state.