 Hello and good morning. Morning. Morning. All right, we'll give people another minute or so to get started. I can get myself situated as well. All right, today is January 29th. And this is CNCF's sick app delivery by weekly call. Just a little bit of a reminder before you get started. These are recorded. So only say things you want the internet to know about forever. And let me go ahead and share our meeting notes. So like I said, today is the 29th of January. We'd like to keep an attendance list to see who shows up. So feel free to add yourself. I will actually put the link. In the chat. In the link for the chat. There it is. All right. So today, just noticing that our agenda is way shorter than it was two weeks ago. Time allowing we can definitely make it longer. But I wanted to get started off with the first item on the list. And I wanted to get started with the first item on the list. And is there anyone new to stick up delivery and want to introduce themselves and why they decided to show up? I can start. I'm Stephen Levine. I'm on the core team of the cloud unit build packs project. And I'm here just to answer any questions if they come up. As the absolute looks at cloud unit build packs, entering incubation. All right, sounds good. Welcome. Thank you. Thank you. Thank you. I'm Xander. I'm one of the contributors of the cloud built packs project. And I'm sort of just here for the same reason. All right. So anyone else from the cloud native build pack project wants to introduce themselves. Yeah. Should we do like a group introduction? I'm Javier. Yes. I'm the platform maintainer for the cloud native build packs. You're more as a witness to the discussion. Sounds good. At least one more. I'm Micah. Also on contributor and the cloud native build packs, particularly focused on windows. Okay. Sounds good. I'm Peter. I work on a platform engineering team and. We are interested in learning. Okay. Hey, I'm trying to figure out. Mike is. Is that Jed record? It looks like it. I cannot meet people. Who is the host? I am not signed in as a host. Nobody is. Nobody is signed in as the host. There we go. Well, thank you. All right. So moving down our agenda items. A little bit ago, we put out a call for a working group on air gap environments. And there is lots of good responses from that. And so the next step in this, I swear, there was one to. There was definitely lots of good responses to this. So the next step is to get all the interested people together. And let's get this conversation going. I am not a hundred percent sure. Of the process for creating an official work group in CNCF. That was something that Alice and I talked about earlier. This week, but what I want to do is let everyone know who's here now or might watch this call or even on the mailing list is that we'll send out a message today about this to get this. Moving on. And I see that Alice pointed, put it out in the meeting that we would put the discussion of creating a working group. Is anyone here that actually responded to that? Guess not. Can I, can I ask a quick question, Brian? You sure can. What is the structure of working groups in the CNCF? They, they were originally started. And then they were kind of converted into SIGs. And the intention was SIGs would take over from much of what the working groups had been doing. So when we talk about these new, working groups, what's, what's the scope, the structure, the plan? Do you know what that is? No, that's actually, that is one of my jobs today. Actually is to figure out exactly what it is because, you know, we, we did, we did working group work with the Kubernetes SIGs. And I think they are a little bit different. So I do want to make sure that we do this the right way and, and get them recognized in the correct way. I do also know that there's, there are other working groups right now. So this will not be the first, but I just want to make sure that we are doing it correct. And, and we can get this organized and get meetings set up. And then also determine because working groups are not forever or should not be forever. What, what will be the end goal of this working group? And what are we working towards? And maybe what someone would like to hear. What, what will be the end goal of this working group? And what are we working towards? And maybe what some of those first deliverables will be. So. Well, that's actually a very short conversation. And I have a question, actually more of a comment. Yes. Google Docs allows you to draw on the, on the, on the canvas. It's pretty. But yeah, open up your own Google Doc and do that. All right. So Brian, I don't see the drawing on it. Oh, I see it. Can you see it on my. I can. Oh, we can see it in the screen. I cannot see it on the version that I have open just so you know, it's not everybody. All right. Well, just because of that, I'm going to hit reload. Oh, still there. Yeah. Actually, it might be on the screen share itself. Rather than zoom rather than yeah. There we go. All right. Good to know. All right. So, so more information will be on the million was today for the air gap environments. Next is a little bit of discussion on opera, a new working group for operator best practices based on our conversation last week. We had lots of great insights on, as we discussed operator framework and what that entails, but we also had, you know, there's, there's. The operator framework is not the end all be all answer to operators in this cognitive space. So what we wanted to do is create another working group for interested people who want to help define this space. And just a little bit of commentary before that is that I did actually take a very long look at the operator framework and all its components to try to see how it was put together. And I realized that, you know, there are some great places for specs to be created. So an example would be on the front end, so the way that an operator framework, they have this idea of manifest that include cluster service versions, their term, and they are put into this SQLite file and service registry. That's interesting, but that's an implementation detail. Let's figure out how we can actually standardize on, maybe the cluster service version is a good idea. And actually it could be, it could actually work with pretty much anything. So let's actually focus there. And then on the other side for the operator hub piece, because I noticed some conversation on that, is how do we include things like Helm and other types of things in this operator hub. And looking at that piece, you know, it's, there's the way the operator hub works is that it makes GRPC calls to a registry and what's in there doesn't really matter. So there's definitely some work that can be done there too. And this actually work would help the ecosystem a lot if we could actually figure this out. So what I'll do is, let me actually write this down so I don't forget, is I'll send a message out to the mailing list today and to say that we want to actually start this idea out. Go ahead, Matt. I just kind of had a comment and a question. One with the things around the operator hub and the registry, it might be worth you reaching out to Dan Cohen on this. Just because of the work he's been going on in the background and the CNCF hub type stuff, just tie off with him. You may have some insight there on things that are happening or in works that may be helpful, fruitful or useful. The other is, it sounds like the output of this is specs. And I know the CNCF, well, we do have a couple of specs in there. But the goal is not to be a specs organization. Is the goal here more specs or guidance or what's the outcome? So I mean, yeah, that word spec is super overloaded. The way that I think of a spec is not something organized by a governing body or standards organization. It's more of, and actually spec is probably the wrong word. It's more of that concept of we have this concept of operators. And we want to put them into something. So they can be searched and they can be installed. And it's not really owned by one group. What does that think? And I don't know. And that's actually up to the working group. I may or may not participate in that working group. So I want others to actually sit down and think about that as well. And that would be the more the recommendation from the working group. So I'm not saying what should happen. I'm just saying that we need to think about that. And then we can do some ideas. Okay. Yeah, I know one of the things on the Kubernetes side is going in a lot of times we would like to have the outcome, you know, what's going to be generated and why and what's needed. So that's why I asked those questions. I also know as, you know, you talked about the service version. In a cluster and it struck me that that is even a bit of an assumption that the operator you're running is designed to host a service inside of a cluster. There's lots of people who will have a single instance of an application. And they're not meant to be a cluster wide service. And I don't think that gets talked about much. Because a lot of the people who are doing it are actually doing service based setups. But there are a lot of folks out there who are doing. A single instance of an application and an operator to manage that. And they're not running it as a cluster service. Yeah. So the cluster service version is just the name of the file of the, of the CRD that red hat created or chorus created. I was actually not even look at it as a service. It's just the, the name of that thing. So. Yeah. It does speak a little bit to the, the thought process behind it by its naming. And I just want to bring up that there's other ways besides as a service that operators can be done. And so whoever's working on this, I would suggest that they take into account those other things as well. Right. So actually, share maybe some light on this. So you're right. It's called a service. But if you look at these back of the CSB, you can see that it has the concept of install modes, which covers exactly the scenario that you just described Matt, where the operator is really just scope to a namespace. Looking after a single application instance. And it's not offering something customized as a service. So the name might be a little bit misleading there. And it's also a little bit of a mouthful. And that's why we are actually in the process of thinking about changing that. Plus one. All right. I quickly wanted to add something to the previous discussion about this. I'm going to go into the next. It's, it's a different. Working group. But we have actually, I'm just going to paste this in here and the agenda notes, opened a cap. As part of work in the sick plus the add-ons group. With regards to. Describing how we ship. Metadata describing operators. So where is CSVs one format. And helm is another. We wanted to see if there is consensus on. Shipping any kind of manifest describing an operator. In a container image. So. Very closely model to. OCI. With the caveat that OCI isn't fully spec out yet. And that there are little red. Yeah. Not a lot of registries that actually support. It probably with. Mime type that we would need. So there was a proposal put out. That I think the doc here that describes how we would. Generically use a container image. And labels to describe the content. So it's curable. And it's something you can put on a registry. And we want to use that as a discussion basis going forward. To ensure there is a. Standard consensus around how we package. Metadata for operators. And we would put that in a container. And ship that as part of. Or ship that around. And then have that store the actual metadata. I think this would. In the mid to long term tie into the discussion that Matt and I started on operator hot.io. How we standardize capturing the. Visual catalog data. In a central place. Are you familiar with the. What's it called. The new artifacts. That they're working on in the OCI. That allows you to store non-container images in. Registries. I think I heard of that, but. I probably need to read that again. We looked at. For us actually. As a quick POC for that. That's OCI storage. And, and like Evan the. Open or DPR also put out a little. PUC implementation of that. Eventually we came down to just using container images because that's. The tooling that everybody seems to have. Available. And that all registries. Yeah, yeah. If you're care, I dropped a link into the chat here to the artifacts repository. This is a newer thing where the OCI is looking at storing other things in an or us is. The first implementation against that being worked on by folks at Microsoft and Docker. To get working. And so Docker apps. And CNAP. And that's. The first two things I think that are really looking at it in helm. We're looking at it as well. But it's basically being able to store things other than container images in there. And so if you don't want to package it in a container and then have to get to things inside of the container. This may be a route to do it. If you're curious about more details on it, I'm happy to chat with you for a little bit or introduce you to some other folks who know more. But this is kind of the direction the OCI is taking for those things. Yeah, that makes sense. And I think I've seen that before. We are fully aware that what we are proposing in the cap is a temporary workaround until OCI is fully specced out. And we have almost all registries out there supported. And it's easy to get a mind type in, right? That's kind of the hurdle that we are seeing right now. That, you know, easy way to do that. Okay. That makes sense. I just want to make sure everybody here. And you and everybody is familiar with the work. So. All right. Sounds good. Hold on to my video. I actually closed that one. So let me reshare it. There we go. All right. So like I was saying before. What we'll do is we'll put it on the mailing list. And also, paying this like channel that we are going to be creating a group. And what we'll work on in the meantime is thinking of. What would a deliverable be for that working group? All right. I'm going to move this around a little bit. Okay. So the next item here is. Who brought up the, who brought up the, who brought up the, who brought up the, who brought up the, who brought up the, who brought up the, who brought up the, who brought up the, who brought up the, who brought up the, who brought up the, who brought up the next steps for the operator framework, TLC, vote. Um, Dad. What does that mean, Brian? Okay. So, um, actually I do have some news. Uh, so yesterday, um, Alice and I worked through, um, we have, um, One more set of comments that will be sent out today. And then this will be in the TLC's hands. And then we'll try to figure out and let between either you or Diane know, hey, this is what's going on and this is whenever this photo is going to happen. But at a high level, actually, I'll just read what we have here. We are going to agree to accept this from the SIGAP delivery point of view, but we had a couple of action items. And one thing that we need from the CMCF is that whenever, so it's easy when a singular project and that lives in a repo that actually says, hey, we want to be in a sandbox or incubation. That's an easy decision. It's also easy whenever you have a project like open telemetry where you have multiple projects because you're going to have a repo for every single language that you're trying to work with. What we've run into with the Argo project and with Open Framework is the Open SDK. It's OLM, it's the operator registry, it's operator hub. So there are four things and now the guidance that we're trying to figure out and we don't think this should be a blocker is how do we proceed whenever we have these projects that are not just one thing, but they are a suites of things. And I don't think it should be blocked just because it is a suite of things because life is complex and this actually solves a big problem. But we want to remove that uncertainty from this whole entire discussion. So those are the things that we are going to bring up. Let me see here. Yep, that would be it. There were other things on the list around CSV. When we suggest this, are we actually getting into standards work? But we decided not to bring that up. So that is for your point of view, Daniel. That's what's coming on. So we'll submit it today and then we'll be on them. And then whenever our next TOC meeting, we'll make sure to bring it up. Hey, let's get this front and center. Yes, Matt. Well, I was just going to point out the next TOC meeting will be the first TOC meeting for the new TOC that's in election. And if it's anything like last time, this may not come up or have time to come up. Just as a warning, it's kind of that transition point. There are several members who are stepping away, who are not running again. And last time they let them give advice and they talked through a lot of things. And it was a very different kind of meeting for that first meeting because about half the TOC is being reelected right now. Yeah. And we also have another meeting, too, where the TOC participates. And we have a CNCF six chairs meeting. So I'll work with Amy to figure out what the best option is. So we can move this along because no one likes to wait. No, it's just kind of a bump in the road, hiccup time where the election cycle is going. And the other thing is when you're looking at the suite of things, when Helm came in, we had Monocular and Helm and a handful of things that came in as a suite. Well, Helm was the primary thing. There was a whole supporting system around it already that came in as well. So if you're looking for something that had more than one thing coming together, more than one repo, different languages, it's kind of a suite of things, Helm is an example of that happening. All right. Yeah. Well, that's definitely something that we will cite as, hey, this is proof of something that already exists. Okay. Let's see. All right. So I actually did have another item here. I know there were a lot of cloud native built pack people on the meeting. What we are waiting on now is word from CNCF on that. I actually, Alice and I, when we talked two days ago, I did bring it up and say, hey, what's going on with that? And find out we are waiting on CNCF. So my action item out of this meeting is we will respond back to whoever submitted it. I think that was Terence Lee. So we will actually respond back. And so hopefully by the end of the week, we can have some update for you for your project and what's going on with it. Because actually right now I don't know. So any other things for the agenda? Because if not, this will be a short meeting today. All right. Well, you all are super quiet. So we have a few things coming out of this meeting. So we have the follow-up for the AirGap workgroup. What will come out of that is another message saying, hey, we're still on it. And we need to work with, we need to figure out exactly how we create a workgroup for the operator workgroup. We need to figure out what a goal for that operator workgroup is. And we'll be sharing on the mailing list and on Slack. And then for the open framework project, what we need to do is get this in front of the right people. And we'll figure out the best way to do that. To say that, hey, the sick app delivery is behind this. And also for the CNAP, or not CNAP, the CNB group, what we're going to do is figure out where that stands. So I will say that there's, I really want to think the projects that went through this, like the ARGO team and the CNB team and the operator framework team, because the questionnaire that we created for this process, I think the TOC is actually going to take it up and make it their standard. So that's a good piece of news out of there. So without that, my list is done. If there's nothing else, we can move on with our days. All right, sounds good. Let's move on. Thank you for showing up, everybody. And if anything, we're on Slack, you can ping, and we'll try to figure out what's going on. Have a good day. All right, thank you. All right, bye.