// the find
operator-framework/operator-lifecycle-manager
A management framework for extending Kubernetes with Operators
OLM is the package manager for Kubernetes operators — it handles installation, dependency resolution, and automated upgrades of operators via CatalogSources, Subscriptions, and ClusterServiceVersions. It ships as part of OpenShift and is widely deployed in production Kubernetes clusters. The catch: the README's own warning tells you this is v0, now in maintenance mode, with no new features accepted.
The CRD ownership model is genuinely clever — OLM enforces that only one operator can own a given API group/version/kind, preventing the silent conflicts that happen when you naively install multiple operators. The channel-based upgrade system (alpha/stable/etc.) with explicit replaces/skips graphs gives operator authors real control over upgrade paths, not just 'latest wins'. The dependency resolution between operators (vault depends on etcd's CRD, OLM wires that up automatically) solves a real problem that most Helm-based approaches punt on entirely. Test coverage is solid — the controller tests use envtest against a real API server rather than mocking the Kubernetes client.
This is maintenance-mode software by the team's own admission — the successor is operator-controller and if you're starting fresh you should be looking there, not here. The ClusterServiceVersion format is genuinely painful to author by hand; it's a 200-field YAML struct that requires deep knowledge of OLM internals to get right. Dependency resolution only works at the CRD level (Group/Version/Kind) — you cannot express 'I need etcd-operator >= 0.9' as a version constraint, which means the 'dependency model' is more limited than it sounds. The catalog serving architecture (gRPC from operator-registry pods) adds operational complexity: catalog pods become a failure point, and debugging catalog resolution failures requires understanding a separate registry system.