Hi Gareth,

sorry for the late reply - responding inline. Thanks for the questions - keep them coming!

On Wed, Oct 9, 2019 at 6:22 PM Gareth Rushgrove <gareth@...> wrote:

Thanks for the presentation, I had a few questions and thought I'd
kick things off here.

1. Compatibility
Terminology wise, checking this is still the canonical definition from
a concept point of view?
https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
I know there are several tools which help build operators
(kubebuilder, KUDO, kopf etc.), I wanted to ask about compatibility.
From a developers point of view these are all different obviously, but
what about from an end users perspective?

I think this definition is still valid. An Operator is a custom controller with its own CRDs serving as the user interface (exceptions exist).

The Framework is designed to be open to the way the Operator itself is built. The packaging format and OLM don't depend on the SDK.

However there is of course good integration between the SDK and OLM.

 

2. Relationship to Operator Hub
Chris also mentioned the intent to move the Operator Hub to CNCF in
https://github.com/cncf/toc/pull/303. Do you see that being under the
Operator Framework project, or under a standalone project? I think
that's interesting given the generic nature of Operators (as I
understand them above) and the Operator Framework as a specific tool.
For instance, can a kopf operator be added to Operator Hub today?

It is under the Framework: https://github.com/operator-framework/operatorhub.io

And yes, a kopf operator, or a kubebuilder operator, or KUDO or something entirely custom can be added to this. They enabling part is the packaging format that drives the indexing and visual display.

 

3. Relationship to Helm
As Helm is a fairly well established CNCF project, I'd be interested
in the relationship between the Operator Framework and Helm. How
involved are the Helm maintainers in the integration with the Operator
Framework?

The Operator SDK project maintainers collaborate with the Helm maintainers, primarily on the Helm-based Operator pattern the SDK provides.

Helm in general focusses on Day 1 operations: bundle & install using an external tool. Operators include that and put emphasis on Day 2 operations: orchestrated updates, complex re-configuration without re-deploying from scratch, backup / restore, failover / failback, etc with kubectl. Helm serves stateless applications very well, that can be entirely maintained using the built-in functionality in k8s. Operators serve those too but provide an evolution to templating package manifests by extending the built-in k8s functionality, thus enabling k8s to run stateful applications and advanced, distributed systems.

 

Regarding the Operator Hub point as well. One thing I feel we should
strive to avoid plays out in my mind like:

User: Where do I find applications I can install on my Kubernetes cluster?
Helpful internet person (HIP): Why type of applications are you using?
User: ?
HIP: Helm or Operators?
User: ?
HIP: Never-mind, do to Helm Hub and Operator Hub
User: Thanks! I presume these come from two different organisations?
HIP: Oh, no, both are CNCF projects

I get this sentiment. I think it's important to point out that Operators and Applications are different concepts. I'd like to think of Operators as managed service providers to get managed instances of applications. So the question a user would be asking instead: do I want to enable my cluster to serve me that application and manage it or do I want to run it myself?

 

I know their are benefits to different tools and approaches under the
CNCF banner, but when it comes to generic descriptions (Applications!)
and end user distribution it's probably worth a conversation between
multiple projects.

Yes, agreed!

 

Thanks

Gareth

--
Gareth Rushgrove
@garethr

devopsweekly.com
garethr.dev

--

Daniel Messer

He / Him / His

Product Manager OpenShift

Red Hat GmbH

Wankelstrasse 5

70563 Stuttgart

dmesser@...