This message was deleted.

“The Pulumi operator can manage all of your other tiers and your other operators, so maybe you need fewer of those other operators,” Duffy suggested. “Do you really need a Cassandra operator to manage the Cassandra infrastructure or do you just use the Cassandra provider for Pulumi that allows you to manage your Cassandra database? [...] maybe standardise on the Pulumi operator to manage all those things and that can help bring down the explosion of operators.” Trying to answer my own question: https://thenewstack.io/the-runaway-problem-of-kubernetes-operators-and-dependency-lifecycles/ Looks like Pulumi itself can be thought of as a meta-operator, much like the OLM Operator, but with the full expressivity of higher-level languages. Still unclear how the two can interoperate; any ideas?

I’m not really familiar with OLM, but it sounds like it would most naturally fit into the Pulumi ecosystem as a provider. i.e., if you want Pulumi to defer operator installation to OLM, you could treat OLM as the driver/provider to do that. At first glance, that seems like an unnecessary level of complexity since you could also manage the operators directly with Pulumi, but there may be other nuances I’m unaware of. One of the main befits of letting Pulumi manage the Kubernetes resources directly is that you get a unified resource lifecycle (previews, updates, etc).