 Hello everyone, as always, while we wait for other people to join, don't forget to add yourself to the meeting notes. And also if you have additional topics that are not yet on the agenda, feel free to add them to the agenda right now. Let's wait two or three more minutes for people to join and then jump in. Hi everybody, this is Michael from the Harvard team. Alloy, we had a quick exchange. I ended up not adding Harvard to the agenda since we're going to go through a sick runtime first for our graduation review. And if there is a need for sick app delivery to look at Harvard as well, I'll just come in a future meeting and discuss it. That's fine. So just ideally just post it in the agenda slide if you want to do it and just think as quickly. I think we also pretty full for today. So that's good. Thank you. Appreciate it. I'll just hover around and listen to you guys. The first agenda I think will be the logo ideas. I think that's also going to be a quick one and so maybe even can jump there. Yeah, landscape everybody wondering. At least we will go. We are going to make it a quick one because we are not going to like have a lengthy discussion here. Next on the vote of some sort. Yeah, landscape first draft. Thanks. I think Jeremy added this one. I hope not. Oh, you did not. Well, that was my idea maybe but I think we don't necessarily have it yet. No, I haven't had time to dig into that yet. So maybe we can postpone it for the next meeting. Let's do this. I think that there's a strong interest by the operator framework. Team to look at that your diligence and make some forward there to think some people are in kudos team and operate the framework there as well. So focus on most of the meeting. And move, maybe operator definition then as the last action item for today, depending where we will still find time to do it or not but it's like at least to give for the operator framework intelligence at least 20 minutes here. And as we have five minutes in let's jump in with the logo ideas. Yep, I have dropped the issue into chat. And sadly, like everybody gets to be able to just pull the PDF up but I wanted to hear people's ideas about what they were interested in from the designers kind of first. There's a lot in here. Yeah, let me just quickly share that. Oh, thank you. I'll make it a very quick round. So there's like a couple of ideas in there. Ideally, you name what you like most and what you like first. I hear no immediate screams from the audience. So I guess that's good. Yes, I think I love the last one. It's very cute. When you put on a tissue immediately, I think, yeah. I'm wondering how an aunt got picked to be in these and aunt doing the work of carrying Kubernetes. I think Diane was no Diana was bees not ads. So one thing that I want to be able to kind of move us away from is if we've got just Kubernetes in here, we're going people are going to think this is a Kubernetes SIG. So I'm more inclined to be able to put in the CNCF logo in here where we have the Kubernetes logo, but that is just me trying to be able to avoid confusion. I like that because apps and apps delivery is a lot more than Kubernetes and so and the CNCF is a lot more than Kubernetes. So I would like to see no Kubernetes logo in here, but instead the CNCF one. Yeah, I think it was also what we were working on the whole chart that we're going to be obviously Kubernetes is at the core but we want to move beyond Kubernetes. And personally, I can't see ships with containers anymore. You're over it. Yes. I had my third dose over the last five years of ships and containers. I feel you, I feel you. I kind of like the ones that are the presence because I like presence. And so it's like, oh, sick at delivery, we bringing presents. For continuity's sake, nearly every other SIG that has currently gotten their logo has chosen an animal. Not required, but you know, precedent mumble. Yeah, from the animals. Yeah, but our storage one is a clam. Can we really say that's an animal? Yeah. Okay. No, that's fair. The, the peace stuff is kind of interesting. You're bringing peace. Yeah. Can I, can I say. Go ahead. I was just going to suggest we've got all of these. And I suggest two things. One, can we get it with the CNCF logo in it instead of the Kubernetes one, because I don't know how it's going to change look wise a little bit like what that would mean. And then we do some kind of voting kind of quarter. Otherwise it's easy to set up so we can see what comes out of it because if we sit here and talk about what we like and don't like, it might be easier just to see them and then just have some kind of vote and get it out of the way. Yeah, so the way that we've run this process with the other groups is like, we have now just done our first round of design meeting and we've gotten feedback. So then go back to our designer letter now like the, here's the things we should change and then we'll probably break them into groups that people can like vote more directly on and then we'll move from there. Yeah, so, so my initial proposal is let's remove the ships. Okay. No, no, no Kubernetes logo thing because that doesn't actually help us define what the CNCF is. Anything else that people are like, down with trains or something. Well, I'm not done with trains. You just don't want to see any containers anymore you're over like the rubber boats. We can also have serverless so that would make it. The ants remind me of Gluster and maybe that's just me but I don't know. Okay, I will take this back into our team in here, watch this space for more. If you have any strong strong feelings that were not expressed in this particular meeting please go ahead and put them in the GitHub issue. Yeah, I think one thing we had really what the bees and like bees building a beehive might still be an interesting one for delivery because it could be like the individual microservices. Adding bees no ships. All right. We need to done this one. Carry on. Storks are kind of interesting to. All right. So, I think that's done for this action item so we go into the next round, just putting it into the notes. Yeah, but first of all thanks for taking the time for the logos it's Yes, I'm just starting here we move ships and containers. And we like animals. Oh, there is a note about how the GitHub logo issue is locked to only contributor. Aloy, you did it. What's up. I locked it because we had the proposals in there I can unlock it. Oh yeah unlock it so people can really come in. Because we wanted to look for the proposals and that's why it actually was locked. I think yeah after doing my GitHub advanced course I can now also unlock issues. I'll take care of it after this one so you don't have to watch my unlocking issue. Super. Thank you. Then, I think we can move on so do we have the redhead people on the land as you saw Daniel already. Yep, we have Aaron and Rob, I think as well. All right from the. We are lucky by the way because today we have a special guest with Michelle so even a to see is watching today. I'll see we have Lee here and mature at a Brian already joined just said he's going to join here. Oh, okay. It's too many. The good news is it's a lot of people in this meeting already so. So the idea was to go over the submission for the operator I just have to bring it up just give me a minute. I have to admit that I do not have time today for a number of reasons to have to have a look at it and go through all the comments but I think it's a good use of our time to do things here today. Let me just share it with everybody. And obviously also paste the link to the chat. Sorry, still working out. So here's the link to the document. So yeah, as is as I mentioned in the last meeting we now have this due diligence framework and redhead was kind enough to say well let's openly discuss what we're working on here and this is more taken what other six have done as well. And I would just propose to go over the here. So the first question obviously was whether we want to separate operator have from the operator framework. So I think the bigger understanding from the redhead teams that they kind of fit together tightly. Yeah, I actually so I actually agree that they do fit together tightly. So we would want to, we would want to deal with all three with the with the with the whole thing rather than trying to do it. So the whole three being operator framework operator hub and OLM. Yes. So this does raise a couple of questions that were brought up by others. For example, the operator hub is tightly coupled to the operator framework and OLM, if I remember right. And so then there's other operator based projects that are going through this sig such as kudo, and that doesn't use it's a different thing from the operator framework. So how does it fit into the context of operator hub, if it's not using this like how does that all mesh together in a nice cohesive way for the C and CF. That's one. Oh, go ahead, please. Yeah, so SDK and OLM and operator hub operator hub and OLM are different conversation but the SDK is just a method to create operators. You can create operators with cube builder or kudo, or yeah, they're not they're not combined so that they're, I don't actually have an issue with that. So if they all come in under one project and one project governance in one thing, what does that end up meaning going forward how does it all work. Because right now yeah OLM and operator hub are tightly coupled. So what does this mean for a different kind of operator even if it's from another CNC of project like if kudo comes in as a sandbox project. What is something like this mean and how does that go forward. Yeah, that should actually be fine and there's a couple of things that are that are going on that will actually make this better. So operator SDK is looking to replace their go builder with cube builder just in general, and they're going to keep their helm, and they're going to keep their ansible their ansible operator builder. It still leaves lots of room for products like medicine or kudo to come in and build operators, we would just have to bring in those controllers as as dependencies whenever you want to install those and that's and that facility is already there. Go ahead Brian sorry I didn't mean to cut you off without your. Oh no no go ahead go ahead I'm done. This might be a good time for me to comment in on from the kudos side. We have some comments in the operator framework draft governance and we did we did some talking at at cube con, because we're also working on introducing like a another interface as well for operators being able to depend on each other called Koi. So what we added to the PR one in the operator framework governance or draft was actually getting getting some more projects in with the operator framework umbrella so like our test tool kudo itself so that you almost have like that approach and making sure that all these projects interoperate well together. So, so, you know, the, if you go get some time go look at that PR, you can see like where we're almost like trying to like pull out multiple projects under a large umbrella and like cover operators as a whole. I think that's a I think that's a great approach. Yeah, so that work was kind of delayed with like the holiday transition but we're going to pick that up here really soon working with the kudos folks this is Rob from the operator. Yeah, those are from from my point I think it's totally fair for one project to to run their own infrastructure for their own delivery mechanisms also for operator hub. I think the main comment is and as you mentioned going forward that we obviously want to have title collaboration between projects obviously but just because something is specific to one project for me does not necessarily mean we can't we should push back on the project proceed being in CNCF actually that that's what then part of the collaboration is in CNCF should be about. The only thing I would be worried about if an operator operator could only be used an open shift because that would make it tightly coupled to one vendor technology but this is not really the case. Yeah, definitely not. I'm doing work and I don't work on open shift at all and where I'm using OLM and operator hub and and I don't use the operator SDK and it all works just fine. So I want to point something out right I'll give an example here if I go right and operator and something like rust and then I package it up as a helm chart to be installed today it cannot be listed on operator hub because it doesn't use OLM. So the situation with that is that for operator hub IO to work. We needed kind of a common definition of metadata that's rather than for the catalog display so simple things like the logo, the short name display name a description links to pull up stuff. And none of that existed at this time when we conceived operator hub video. And it's part of the CSV spec that OLM also uses for lifecycle and runtime concerns. And we already started looking into ways to separate this out from the runtime aspect of OLM. So we are actually we were actually talking to people that are already last year around a common format to package operators and just get this catalog style data into a common spec, and then separate the concerns from the runtime aspects of things like OLM. So that also kind of dovetails with the application specification that's being developed under Kubernetes and even the helm metadata that you can get in a chart in YAML file. There's a lot of the metadata out there, but but my point comes down to is if we look at this as a whole right I'm not trying to like cast blame and get into architecture. But as the SIGAP delivery I think we're supposed to do like do diligence and look at this from a CNCF perspective. And so what happens if we have multiple say operator things that come together and and now we want to list them in an operator hub from different projects. If the hub is tightly coupled to one project with one way of doing things and other projects want to come in or do land, how do they get their things listed if they don't work the same because it's tightly coupled to one group's way of doing things. But I don't I think what Daniel was trying to articulate though is the things that are required for it to be listed in the hub aren't dependent on the implementation of how it's done it's so that they can properly be viewed on the actual website. But right now they are tightly coupled to it because it's tightly coupled to OLM. If you don't use OLM you cannot be listed. It's tightly coupled. Yeah, but that's that's the metadata. They need the metadata so you can be listed. So when you create a cluster service version, you can create it for any operator that you've created in with any technology. So just so that it actually shows up that can I use can I use the metadata and not use OLM. Can I have it in another packaging format in another way such as in a chart or something else. Oh so OLM is not a packaging format. OLM is a mechanism for getting operators installing figuring out what to install in the cluster. I mean at that point it's just it's just Kubernetes objects. But OLM actually figures out where it comes from and then figures out what namespace it needs to be in and puts it there. So that's what I understand that but but I'm coming back to implementation here if somebody packages a chart and say rust or they write a chart and rust. All right, sorry an operator in Rust and they packages it as a Helm chart to be installed. Can it be listed in the operator hub and work with everything else. And the answer I've been told is it has to use the implementation of OLM. So unless you also have OLM installed in your cluster it doesn't work because you need this. Like how does this work. Like how would you make that use case work in order to do that for operating that's the question. And it's perfectly valid but I think it's also just a logistical question but doesn't also beg the question that could we take an operator that we've created in our sense and use it the same way we use Helm. I mean the idea is to have different implementations of the same things and enhance the ecosystem. I totally understand that today there are a lot of operators packaged up as Helm charts and there are people who prefer to do that. And if operator hub is the destination to find all of your operators. And now we're saying that a set of operators that people exist and use and work with today cannot be listed in there. Because they're not using a certain thing it's not really a full list of all the operators out there. It's a set of those. So Red has actually gone above and beyond in this respect and you can actually supply a Helm chart to operator SDK and it'll build all the metadata out for you. Okay but you still have to use operator SDK. You still have to install OLM in your cluster and it has to work with OLM to be listed on the operator hub. And so today with the many of the charts that are out there that do this unless they make modifications even though they do operators they can't be listed in operator hub. And so is it operator hub or is it OLM hub. Right and this gets into if we look at it systematically across the CNCF not just like if this were the operator framework hub or something like okay it's very scoped to this project it's very scoped that way kind of the way the Helm hub is. But if it's listing all operators everywhere and then we're artificially limiting some of that listing and I can understand there's lots of technical constraints in the way it came to be and why it came to be and I'm not arguing that. I'm just saying as a CNCF and it wasn't me who noticed this right the TOC brought this up in the first place and I can't remember who it was with somebody said hey what about this stuff and they actually talked about all the hubs right because right now there is the there's a security hub. There's a Helm hub we introduce operator hub there's actually effort working on to see how do you consolidate into one hub and I know a couple of the folks Diane and folks were at a meeting at Kubcon on this. They're looking at how do you consolidate everything into a single hub right like why do we need a cloud native security hub. Why do we need a helm up if customers have to go all over the place or users have to go all over the place right I can see some of my operators and operator hub I can see some of them that Helm hub what's the difference how do I navigate this what's going on. It's an entirely confusing experience but I think it was Joe beta who actually brought that up in one of the TOC meetings and so when we look at this right and we're still fracturing things with this current stuff. What what does that mean and how does it impact end users not us project owners but the people who come to consume stuff and navigate it. I thought the whole point is not to be king makers if we have one hub for everything then I think we're being very decisive about how things should be done by offering an alternate way to do it in the alternate way welcomes. However you build it will provide an easy way that we can get it in here as well so long so we can show it. It needs to have a minimal amount of logo. The CSV to talk about the versions and what are the dependencies things like that I guess I'm. I'm not what I'm hearing you say is that you feel like there should be one hub and maybe I'm misunderstanding that. OK so two clarifications one the operator hub isn't saying anybody can build an operator anyway and get it listed. It's saying if you build and package your operator a certain way you can get your operator listed. So it is automatically limiting it's not saying anybody can come it is doing king making and then the second thing is to point out the one idea of one place that was others that was Joe on the TOC and it was a point in the TOC. So Dan the executive director of CNCF he's been talking a lot about this I am pointing out what they keep bringing up because they're not here today. Right. Can we table the the central hub for a second I think like that it's useful and it's got it's like merits but let's just table every second. So flipping your argument around say operator framework isn't in CNCF and helm wasn't and you would say that we would be on on this call saying you can't package and get listed on helm hub because you're not packaging a helm chart you're using this CSV thing is not the same argument wouldn't we will not want that outcome as well. Okay, so the helm hub is different because it's helm packages. If you create a helm package and you follow the structure for helm. Then yeah, right it's not saying it's everything that can be installed it's not all Kubernetes applications. Right. If we said it's Kubernetes applications and oh yeah you have to do it as a helm chart, then we're kind of defining the way to install all Kubernetes applications right instead we're saying this is the helm hub where you find things that can be installed with help. Instead of all Kubernetes applications we're not saying it's all the things. And so that's where I would argue it's different because operator hub is all things operators right except no it's only operators that can be installed a certain way. And it's branded as all things operators and so that's confusing friend users because they'll come here they'll say it's all the things operators not really that many types of operators can't be listed. So I mean I don't want to get us. I don't want to go too deep, but I will actually say that that that that is not that's not true. This will work with anything that we call an operator what's an operator. It's a set of CRDs zero more and a controller that does some kind of function in the cluster. So this will actually work with any of those and that's what and that's and I think that's a good thing. And I didn't have a conversation with Joe and I don't actually think he understood the project actually laid it out for him. And the way that this is the only change that I would make to what Red Hat is saying is that instead of coming in product first, I would actually come in with outcome first. The operator, the operator framework this whole thing is an operator SDK gets you started with building operators. And then there is, then there is operator hub showing operators that are that are available. And then there is OLM, you need a way to manage what operators are available to what namespaces in your cluster operator and OLM is agnostic to it's actually could technically be opera agnostic to operator hub. It's definitely agnostic to operator SDK. Maybe there's another piece of actually managing what runs in a namespace but they already have this concept of subscriptions and the other thing and operators. So this is, it's, I don't think that what you're bringing up is actually a problem. And the only reason I'll think it's a problem is because they're not specifying the technology you need to use. So it's just a bounce on top of Brian just for a moment. And, and that's that's also one of the really valuable things about, you know, Kudo and Koi moving into this like another spec for interoperability here, so that we can continue to try to get more and more inclusive as we go. And because really like operator frameworks about delivering operators right and within there is multiple ways of delivering and serving up operators to people that's still focused around, you know, Brian said as far as like it being that core concept right rather than just some delivery package right you know, Helm chart or something else seen at bundles something else here right so that's that's how I see like, like in why we're moving this way as well because yeah sure it may you know you can get the impression that that is that way for now but all the projects that we have under that umbrella would be expected to interoperate well right and be able to be served up well on in the same place. So so let me ask this then. If I if I wrote up go ahead sorry. I think maybe because we're just at the very beginning of the whole document and the whole discussion. So I'd agree that there might be changes that we want to do or work on with certain projects to be more widely adoptable. That the answer we had basically what I do we think that operator framework was operator half is something that significant enough within the cloud native app delivery community that it makes sense to be part of CNCF as a project. I think they do is everything perfect know might you have specific requirements on where the project should be moving in a certain direction. Yes, and actually governance could help us here. I think overall it is it is adding value here and we just discussed about nomenclature here what we call the operator half and other things and I think we have flexibility there we can move a project in a certain direction overall it actually does add value. And also to the other point you don't need actually oil and to be installed use operators on the operator. We, for example, dinotrace use operator have operators and not use oil and to install it. So the question is, do we consider the project and what it's doing valuable enough. And is there a value in having it on within the CNCF. I think the first one for me. Yes, it is because there's a lot of people for operators. Is there a value of consolidating it with others. Yes. If we figure out that there is a restriction that other projects have problems with to submit their operators, then this is something we should work on with the project. That's also why it would be an incubation project and not a graduated project, obviously. So that that's my my take on it and I'll say that everything's going to be is perfect right now. But do we really talk about something that's so significant that we can't allow it at all. Yeah, and that's actually a really good point. We're talking about, we're not talking about a graduated project here. We're talking about the beginnings and hopefully with stewardship from the CNCF that we can actually turn this thing into something that would be a great thing for the whole community. I mean, with that, that's why I'm actually saying, yeah, we should move forward. Are we where we want to be right now? No, there's three things in the 2020 plans for the operator project that I think would be paramount. And I could probably think of two or three more. So let's let's just get this project started now, rather than say, you know, baby with the bathwater type thing. I asked a specific question before and it's an easy way to shut me up. I said, if somebody writes a an operator in rust the controllers written in rust, and it's packaged up as a helm chart. How could it be listed on the operator hub, and I've been told in many of the conversations that it can't be today. If somebody can tell me how to do this, right? Somebody can tell me how to do this. It's an easy way to shut me up because we can take many of the operators we have listed over on the helm hub and say it's a legitimate operator. How would it be listed? And it's an easy way to shut me up if somebody writes up here is how you would do it. I can go off and replicate it. I think there's two ways. One, you can run the helm SDK command against it and get the everything you need all built up and packaged. Or if you think in that helm chart, it's really, there is a container, you package a container with rust code in it. There's deployment and RBAC. You can provide that in the OLM spec format and CSB and listed on operator hub. Okay. And so there's a way for me to package it and run it without using OLM but have it listed. You can package it. We recommend you use OLM to run it. You could also, you know, if you wanted to process a CSB file yourself and pull out that information, there's a deployment and an RBAC file listed inside of that. Yeah, but lots of the operators that I deal with don't have anything to do with services running in a cluster and many of the things for OLM. You know, they don't make sense for a lot of the uses we have operators. And so it's, it's easiest to just install it as a helm chart. And so, I mean, really, and there are a lot of people who do this. I need a way to package it up, get it listed and run it with or without OLM. And if I could see that how to do that, that would shut me right up, right? Because now I see a way to list operators in the operator hub that isn't tightly coupled to this implementation here. There are people who do run operators in different ways. And where I work, we do. We don't, many of the operators we run, OLM is overkill for. We don't need it, right? And so how can I do that with things that are legitimately operators and other people do too? Like if I have that, it's an easy way to shut it up, meow. And anybody else who's like me who sees that other view. Yeah, and I guess, I mean, the, I think we could work on that experience. I think that could very easily get added into like the 2020 scope. But I guess the question is, is that a blocker or not? And I think that was the point we were just talking about. Yeah, I agree with you. And I would like for, I appreciate Rehad being open and I was if there's good enough community interest, I expect you to move in that direction. And I might suggest when this goes towards the TOC and it's in the plans that this experience is probably called out because otherwise it'll be discussed on the call. If not by me, I wouldn't be surprised if others do. But it will come up. And so if ahead of time you say our plan is we're able to handle these other situations. This is what we do today. This is what we're planning to adding so that the operator hub isn't just things that use our method for installing them. Other people's ways of doing that can be listed as well and used. That would go a long way. Okay, let's let's let's take this one down and put it in there. I just want to ensure that we can work on some of the other feedback of this one as well. So matter not trying to shut you down and just trying to get through the document and some of the issues in there. Do you want to cover the whole thing or do you just want to go through some of the. I'm just looking at the questions whether there is any other one I was just asking about and several okay because this is the more related to vendor independence. Yeah, so the answerable there is just the open source and school project no product. On the open source question I had wanted I at least did not but just looking at the repo that wasn't highly clear to me is when I look at the operator hub I owe a GitHub repo it looks like it's only the website but not the actual operator hub code. The website is the code. What do you mean like but I think that the other discussion we had is that there's over some some containers running in Kubernetes as a back end or is or do we get anything wrong here. That will be the case in the future right now it's basically a static website that leads the content of the repository once into a Node.js back end and then serves this up with the UI you have today. We do have a database format in place that we are looking to use. So there are no inconsistencies anymore between what it's in GitHub what's in the database format and that will run in a container but right now it's literally once the site starts up. It close the repo. That is called community operators. That's where the metadata about all the stuff you see there is located and operator have I owe the code you've seen this is the Node.js from then. Okay, that might then resolve my confusion. Okay, I can remove most of these comments here. Yeah, Brian you had the same comments. Now we're just for clarification for posterity. I just want it wanted to be written down like that. Because I've actually went through and installed the whole thing and it would just want to make sure that was clear. Okay, like the domain and the infrastructure as well as the code is that we just want to make sure I understand. Yeah, that's that's actually what I was asking so you have operator hub that I owe is that going to the CNC f as well. I am you'll that is it that they all are part of the operator framework. Yes. All right. Cool. That's that's just what I wanted to make sure was clarified. That's all. Yeah. If they want it. Yeah, obviously you have your customer examples in there. I mean we obviously know that people are using operator have your healthy number of committees you have answered. Harry you had a comment on the release site is here and on all and other components. Are you here. Yeah. Yeah. I noticed something in the dark because it seems that the OEM has totally different really cycle with the operator hub. I don't know if there's any reason for that. OEM and SDK I think were the ones that you called out in here are kind of like we talked about can be used together but don't have to be used together so there's no reason for their releases to be synced up, as well as the website code once again is just reading that community operators, you know bundle of metadata so it's like the hundred or so operators that we have listed, and that's changing day to day as folks are submitting things. And so all that's kind of all unrelated and doesn't need to be synced up too much. So, so the question is, if I am a developer who is writing the operator right so how can I use OEM specifically. Is that possible without open SDK and open hub or they have to be tied to all the three, I mean all the three projects has to be tied to be used together. Oh, you can, you know, build the SDK and out pops a container that's an operator and you can just use that directly. If you have some SDK that you built yourself like some folks have built some Java SDKs that are not related to the framework you can use those. And you can stop there if you wanted to, or if you want some of the life cycle benefits of the life cycle manager the things that Brian was talking about earlier subscriptions and kind of more of a multi tenant environment and that type of thing. Then you can start using the, you know, CSB format of the life cycle manager and do all that. That content is the one that is more tied to operator hubs listing like we talked about. So they don't have to be all connected. Okay, I see. Yeah, this answer on says my first question. The second question is, it seems that the operator SDK OEM and operator hub actually have different material labels from my perspective because. They're actually solving very different problems. I don't know if it meets the goal of where all of the incubation quite here and I think we may raise a discussion around that. Yeah, I guess that's a good point. I think we should have a discussion. Where do you, where would you label them today? Sorry. Where would you label each project today? Yeah. So from my perspective, I can read that operator SDK is pretty, pretty mature but for the OEM and operator hub, I see it's still at early stage. I can see that a lot of operators has been listed in the operator hub but for OEM, it seems there's adoption is not very, I mean, it's not comparable with the operator SDK. Am I right? Or I just made something. I think that's one of those ones because it gets installed on folks clusters. It's harder to gauge than the SDK which you can go see how many people have cloned it and you know that type of thing. So I think that's where it's a little bit harder but there's definitely thousands of OpenShift clusters that are installed with the Lifecycle Manager. Yeah, that's what I would bring up. I mean it's installed by default on OpenShift and I know lots of people are using it here about all time. I see. But we just don't have any visibility into, you know, just folks that are just running clusters, you know, all over the place. So we don't have any insight into that. Yeah. And I'd also like to point out, well, there's a lot of OpenShifters out there. It's important that the CNCF not play king makers here and we have got a lot of member CNCF certified distributions. And so we shouldn't go off of OpenShift but everything should run off of what is it? Compliant Kubernetes clusters. So that is actually a really good point. We talked about this at KubeCon between our two teams. So we're pulling a tool out of Kotl, R conformance and test tool to try to help facilitate that for all of Operator Framework. So that'll absolutely be a part of this whole thing. Yeah, testing huge component of this. All right, quiet means Alice, we should move on to the next item on your list. So before we move on, what the next step is for this due diligence? This is Diane Mueller, the one that will always ask that question. Well, we get back to the TOC with a proposal or more or less accept no accept and then the TOC will decide whether they want to have another presentation or not. So does that mean you send it up to the TOC, this document up to the TOC and ask them to take a vote on it or do we do another presentation to the TOC? I think it's eventually up to the TOC how they want to have it, whether they want to take always our proposal or they want to have an additional presentation. Okay. So when will that send up happen? So usually project presentations are scheduled for like the thing the first Monday of the month or the first week of the meeting of the month, Michelle correct me if I'm wrong. Yeah, so I think is where are you all on technical due diligence about document? Is that completed? Yep. We believe so. I would like to point. Go ahead. I was just going to point out the next first meeting of the month is the first meeting of the new TOC. And I'm not sure that that will be the same as all the normal ones because we are in an election cycle this month. Still, it really would like to we've done one presentation to the TOC already so we'd love to get this, get this in and out. Between Harry and I and myself, we will try to move very quickly on this. Much appreciated. Thank you very much. Yeah, the only, I think a bit of an open question for me still is, when I look at the repos and unfortunately GitHub is not the best place to necessarily is out. Graduation material is like had really having some, well as contributions from at least to organization, which is very vague. I would like to see a supporting statement that you have like really substantial contributions from from tour organization because most people right now are from red heads. Well, this is not a formal requirement. I think it would. I think it would be good just as part of the review. I think that people who like to go to operator SDK the top active contributors are record people right now. Right, but I mean, I don't want to put that on them because they're not going for graduation right now. That's, that's a, that's a later step. Graduation. Yeah, that's right. Yeah. And really the whole push to get it into the CNCF is to get it more open and more more contributions coming in and work more people collaborating with us. So, and I mean it's good. I mean, even on this phone call today we had a kudo project said hey, we're working. And so that's good news. I think the other comments like everybody but everything from our side so far has been addressed. I think we are pretty much that document so far and yeah. I think this we have us can can then talk and move this forward to where you see Lee is on to get it to a TV. I don't have any question to Brian. Harry anything from your side. I think then we are actually on top of the hour today. My love the hour but not the end of the meeting. I don't know where to make sense to start anything else on the agenda. Today, I don't think so unless somebody wants to bring something up that can be quick and move the other topics to the next meeting. Okay. All right. Yeah, then thanks everyone and talk to everyone. Thank you. I think, thank you.