 Hello. Okay, Brian's here as well. Yes, yes, I am. By the way, Amy, as we have you here, we discussed the topic about the GitHub repo before we still cannot assign any labels. So, go ahead and check for the invitations to become admin. That is, I believe, where the hang-up is. I am, however. Yep, that's what's going on. You got to accept the invite. Sorry. Oh, okay. It's not that we're all not getting GitHub invitations. Yep, that explains that. I am actually editing things to be able to add you all as chairs, because it's come to my attention that we've not actually done that, so I'm actually submitting a PR at the moment. Okay, thanks. So, we have not a fixed agenda for today. It's the high amount of people from Microsoft joining today indicated that you want to present a brigade. I don't think we had any plans to present anything to it. Here, let's see. Okay, well, we're a few minutes after the hour now, so let's go ahead and get started. I was said that we didn't get any demos on the agenda this week, but we still have some open items. And let me actually go find the, let me go find our running document one second, because there are definitely some new things that we need to bring up right now. I can post it in the chat here. Everything might be all the way down, but there you are, you know, have fun. It's all good. Right. So what I'll do is I'll just go ahead and share this bad boy. All right. So there are some items that didn't hit the agenda. And so I'm just going to rattle them off and then we'll tackle them from top to bottom and get them in the document. The first item is around the definition of operator. I think the history here is we know, depending on who you talk to, an operator is different. And we want to make sure that there's a canonical good that there is a canonical definition of what an operator is and have it written down. And then the next item that I was proposed is, is the operator framework versus the hub. There, I believe they've been submitted and we need to figure out if they should be the same submission or separate submissions. Maybe to quickly jump in this was a discussion yesterday in the TUC meeting. So for those of you who haven't heard what's like, especially discussion about the operator hub. Number one was a clear definition pointing out like the Dallas customer. I should be back now, hopefully. All right. My Mac just decided to switch to microphone null, which obviously did not work. Great. Sorry. So yeah. Yes. I don't know what's going on with zoom. So yeah, the discussion yesterday was to really have the definition of an operator first, before we can really validate further the operator project and where there's something missing in the project that we want to see and how we want an operator to be structured. And the second, like they were to discussion about service manager, for example, and should something like metering be part of an operator should not be part of the core operator capability. And an operator framework with operator hub is, I think, still an important discussion because the operator framework per se allows to build the operator, but it's a whole different story if the operator hub should be managed by CNCF as well. So this is really a question to to red hat on whether we want to separate the two. I'm not sure we have anybody in the cover methods today though. No, we know. I don't think we do. We do, but this is no from red hash we do but I need to check it out internally. So I get I get the right people on the call for you. I think these are the two main two main items that we need to discuss because it all has different implications. Right. Before obviously with helm and the tribe museum. But I think it's better to understand what the future structure and the management of the project should be. And for the matter, there should be two separate submissions conceptually. So if I understand it right, the operator framework includes in their submission, the operator life cycle manager and the operator hub, all three of those and maybe more are bundled in the current submission. It is not just the framework. It's a collection of things that surround it. Yeah, I think that's correct. And also, one thing that we, I think there are some discussing around it already. Actually, people are using operator for work mostly for developing operators. So the position of or pretty hard and operator life cycle management or something like that. I'm not quite in the scope of many people are using operators. I think that is the discussions and read more mostly about. Well, some of this, if I understand it right is there's another submission for kudo, which is another operator based project. And it takes a different route than the operator hub. It is also, I don't know the ins and outs of it. I know there are other operators out there, such as the one that the Microsoft folks wrote for it's called rudder. And that's another example of an operator. It's not even written in go. And it doesn't use things like charge back and other things like that that are included in the operator life cycle manager, right? And operator life cycle manager operator hub and operator framework are all bundled together. So what does all of this mean when there's these other things outside of the one submission, like how does it all play together? And what does that mean? Yeah, I think that's what everybody's a bit unclear about right now, because it's like not just the project. It's a couple of bits and pieces. And the question should really go back to Red Hat, whether they want to potentially separate the three because it's the three different discussions kind of. Hi, guys, this is Diane Mueller. Diane, perfect. Sorry, someone just pinged me while I was in another CNCF zoom room. So I apologize. I couldn't clone myself earlier. So, can you ask the question again about operator framework versus operator hub? Yeah, let's quickly repeat. We had yesterday a presentation of the 2D TUC and a couple of questions came up regarding the operators framework submission. First of all, operator and operator life cycle manager that they're bundled together and obviously serving two different purposes plus also operator hub and how they should like all fit together because it's different to have the project, the operator framework project inside CNCF. Versus to more or less them discuss how we can manage and run the entire operator hub and plus we have the charging and metering obviously from operator life cycle manager and whether this should be like a core component of four of the operator as well. So I think the game plan and I think Aaron Boyd probably could answer this better than I than I though I am the person behind the curtain at operator hub.io. But most of the operator hub.io efforts are getting to be pretty automated. And what we're looking for in donating that piece and this is Diane's point of view is to, in the review process, more people involved in in that so by donating it. It becomes not such a red hat centric process or resource sub process but we would still put resources on it to obviously to help with the CI CD process of getting things into operator.io. And it would be nice, in my opinion, to have a non vendor space or non branded a CNCF branded space for all of these operators and services that had players. We have had interest from AWS and Google in resourcing some of the review and upload process but it's pretty highly automated at this point so operator hub itself is almost self sustaining but you can never say that 100% And the other projects it's it's kind of it's being presented I think as a bundle because they all sort of feed each other. Is it a resourcing question of like. I might be able to this is Matt for now I might be able to fill it in this started in the TOC meeting and the context is there are operators that do things very differently than the operator framework. One of the other ones that's been submitted to the CNCF is no. There's also other ones that have been written and so how do they play out because the operator hub plays very much into the way operator life cycle manager works and the operator framework and these other operators. They do things very differently from that so what does it mean for them and some of these are written like kudos some are written in entirely other languages they're not even go based. And they're just different and so what does that mean because they don't fit the current operator hub model and so do they should they fit into that flow. You know a lot of operator life cycle managers very service catalog like and there's a lot of operators out there that don't fit that mold. So how does all of this work together and what does it mean should operator hub be something separate so that way it's not coupled to operator life cycle manager. It can be coupled to multiple operator projects like say both kudos and the operator framework and in the CNCF it's it's coupled to both like how does all of this work and what does it mean. So I actually think those are awesome questions because we've I mean I've thought about them as sort of the community person behind it. And we've done some outreach with the Helm folks and with Coop builder and head conversations about that. The goal of the life cycle management is really to get more mature operators out there in the wild and so we can support day two ops kind of things. But by moving it into the CNCF the governance of what goes into operator hub.io becomes an open and transparent thing. So that would be then I think by adopting it into operator hub.io that conversation becomes something that people will have more influence over and be able to maybe extend operator hub.io to do all the other types as well. So I don't think the donation of operator hub.io as is precludes it from extending to adopt other forms of operators but I think in my humble opinion again those ones that don't they would have to be some metadata tagging thing showcasing maybe what level of maturity because that's barely been with operator hub one of the most significant things is being able to show the level of automation and in place. So I think that that is where some of the disparity comes in but I don't think once it's in CNCF I don't think anything precludes nothing precludes it from being extended to adopt the other ones. So let me ask this though, should it be a separate project from the operator framework so that way let's just imagine a world where both Kudo and the operator framework have both been submitted and become successfully part of the CNCF. They're both going through that process now if I understand the backlog of issues right and they're both operator based. Because there's two projects should the operator hub not be coupled to any of those projects so that way multiple projects can feed into it? Again I think that once the donation and the adoption of it is done it is up to the CNCF how they use it. Yeah so I think we're just trying to get it out there into an openly governed fashion and make sure I know from my perspective I would like to continue to have it support the operator life cycle management. Yeah the reason I'm sorry the reason that I bring this up is when you submitted it's not that the CNCF controls it. The CNCF lets each individual project have their own governance and they are seen as each individual projects. Okay and so it isn't donated to the CNCF as in it's the CNCF will go control it. The CNCF lets the project has its governance so if it's part of operator framework then that operator framework and that whole thing will have one set of governance and that would fall under that. And it would be separate from the governance of Prometheus or Envoy or any of the other CNCF projects and if Kudo landed it would have its own governance structure that is separate. In fact if you look at the CNCF projects each one of them has slightly different governance that works for them. It's different from something like the Apache model. And so where the operator hub lands when it is submitted will dictate how the governance is set up for that and what part of the project it is in relation to the other projects. I absolutely understand that and part of the outreach that we've been doing and we obviously haven't done it to the Kudo group enough is to try and work and collaborate with them to make sure that it can extend it to other forms of operators. And I totally understand that it's still going to be under the operator governance of whatever that group becomes and whatever its name. But the opportunity here is to collaborate openly and to get more and the possibility of it being adopted as an incubated project allows it to move forward and have more people under the umbrella of the operator framework doing that collaboration with other projects. So it's a semantic thing. I got it. If you need to separate it out and in order to get operator framework done then that's the TOC's call. But I personally think that the thing that we need for operator framework and for the operator hub I owe together is for them to grow underneath one project and collaborate with all the other ones. So that's just, you know, the way that I would like to see this move forward. But it's really the TOC's call, whether they want all the pieces or they separate it out. So real quick here about Kudo. What's the status of Kudo was that I haven't done much research on it yet so I apologize. Because I'm not even sure if this comes, if we even need to go that direction this might be like a move point with Kudo, just to put it out there. I think the real question is if I want any type of operator and I want to put it on operator hub what is my minimum requirement to do so? So there's scaffolding for Ansible and Helm and Python and other languages already in place to turn pretty much any of those into operator hub service offerings. So it just depends on how we extend. Yeah, thanks for putting my name. You can add my name in there too. So it's pretty, if you go to operator hub.io you can find the way to add anything in that's either Helm or Ansible operators and others. And so we just keep extending the SDK and the scaffolding to automate the building of pretty much anything and to make them operator hub ready. Yeah, I think the thing that maybe that you see also at least now I'm a bit well worried it might be the wrong word. I think what needs further discussion is do we create like a gold standard when operator looks like right now without involving other people who have operated the frameworks like the two of our were mentioned for their requirements and because as soon as we as appointed as a CNCF project that's pretty much what we do with it. This is what operator has to look like. And I would like to have this discussion with the other folks as well. Yeah, yes and no I mean I think there's one of the things that the CNCF has I think been clear about is that I mean it optics might be in mark how people market is but they're not setting gold standards for projects or I mean if you look at container registries for example, there are multiple container registries out there. You know that's not really what we're doing here. So, you know, I'm just putting that out there I think what what I see this more is an opportunity to collaborate with other people who are trying to solve the same problems and you know come up with some what I what I personally this is is this that I like about the operator framework and the lifecycle management is that it gets us beyond basic installs and of operators and things that can do and what I what I think is is it creates a pattern for things to get to have more maturity and be helpful in the lifecycle of operators and that service on any Kubernetes platform so that's that I think that's more of the goal of operator hub that I always to bring into show what level of support you're going to get for the different things and so it's more of a pattern. You don't have to do beyond an install. Let me let me ask this and so I've got two questions or a comment and a question. One of the things that this that I've heard in the TOC meetings repeatedly is the CNC f isn't going to bring that collaboration a project they expect should be out there collaborating, whether it's in the CNC f or not. The pieces of feedback they've given so to say to have it in the CNC f will bring the collaboration. Normally one of the things that they push back on they say you should have that collaboration anyway. I've heard that and a number of calls. My question would be so we talked about something like operator lifecycle manager right let's go and say and this is something that I've done where I'm at. Well let's say I have an operator packaged up as a home chart. There's no operator lifecycle manager involved and I'm doing this to create an entirely separate avenue as an example that's only for an example with the operator hub. Now how would something like that be positioned and displayed and fit in to the operator hub because it's a different flow from the other tooling that's that's proposed here. So there for specifically for that example there is scaffolding and a little automated tool to turn that into something that's operator currently what's considered operator hub sufficiently wrapped up to be an operator hub. Does it require operator lifecycle manager. You're asking. I don't know the answer to that I don't think I don't think it does it injects some more YAML around it to make it work in the flow flow but you know I'm going to reserve judgment because I just should I shouldn't speak where I don't know exactly the answer. Apologies. But I don't think so it's pretty simple scaffolding that gets added and wrapped around it. So there is a path for anything and or there is a pattern for anything new things like whether it's kudo which I don't know much about or could you know co builder. There are collaborations going on already what we just really want to get. I think is the lift from more eyeballs on the project that you get by becoming an incubated project. And you know then probably myself and other people who come to the project will be doing you know still driving that collaboration Daniel Messier and myself have been doing most of it as well as Matt Dorn and a few other folks. And Chris short but they're you know there's you know we're going to be honest is primarily Red Hatter's working on it on the outreach right now. Though there's you know a couple hundred operators, you know in the in the operator hub not a couple hundred but 100 operators in the operator hub from lots of independent people. All right, so I'm trying to figure out what the next set of actions can be from this because there is there is definitely We're missing contact somewhere so what I will do is I'm going to follow up through our mailing list and so we can figure out first of all where we're trying to be and then figure out how we're going to get there. The thing I would ask is, and it's normally I just jumped on the call so it's normally Aaron Boyd and Daniel Messier who have been answering most of the questions for the TOC. So if you put it in an email thread, let's get them to answer the official ones because I'm basically just the manager behind operator hub dot IO. So that I'd like them to be able to weigh in and I think Aaron answered a few of the questions in the issues lit on for the TOC already. I just hadn't had the bandwidth to go and I wasn't on the TOC call so I apologize. Can can I make two suggestions of things to work out on this one is the TOC asked about the definition of an operator. And so that was a specific ask of the TOC to come back with something in writing. And so we should probably chase that down. Hopefully it's pretty easy since chorus defined it in a manner that everybody's been running with the few years ago. And then the second action, I would suggest is there is Kudo is an operator and they have an open submission to the TOC. So I would suggest SIG app delivery actually reach out to that project on it because a lot of people who submit projects still don't know that it needs to go through a SIG first. There's a bunch of communication and stuff. There's even been some due diligence that's come before the TOC and they said, hey, what did the SIG review this first and help with it. And they're like, we didn't know that that had to happen. So it's probably a good idea to have the SIG actually reach out to Kudo to loop them in and maybe bring them in and start doing the due diligence that the TOC expects. I would suggest those as two next steps because that'll kind of help see how everything fits together because that's what the TOC I think wanted. Yep. And I don't know how many of you are from the SIG are coming to KubeCon in San Diego in a couple of weeks. If you want to have a face-to-face about this, I have a room at the Marriott that I would happily schedule a time to deep dive in further and bring Aaron and not Daniel, but Rob Somsky and the other engineers too on this. And we can talk about it more in further depth. I'm not sure whether you'd like to do that or not. If we have time. Yeah, let's see who we can get together. I'm trying to be available and see with other people as well. Obviously we won't have time during the SIG discussion per se, but we can try to find the time. I think there's just a couple more things that I think still need some homework here. One is with the requirements to run it and because eventually somebody has to provide the infrastructure for Operator Hub if it is submitted. And even if somebody is sponsoring this, we should have a better understanding what's really required to run it. The second point is really on the governance model where I'd also like to better understand how you envision the future governance model to work, how like Operator can make it into the Operator Hub. We'll have a saying in this and how you plan to have this further develop to your point. I think it's great that you started this project at Red Hat and I want to widen it out just a bit more clearance how you expect this to look like would be great. Yep, happy to do those. And then I think I'm just splitting whether it's two separate submissions we can discuss later. By the way, I just read the website again of Operator Hub about publishing and submitting it. I think this is also kind of like a bit ambiguous because for the Operator, your Operator should be able to be managed by the Operator Life Cycle Management, but also Operator Life Cycle Manager. And when it then comes to automated testing, I think it has the Operator Life Cycle Manager as a requirement in there. Yep. Okay. Well, I will... The language is a bit unclear. So we can work on that and clean that up and respond. I'll get one of the other folks who are managing the process to clean that up. Yeah, and Diane, thanks for jumping on the call. So we were not that good at preparing the agenda up front. So thanks for your flexibility as well here. No worries. I'm sure I misspoke at least five times. So that's... We'll clean it. I'll go through the notes and make sure that the folks who are on the engineering side answer your questions too. All right. Okay. Well, all right. Well, that gives us two items on our general list that we have followed by one. So the next one is the application delivery model. And Alice, you want to speak to that? I think we have done some work on the application delivery model. So that's everybody. Is everybody worth to document it? Who would actually have a chance to read it and provide feedback? Let's start there. And some people just posting it in the chat right now. So this was like the first delivery that the first deliverable we were planning to work on. And I think Harry's done a great job moving this one forward. I think the key piece in there is really that diagram, which is a bit further down on the... Yeah, on the reference model where we have application definition, packaging and so forth. I think the next step would be from my perspective and I want to put it up for discussion to be a bit more precise. But the Zoom's haunted today or is it just me? Yeah, I don't know. It's apparently haunted. Hey, hear me again now. Yeah, you're back. You're the haunted one. Got it. I'm the haunted one. So yeah, I think we should now define what really has to be defined in the individual layers and whether there is like a certain logical flow of components and also which projects are the people using for application delivery, see themselves at which layers, which also helps us with the landscape work. So where we would put them. So because they were related to things, if we can define a landscape based on the model, it will show that the model actually works for categorizing projects. If you figure out that every project fits into multiple layers, that's kind of an interesting finding as well. Oops. And the other topic is really what should be described at the individual layers and what the definition should look like for those and what we have there. Does this make sense to. Yeah, and I would actually expect many projects to cross many of the different layers of the things you're calling topics in this, because they're going to be targeted around solving end user problems. And when you try to do that, you're going to end up touching many of these in order to create a good user experience or to provide usability in the solution that's targeted. So you have delivery captured who different roles and actors are and their needs and things like that at all yet. Honestly, we haven't come any further than what you see on the screen right now really on this one specifically. Some parts were in the charter, but most of the reasons. Efforts were really about like project presentations and not so much on the model. That's why we want trying to push the focus back now a bit more in the application. Every model here. Yeah, I mean if you're trying to create a usable solution for certain end users like an application developer and application operator, you're going to end up having tools that cover a lot of the different layers here just in order to create something that has good usability. You know if you're doing the Unix model where you've got lots of things separated into small slices possibly, but quite often you have to chain those together and hack a lot of the app developers and app operators out there. You can just want a nice GUI in place that does a lot of the stuff for them. Good point, Matt. Yeah, I think we should just go one level deeper what we want for the individual piece like for application definition. So actually this is another thought is that we're going to be meeting in person in two weeks. Like two weeks from today, I think. So why don't we prepare something so we will be doing this so that we can actually show this so we can get some consensus with a much larger group of people than what we have now. And to tell you the truth, I'm trying to figure out what like when should we actually think about shipping this and with KubeCon coming up. You know, that's a great opportunity to gather some feedback and then we can think about our next steps after that event. Yeah, yeah, thanks for pointing out. Next session dedicated to the application delivery model at KubeCon. So everybody now can join that session. And I think it's actually called a workshop and I think it should be a workshop. Everybody will say, OK, what do we want to have like in the application definition piece? What do we want to have in there? What do you put in there and what people see in there to have more details there? Maybe we'll defer it to a face to face discussion, which we're going to have in two weeks from now. I think that makes a lot of sense. I really like the idea of an interactive workshop because I think like testing this model out with post-its would actually be really like, I think a good test of it. Is there a workshop in five sets or two weeks at KubeCon? There is, yeah, it's on the website already. I can tell you also when that meeting is going to happen. So let me just quickly check here in just a second. So the workshop is scheduled for Thursday, 10.55 a.m. Did you say 1.55 a.m.? 10.55. OK, all right. Yeah, we'll associate it by the mailing list so that everybody has the dates of those workshops. The first one is just the introduction, which might not be that interesting to this group, but I think the workshop is definitely interesting for people. I think that mostly concludes the meeting for today, I think. Five minutes left, otherwise. All right, well, there's no need of keeping people around. There's other things to be done. I guess we can just call it here. So the next time we will meet, we'll be at KubeCon during our session. So until then, safe travels and have a good day. Brian, this is Diane. Oh, Diane? Because I do have someone graciously gave me a room at the Gaslight Marriott for the week. If we wanted to have a separate meeting to talk about any of the operator hub stuff or something else related, I'd happily schedule some time. It only fits 15 people. And I'll add some notes to the meeting here with follow up on some of the questions that were asked. I've asked a bunch of questions, so I'd be happy to join. I think that a few people in person sounds like a good idea. I think we mentioned that on the TSC call as well. So I'm going to set up the doodle and the calendaring thing hopefully tomorrow. And we can figure out a time that might work for everybody else. I'll look at the schedule. But that's my goal with that room is to meet face to face time to use it wisely. All right, Diane. So we'll reach out to you. All right, and I'll put my email in the box in case you don't have it. All right, I was just going to Google you. Hey, well, it's easy. All right, cool. To be quite honest, which is kind of scary. All right. All right. Well, in that case, Diane, we will be following up with you and we'll put out a call. There are a couple of people that we would like to have a conversation around that. But we'll have to keep in mind the amount of space that we have. But we'll work out the logistics for that. All right. Well, thank you, Diane, for popping in here from whatever else you were doing that is appreciated. And thank you everyone else for showing up today. And like I was saying before, we'll see you in a couple weeks in person, some of you at least. And then we will not be having this and then we'll have this meeting again. What is it like the 6th of December is that the day. We'll leave. It seems accurate. Yeah. Yep. It's like a month. Yeah, that's right. It's like a month. So until then. Bye. Good to see you. See you guys at cookbook.