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