Sorry I am late to the thread. I just noticed the content.
The proposal notes that the Operator Hub website is the one for the Operator Framework. Given the conversation here, is the plan to keep that or change that? I'm not suggesting anything. Just asking for clarification.
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.
This doesn't accurately share the details, intent, or use of Helm. For example, Helm can serve quite a bit of day 2 and works fine for many stateful apps (I know from experience). I'm not going to go into a lot of detail because many people don't tend to read long emails. There must be a better place to have a talk like that.
It also raises questions, for me, about who we (CNCF contributors) think the end users are, what their needs are, what their on-boarding experience looks like, and numerous other things. Is anyone capturing details on end-users anywhere for the CNCF?
a1. I want to install MySQL
a2. Visits application store from CNCF
a3. Oh, there are several options
a4. Reads tradeoffs
a5 Installs
I think a4 is going to be really tricky. I've spent countless hours discussing Helm, operators, on-boarding people to Kubernetes, automating the things, UX, and how all of this fits together. One thing I've observed is some folks with an opinion that their way is right and others are wrong. It's a philosophy discussion involving a certain amount of belief. How do we get well written tradeoffs when this is going around? But, I have found there are tradeoffs for different ways to install and operate applications.
- Matt Farina
On Mon, Oct 14, 2019, at 11:51 AM, Gareth Rushgrove 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?
https://github.com/operator-framework/operator-lifecycle-manager
This sounds like OperatorHub requires Operators to use OLM?
Are there any examples, or is it possible, for a Kudo (or other
operator tooling) to use OLM?
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
it.
Gareth
>
> On Mon, Oct 14, 2019 at 4:18 PM Jay Pipes <jaypipes@...> wrote:
>>
>> On Mon, 2019-10-14 at 10:17 +0100, Gareth Rushgrove wrote:
>> > Note this isn't about the Operator SDK, but given the Operator Hub is
>> > in scope of the Operator Framework, it appears to be the framework
>> > submitted to the TOC https://github.com/cncf/toc/pull/303.
>>
>> I agree that tying the Operator SDK and Operator Hub together is
>> counterproductive. Is there a reason why they cannot be separated?
>>
>> In my mind, *how* a k8s application is built (Operator SDK) is a
>> different thing than *where* that application is published (Operator
>> Hub).
>>
>> Best,
>> -jay
>>
>
>
> --
>
> Daniel Messer
>
> He / Him / His
>
> Product Manager OpenShift
>
> Red Hat GmbH
>
> Wankelstrasse 5
>
> 70563 Stuttgart
>
> dmesser@...
--
Gareth Rushgrove
@garethr
garethr.dev
devopsweekly.com
