Erin, I apologize for the confusion from my language. I was more interested in the concept of a service catalog rather than the specific Kubernetes implementation. The major public clouds have

HI Matt, So interesting that you bring up the service catalog. Do we have a feel for the service catalog usage? One thing about it is that the API is built off of CFF rather than Kube, so there is a

At the moment, we're still holding for the 23rd, with the meeting moving the first week of November. Thank you! - amye <dirk.wallerstorfer@...> wrote: -- Amye Scavarda Perrin | Program

https://developer.ibm.com/blogs/eclipse-cloud-developer-tools-working-group/

Hi, I wanted to ask about the date of the next community meeting. Last time we discussed whether the meeting cadence will be changed to 1st and 3rd Wednesday. Is the next meeting tomorrow or next

I am an early engineer on the operator idea, and drove the inception of SDK/OLM etc. at CoreOS . OperatorHub is designed to be operator first, which means the users need to understand the operator

Daniel, thanks for the added color. I have more questions... This and some of the other comments sounds similar to a service catalog along with elements of OLM (e.g., the metering and chargeback

Hi Roger, there is a group of people responsible for running the site itself and processing submissions. We use standard GitHub issues / PRs for contributor interactions and as part of the CNCF

There are a bunch of Operator lifecycle aspects, mainly around CRDs, that OLM takes care of so you don't have to. E.g. what happens when you attempt to install an Operator and there is already a CRD

Please excuse my ignorance on some of this software. I have a number of questions now that I'm starting to look around. Out of curiosity, why create another package manager? What features are missing

Side question: is anyone here involved with management of OperatorHub, or if not, have pointers to folks who are? Roger B.A. Klorese (they/them or he/him) Senior Product Manager SUSE 255 King St

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

Agreed. This is why I think separating the method of discovery and lifecycle management from the operator-sdk is critical. Perhaps a developer would like to use the operator-sdk to develop

Yes. Yes. OLM is a package manager for operators, and it specifies a packaging format. Operator Hub uses that same package format. When we talk about Operators, we are referring to the concept

Hi all, I believe we were going to be on the agenda for the next meeting to do a demonstration of Porter (porter.sh) and give a little overview of CNAB, but we'll need to reschedule that as we won't

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

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

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.-- Daniel Messer He / Him / His Product

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

Hi, there were a bunch of questions in the last SIG call in regards to Operators that did not get answered - I am running through the ones from the chat log below. Feel free to chime in, if there was