1. Cncf-Tag-App-Delivery
  2. Messages

Re: Operator Framework questions

Matt Farina
 

Please excuse my ignorance on some of this software. I have a number of questions now that I'm starting to look around.

OLM is a package manager for operators

Out of curiosity, why create another package manager? What features are missing from Helm? If some feature was missing I'd love to talk about it to learn the context and assumptions around it.

When I start to look at OLM I see things like Install Plans and Subscriptions. This looks a lot like Kubernetes Service Catalog. Is there any kind of write-up comparing the two?

You can do a lot with operators. If OLM has a lot of similarities to Service Catalog and has a bit of that intent in mind, what about the use cases aren't related to the service catalog type setup?

Should I ask these questions over on the TOC issue instead?

Thanks,
Matt

On Mon, Oct 14, 2019, at 6:03 PM, Michael Hrivnak wrote:


On Mon, Oct 14, 2019 at 4:50 PM Jay Pipes <jaypipes@...> wrote:
On Mon, 2019-10-14 at 16:41 -0400, Michael Hrivnak wrote:
> 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.

Agreed. This is why I think separating the method of discovery and
lifecycle management from the operator-sdk is critical.

Creating an operator and creating its packaging are at least logically separate, even if one tool can do both things. When you create an operator with operator-sdk, it does not have any packaging unless you explicitly run "operator-sdk olm-catalog gen-csv" with some arguments. Adding OLM packaging is optional and does not happen by default.
 
 
Perhaps a developer would like to use the operator-sdk to develop their
Operator, but provide a non-OLM way of packaging that code. Decoupling
the SDK from the method of packaging and managing the code that is
produced by the SDK seems to enable that, no?


This is already easy to do. To start, after you've made an operator with operator-sdk, you can install it manually by running "kubectl create -f" on a few of the manifests that operator-sdk creates for you. They just contain the CRD, RBAC resources, and a Deployment. You could then turn those manifests into a helm chart that installs your operator, or use any other tool you choose.

--

Michael Hrivnak


Principal Software Engineer, RHCE 

Red Hat
Join cncf-tag-app-delivery@lists.cncf.io to automatically receive all group messages.