Re: Operator Framework questions
On Mon, Oct 14, 2019 at 11:51 AM Gareth Rushgrove <gareth@...> wrote:
On Mon, 14 Oct 2019 at 16:36, Daniel Messer <dmesser@...> wrote:
> Agree with that Jay. The connection comes more from the OLM side since this is where the metadata format is defined that drives the OperatorHub.io index.
I presume OLM is Operator Lifecycle Manager?
This sounds like OperatorHub requires Operators to use OLM?
Yes. OLM is a package manager for operators, and it specifies a packaging format. Operator Hub uses that same package format.
Are there any examples, or is it possible, for a Kudo (or other
operator tooling) to use OLM?
When we talk about Operators, we are referring to the concept originally described in this post from 2016: https://coreos.com/blog/introducing-operators.html
In sum, an operator has three parts:
1. One or more CRDs that represent the desired vs actual state of a specific application. Example: a "MySQL" CRD.
2. Controllers that reconcile those CRDs.
3. Operation knowledge; anything a human might do (install, upgrade, scale, backup, repair, refresh, rebalance, reshard, vacuum, failover, ...) gets automated as logic in a controller.
Kudo has a very different pattern. It runs a single set of controllers, as "cluster-admin", that own a set of kudo-specific CRDs. That is kudo's out-of-the-box "Universal Operator", before you've installed an application-specific operator. If you then made a mysql operator with kudo, there would not be a new CRD, and there would not be a new controller.
OLM can be the package manager for almost anything that has CRDs, controllers, and RBAC policy. It does not matter how you created those things. You could probably even use OLM to install kudo itself. If you use operator-sdk, it offers some features that may help you package up assets for use with OLM, but you're under no obligation to use it.
I agree with Jay, separating how apps are build from where they are
published would appear important here, otherwise we're going to have
them coupled and we'll have one app store per toolkit before we know
How they are built matters because you end up with very different APIs and lifecycle management features. Operators, helm charts, "kudo operators", and other similar things each have fundamental differences in what they are capable of and how they get used, based on which pattern they are following. The "app store" is merely the discovery mechanism; how many different tools will a cluster owner want to be involved in managing and upgrading the workloads on their cluster? Different cluster owners will have different tolerances, but many will want to standardize on one mechanism for controlling what versions of software are running in their cluster.
Michael HrivnakPrincipal Software Engineer, RHCE