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

Re: Operator Framework questions

Michael Hrivnak
 



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.