 Hello, good morning. I am not going to lie this calendar change date really threw me for a loop. I'm glad I didn't have anything else going on right now. So, before we get started, let me let me myself a little bit better prepared. Good morning. Good afternoon. Yeah, Jared, that is exactly right. All right, one second here. And from what I remember. Yeah, I think it's on the phone. All right, so almost here. Give me about 30 more seconds and I will be ready to go. All right, now I'm ready to share my screen here. And welcome to the February 19th CNCFC, it's like a delivery meeting. I'm Brian Miles. And today we're going to talk. It's a fairly short agenda today, but today we're going to talk about Kudo and is it it's Kudo and him graduation requirements or questions from Matt Frina. So, to get us started. Jared, are you here. Yeah, I'm here. All right, I'm going to stop sharing. And you can take over. Thanks, Brian. Let me switch over. Is that size okay for everyone? It's nice and big for me. Oh yeah. Great. We love that. Right, makes it super easy, except on dark screens. So yeah, I'd like to chat today about the Kubernetes universal declarative operator, which we have proposed for the CNC of sandbox inclusion. And just to give you an idea of who's chatting at you today we have we have a good size Kudo team but I'm a senior member of technical staff over at D to IQ. I work on Kudo I work on Kubernetes for a long time, and I'm pretty active in Q builder and some other Kubernetes work so fairly active there. So I want to start off by telling a little bit of a story to kind of build up the state we are in in Kubernetes native development building things for Kubernetes building things on top Kubernetes. And if you look at what Kubernetes is, it's a you know it's declarative data that's operated on by a series of controllers and most of us already know that this I'm going to go quick but it's, and what I'm doing here is building up a little bit of the Kudo view this, this story. Like what's a controller right and a controller is really a really a reconciliation loop of, I have an actual state in the desired state, please advance me towards that state right. So, lately we've had a lot of discussion around operators and what one operator actually is and, and you know we had a long thread we had a long discussion here about that. I like this particular definition, but I wanted to pick this one to enhance upon it a little for the perspective of why we why we ended up creating Kudo. And that is, you know, we know what a controller is and so why not just call them all controllers and and what's this difference in an operator. And it comes down to controllers reconcile state and they don't care what the underlying workload is if you think about the controller manager and Kubernetes, it cares that it has a deployment it doesn't care about what it's deploying right. And that goes for any resource that that is maintained by that, that controller manager or the scheduler or anything else. And so controllers plus resources doesn't really make sense in general terms. And one thing I want to talk about and harp about because this is this is very central to the way Kudo looks at the world is it's this idea of application awareness and it's how how your application exists with with itself with your your cluster how interacts with other applications. And that's one of the things that application does and how how the tooling we use in first or influences how that application operates right. So, so for example for application backups right now in restores we might use something like Valero, or they're scaling there's a couple other things that we need to do. And so what we can say is then is from the from the perspective that I'm talking about is an operators control it's well optimized to the requirements that you know me. So, we set out okay great Jared you've convinced me let's operate all the things right, we want some Postgres let's write an operator we want to do some migrations right and operate backups, Kafka topics we're going to operate everything. We get into this problem where if you start to span this out right now too much, you're writing a lot of operator code for increasingly little returns. And so if I say I wanted to, let's turn my Rails app into an operator that had a database with an operator to do it. It starts to be I'm writing more and more lines of operator code for less and less less domain specific code. And this is kind of a prolific or a proliferation problem that I want to I want to talk about more but to give a really concrete example look at the elastic operator elastic search operator, and elastic is a massive job app it has 65,000 lines of application level code for the operator right that's not including dependencies on controller runtime or client go, or a million other dependencies that you need to interact with the Kubernetes API server. So you get all this setup right you've written your operator. And you think everything's great. And then Kubernetes one dot 17 drops and removes deployments view on beta one or something changes right and now all of your dependencies are out of date and nothing works with each other. And it's not just a matter of, you know you see this and I'm done and you do this and I'm done, and you do this and you're done, you actually have to continue this change management over time and a very large scale of something that's not your domain if you're someone just trying to deploy, it writes me that deploys elastic on Kubernetes in a very Kubernetes native way. And so, you know, this is not very maintainable and the problem here comes down to an accessibility problem. Right. Right now requires too much Kubernetes domain expertise you need go developers who knew Kubernetes very idioms very very well, or you need to invest a lot of time to learning those idioms in order to write an operator. Right. And operators are potentially useful beyond the category seen today. And I want to harp on that a little bit later than something we've seen in kudo that that actually surprised us around about that. So what we really should be able to do is enable new pathways for developing native applications on top of Kubernetes that interact well with that with with the post environment that it's in. So this is where I want to introduce kudo the Kubernetes universal declarative operator. It's right now a tool for application sequencing and resource ordering, but it's a lot more than that. It's really about shipping in application with its runbook. And I'm going to open chat just so I can keep track of if there's any questions. That's not right now perfect. And really what we're trying to do is promote the application awareness and use application native tooling, instead of rewriting my SQL dump and go for every single operator out there. That's not really the right tool for operating on the every operating the planet and we there's a very strong distinction we have of when you should use these sequencing tools versus another tool. But if you're doing a lot of sequencing that a lot of these operators are doing for complicated applications. It's a great tool for a lot of that. And there's no reason these things can't interoperate with with other operators that do smaller more focused tasks. So we've had a very strong community governance and roadmap and really kudo is just kubernetes and we we try to use this a lot because what we're doing we're talking about is writing operators using CRD is and taking kubernetes. That kubernetes sort to the hills by saying everything looks like a kubernetes object and use it as much as possible so when we when we go to make decisions where we we try to ask, how do we do this in a kubernetes native way with that kubernetes resource data model. If we look at the kudo architecture real quick. Right now we have a set of crds and a controller that you operate on that defines an operator and operator version and an instance that that will effectively give you say an instance of Kafka for a given version. And this all goes out to a repository and an operator now when I say repository don't mean catalog. We don't really have a distribution mechanism at the moment and we're working on that and we're working with partners in that space to figure out what that distribution mechanism should be in a way that works well with other CNCF tooling. But but we do at least have a way where it looks like the helm charts of now where you can get an index and grab an operator and start using it as of today. So we have a cube CTL plugin that brokers all this, but one goal is is, like I said it's just Kubernetes. So we are one of our one of our aims is to anything that's done in this plugin should be done be doable with raw cube CTL. So if we look at what kudo is today. We have a stable and generally available version of kudo that does some declarative sequencing of resources, and can run deployments updates upgrades and some custom plans. So if you want to do a backup restore you can you can view that sort of functionality now. So that base core core core functionality stable. While we work on one dot oh features that are really centered around. How do we make life easier for both operator developers and end users. And we're shooting for a one dot oh by a cube clown China. So in progress and play or planning for that right now we have user defined commands with the kudo CLI. So whereas we want everything to be declarative we recognize that can be hard for end users. We know what one thing is to be able to add in sub commands into the kudo CLI so that you can say cubes cuddle kudo backup my SQL right or add topic to my cough instance. Under the hood that's going to be a CRD but we we at least offer that imperative shell to make some scripting easier. We're working towards graph based sequencing sort of resources. If you can think about terraform but apply to Kubernetes CRDs. That's what we're talking about here so that we we can get out of manual dependency management and allow kudo to really do a bunch of features for you around sequencing and ordering, as well as drift detection and and expiring the right areas of you up when you go to update. We'll be doing some automatic sandboxing a big one for us a CRD schema management and declare your day to operations so right now back in the architecture slide you saw we had an instance. We're working on replacing that where kudo will manage the schema for various CRDs on the user's behalf. So instead of creating a topic via the Kafka API, you would create a broker CRD and have a create update delete plan that then forces everything possible to be declarative and represented inside of Kubernetes and you could, you can take this pretty far we want to see how far we can drive that before it becomes a problem we've already identified some areas where you need that imperative hatch right a restore of your data is really hard to make very, very declarative, but a backup. Instead of declare I want to backup kudos trying to take the approach of, hey, I want a backup that's no more than 24 hours old kudo plan figured out. And so that's what we mean by declarative day to operations drift detection I kind of I kind of mentioned this but really it's all about running plans and response to events. And then some features around support support ability and interoperability with the entire ecosystem we want kudo operators to be able to easily work with other operators. Whether or not they're written in kudo or q builder directly or operator SDK or whatever else. So just a quick drop into the our community so far. We have a lot of members in slack we have a lot of stars we have a lot of contributors. Everything we do is out in the open open governance and we follow the cap process since the beginning for enhancements. And we were the first operator focus tool in the Kubernetes podcast. We found out that someone back in a few months ago put us as the top recommended tool in the Kubernetes operator docs which was a pretty cool thing to discover. We have an upcoming workshop we're talking about all over the place and we have people who are not us even writing blog posts about this so we've started a flywheel effect we have people interested. And we have people interested not just writing their databases but also orchestrating microservices large large microservice applications using kudo and so that's that's what I was talking about earlier when I said, you know, people are wanting to do this for just beyond run my my Postgres right people are looking at this for their Rails app or for for their other tooling as well and building out a cohesive ecosystem. So we have a bunch of operators so far, both maintained internally and with others, and we have a bunch of users in the community or contributors in the community. You know, these, these, a lot of these companies have either been contributed directly, or have have put in feedback on caps, especially around our support bundle process and others, and we have a lot more users, but I wasn't able to get clearance to be here in time. But they're in our community they're active they're asking questions and using that tool to build out both data operators and microservice based operators internally. So looking at kudo in the CNC ecosystem there's a bunch of things that we want to bring bring out and and and there's there's reason there's value we see in some of the stuff that we're working on with other people in the CNCF and for the community at large. So what we're working on is the Kubernetes operator interface and what that is, and I'm going to post all these slides to I wanted to save some time for discussion, but really what we're talking about is a specification that enables compositions of operators and other tools so that we can start building ecosystems right and building tooling that consumes that so that end users don't have to learn a new tool for every single operator or a new way of interacting with every single operator, and operators don't have to manually interact with each operator. If you have a cough operator and you want to get a connection string out of a zookeeper operator. That's what co is attempting to solve here. If you, if you want to write a CLI tool, or if you want to write a UI or dashboard that that actually consumes the behaviors of an operator this operator can do a backup or restore. And so it's really important to know that this is really supposed to be not be competitive it's really supposed to be compatible with other specifications that aren't really covering this particular use case. Another one that we've talked to a lot of people about and we have a lot of users of is as cuddle, which is our Kubernetes test tool. And it's a declarative framework for writing conformance and EDA tests for Kubernetes resources. It's based on assertions we have a lot of companies using it to test really anything on Kubernetes, but not just operators and not just Cudo. And for us, we, the reason we developed this was to enable like conformance and certification matrices of various distributions and various Kubernetes versions and different operators that you can quickly at a glance, see that this operator works on these versions of Kubernetes and not these versions of Kubernetes and also determine how how mature how many how many different, you know, features on maturity model that these operators supply. Right now, the best way to use that is in the, the, as a sub command and cube cuddle Cudo, but we just moved it out into its own cuddle repo. You can totally say cube cuddle cuddle if you really want to that's what I do. But it will be, we're working towards a first release of the standalone cuddle as a tool. We have a we have a lot of community stuff we're working on the coin cuddle site I think they're just redirects for now to the repos or they're, they're not but in the coming days those two sites will be up. We've got Dev is up, we have Cudo on the Kubernetes like we have a GitHub. And, you know, there's a lot of reasons that that we think we can bring a lot of value into the CNC sandbox and and and running this experiment out in the open. And so what we really want to do is enable some really public experimentation with operators but also conformance and certification of workloads on top of Kubernetes. We really want to align that application delivery with other CNC projects and work with helm and others that get in to establish standards for distribution of, of workloads on Kubernetes. We really want to provide a really lightweight mechanism programming model for users to develop these Kubernetes native applications and operators. Like I said, Cudo is not the end all be all tool, but we think there's there's a room here for a lightweight tool that makes this a lot more accessible to people who aren't Kubernetes domain experts. And then we want we really want to bring this both our tooling and our standards and advance that to incubating and graduated as the project involves or or get some of these integrated into Kubernetes directly, depending on that tool. Connell might be a great thing for sick testing to eventually, you know, have some involvement there but but we want to experiment that under the CNC of sandbox which is, you know, it was mentioned there that a lot of things going into Kubernetes incubating is appropriate for CNC of sandbox. And then we want to solve some IP concerns that we've had with some potential contributors who are really interested in these problems as well. But but for what reasons, whatever reason, they're either not comfortable or their employer won't let them work on non CNCF projects and so we want we want to lower the barriers of entry there for a lot of people who we know are really interested in this problem. So, you know, if we look about kudos all about it's really about enabling teams to build operators in a very accessible and maintainable way. And we think inclusion and CNCF sandbox grows that mission. And with that I'm Jared Dylan, we have a few other members of the team here and thank you everyone for your time. All right, thank you, Jared. So, did you say where we can go see more about this or if you have any video. I can reshare the screen kudo.dev is the a good entry point with getting started in documentation. It'll lead you into the repo. And this week we'll have the Koi and cuddle sites up we've just been extracting that out of kudo. Sounds good. Well, thank you, Jared. All right, next up on our agenda is, let's see here. Oh, I know who it is. It's, it's Matt Farina. Well, hold on. Were there any other questions with kudo or I was actually kind of curious about this, since we're going through project processes. And my question is also about project processes. I was curious. Now that kudos given their presentation, like what's next in the processes, where do they go next, what should sandbox processes expect next, what's going on here. All right, so to answer that question. This is something that we are working out with to see right now. As a matter of fact, I'm actually having a literally right this second having a side conversation with the to see about knowing this all down. But in at a high level, what's going to happen is for projects that are coming and Amy as well. Projects are coming into coming into CNCF, whether it be incubation or sandbox, we've created a questionnaire that needs to be filled out. And it's more on the, it's more on the project maintainer to get this out. And then depending on whether it's a sandbox, or it is an incubation project, then we work with Amy to get this in front of the TOC, and they do what they do. So that's what that's what we're trying to give more color here as well. If you invoke me and I'm here, so hello. Part of what also happens with this is being able to get like the review from SIG and being able to have sign up from the SIG saying yes, we recommend this or no, here's some other things that we think might be a better fit. And that part is kind of the thing that I think we're working through right now is like what happens if it's not a fit. But in the case of like, hey, Argo Argo was ready to be able to go through over to TOC. So being able to say hey, we've made the recommendation TOC now please review based on our recommendations and what we've gone through. Does that help Matt? And Jared, does it help? Yeah, I think I think so. I also saw Chris's reply in here that about SIG after making your recommendation report on Kudo. So, I guess, Brian, Harry, I don't say a lot of us, but whatever I can do to help facilitate that that and help provide as much information as you need. I'd love to chat about those next steps. If I understand the next steps is there's the due diligence template and they need to do a pull request somewhere with it? Is that right? So, I'm trying to look at the process up here. That's separate. That's something that you're looking for for graduations between moving from sandbox to incubation and that sort of thing. So, what's the next step that, say, Jared needs to do or is it not a next step for him? It's the next step for somebody else on this call. So what we'll do between Harry or I, we will get, we will actually, we create this document with a questionnaire in it and we will share it with Harry and his group. And that's what we'll let out and that's what we use as part of our due diligence process of whether to make a yay or nay decision on that. Does that look the same? Does that look the same as the incubating due diligence at the SIG level or is that a different for a sandbox project? You know what? I will need to figure out what the answer for that one is. And Matt, this is Diane Mueller. Thank you for asking all these questions because it is very confusing. And, you know, I know we went for an incubation status with the operator framework, and now it feels a little bit like we're in limbo. So I don't really know and I ought to know, but I'm asking again what the status is, is it now to go to the TOC and we need to request, do we, like the folks behind the operator framework need to make the request of the TOC to review and vote on this? Or it's very unclear to me at least. Diane, for your particular case, I'm actually going to follow up. I've already followed up with Amy today about that. We're going to get you some new information as soon as I get it. So Diane, I think one of the pieces of context that might help here is not only is there mostly a new TOC in play or half of a new TOC in place, but there's also new processes in place. It's kind of going over the cusp of it. That's the reason I have questions for Helm here, and I've had so many questions about Kudo, because there's just so many changes and so much of this is new and reading the docs that they've got is a little confusing. And we're talking new process and you're like right over this hump of you came in during the old process, you've got it, but they had to stop because the TOC couldn't vote. There's no new TOC in what process. I'm sure there's a lot of confusion there. Yeah, you'll probably need to hark on it. Yeah, and we've been in limbo now for almost four months, and this is it's not a comfortable place to be. And we keep trying to go through whatever hoop everybody puts in front of us and get all the information out. And Gerard, this is, you know, listen and learn. There's nothing saying that this process isn't going to change again. So, you know, with the new TOC. So, you know, my druthers is I would really just like to get to a vote at the TOC. As soon as possible, preferably before KubeCon EU, so that we could deal with it there and have some, you know, recruitment for new bodies and external parties to work and collaborate like Gerard and Matt and everybody else at that event. So, you know, this will be the second KubeCon opportunity we've missed to bring everybody together. I feel your pain on some of this. One thing that I would suggest is you can still recruit bodies. You don't have to be in the CNCF in order to recruit more people. That's the one hole that I can say, but yeah, you have a great point. And we will. I mean, I've got a meeting room set up and everything else, but it's just this is getting to be redunculus as the word I use the most. And Chris, I know you're on the call and Brian and Amy, I know you're there, but it's like if we could just get it on the agenda, I don't care what we have to do to educate the 11 new members of the TOC will do it. We just need to get this done. I very much appreciate that we are having conversations to be able to help move all of this forward and to Matt's point you, he's correct you guys are kind of in that weird edge case between here's process and here's bringing to see comes in but thank you for bringing it up I will take a look at this with Brian and with Chris today. And Matt, I guess with that I'll pass back to you. You mean it. I saw it. I'm glad it tells you it always reminds you when you start talking and. But I guess the thing that I would ask is that as you go through the things that the chairs have to do in this sake. Please keep those of us who are on the projects in the loop regularly. If we have to go weeks without knowing what's going on. It just eats at us and we feel bothered and I know it's extra work for you. But otherwise it creates problems for us and I'm sure the folks on kudo can can say they've gone through this because they first pitched it like six months or seven months ago now and changing processes and problems have created problems there. We just heard about the operator framework, we really love to know what's going on when things are happening. So at least we feel like we're not forgotten, and it forces you to not forget us and keep going. So that's the thing I would ask. But with now with that, what I wanted to do is I'm looking at this new process and hell wants to go for graduation. We've had all the eyes dotted and to use cross for some time. Everything we're doing now mostly goes above and beyond the graduation requirements. And so, or just filling out the right things like you want to know who the users are in a in a markdown file in a special format right you've got this place where you need to do something like okay. We've got to take our users and get them docking some of them anyway, get them documented over here. So, my question is is now things have very much changed in the new process. And I know there's a due diligence form we've got to go through and fill out most of that was supposed to be done for incubation but we went in for incubation quite some time ago, so we don't have a due diligence form like that. And so I'm wondering, what does the process look like now we'll go we'll work out to do diligence. We'll get with our TOC sponsor who is still on the TOC. And we'll start working through some of these things. But what else do we need to do do we need to come here and give a presentation maybe in two weeks that walks through to do diligence. Do we just need to do a poll request to the TOC repo. What's the what's what are the steps we need here. I cannot give you the answer right now, but I am meeting with the TOC next Wednesday at this time. And, and, yeah, it's not the best answer, but it's what we have and this is what I will be bringing up and what we need to figure out. So we're actually even better. We've got a meeting tomorrow about being able to outline all of this that's roughly this time tomorrow. In fact, exactly 24 hours from here. So I appreciate that you're also feeling that you're stuck in limbo about this but can you tell me where you are on the due diligence doc. Well, since I just learned that we need to do it yesterday, and I'm prepping for a webinar to give next Tuesday, I have not started it yet. Okay, the plan is to start it either this afternoon or more likely tomorrow morning. We know most of the things it's just a matter of going and filling it out so probably some time tomorrow is when I will start work on it. So I can probably get started on it. And then if after the meeting in this time slot you could give me some direction, I'd appreciate it. Yes. Come find me on Slack we're being able to drop me an email and that sort of thing and I'll let you know if we have clarity around if you need to be able to prevent towards the app delivery group with that due diligence docs, or if it needs to be able to go to TLC directly. What time does that meeting and tomorrow 9am, 9am Pacific Pacific. Okay, I don't want to bug you before then. And so that's why I mean you can I just won't have any good answers for you, but I appreciate this and I appreciate that like, you know, there's a lot of confusion here. I will put this on our agenda to make sure that we get clarity around this. Thank you. Yeah, absolutely. All right, Matt, is there anything else. No, that was it. All right. So, going back to our agenda. Well actually it looks, no, actually there's a, another item just popped up on here from Xander. Hi, yeah, I am another supplicant to the process of moving through this, this gauntlet, and I'm here representing some of the core team of cloud and build packs project basically just checking in. It sounds like we did a PS we did a PR in January and I'm reading the comments on the PR that are saying we need to do this same due diligence template. I have a guess a couple clarifying questions my, I had used the template as a means of kind of figuring out what information we might need in the PR. And, and when I read this template it, it sort of seems like it's for people who are leading, or I guess the quote is leading or contributing to due diligence should we be filling it out ourselves or does someone else have to fill it about out about our project. No, you would fill it out yourself. Okay, so we do our own due diligence fill out all the items that seem to apply to us and then attach it as part of the pull request. I guess if you fill out Google docs you can put the link there. Okay, but then that information provides whoever's going to do further due diligence, at least enough pointers. So that's how we would move forward. Okay, cool. That's helpful. Thank you. No problem. So but if you need anything. Feel free to reach out. Don't wait for this meeting. Okay. I reach out in since you have to like delivery slack. There or on our, yeah. There's a mailing list. There's a mailing list. Yeah, just reach out Sandra and we'll make it happen. Okay. Sounds good. Oh, right. That actually. Alright, I'll actually put the call out. Are there any more projects that are, I don't think there are any more there would be framework and then the helm. And then our goes is ready to move to see and cloud need to fill packs. If there are any more, let us know whether it's mailing list or or or or slack. And with that, I don't think there's anything else on our agenda today. So I'll just send in early away. What's the recommended way of, from the question from the chat is what's the recommended way of distributing and packaging operators built by Kudo. Jared, I will let you take that. But. Yeah, sure. So right now we have a repository model and actually can is here and can talk more to that. We have the Kudo channel as well. But basically, right now you can stand up your own Kudo repository and package and put your operators into into that repository. The reason we haven't come up with a more centralized we we we do have like our stable repository that's your default public one. So getting into that is just a matter of PRing into our operators repo the the operator and then cutting a version of it and doing a release. The reason we don't have a more formal way of doing that right now is given some discussions we had a cube con with with a few other teams helm and operator framework. We wanted to wait and see how Kudo could fit from a distribution or a wider distribution method, how could fit into those frameworks right and and participate there, rather than going and creating like a fourth Kudo hop right so repository model for now happy to talk about it in the in the Kudo channel and walk you through that we have a lot of docs on it would be your your way right now for distribution and packaging. But more TBD on that. All right, thank you. Any more questions. Well, with that, just one more update. I was talking last week about the workgroup for air gap that meeting invites going now that I know where to send it will be coming out very shortly. And it's going to be next Tuesday around this time. So we'll meet then decide if that's a great time. And then we'll get a cadence on the calendar. Sound good. All right. Well, with that, thank you everyone. And I'll be talking to some of you all soon and we'll be doing all the follow ups and until that time until next meeting. Talk to you later.