 Good morning. Good afternoon. Good evening. Wherever you're hailing from, welcome to Cloud Tech Tuesdays here on Red Hat Live Streaming. I am Chris Short, host of most shows here on Red Hat Live Streaming. I am also a Kubernetes contributor and CNCF ambassador. So these are a lot of my friends on the call today. Josh, you are the official host with the mostess, I guess, today. Please introduce yourself and pass the ball along. Right. I'm Josh Berkus. I work at Red Hat as our Kubernetes community manager. And I was also a previous release lead for the Kubernetes release team. So it was very exciting for me to invite members of the Kubernetes 1.22 release team here to talk about the release now that it's finished and all the panicking is done. But before we introduce them, let me introduce my co-host, Amy. Hi, everyone. I'm Amy Marish. I'm the lone open stacker here. I also work at Red Hat. I'm a principal technical marketing manager officially, though I am the open stack community person. And I'm going to introduce Jesse. Hey, everybody. I'm Jesse Butler. I am a DA on the Kubernetes team at AWS. And for the 1.22 Kubernetes release cycle, I also acted as the comms lead. And I did work with open stack quite a bit back in the day. So it was a little, little synergy. So I don't know where we're at. So I'm just going to pass it this direction from me to Savita. Hi, everyone. My name is Savita. I am a CDR platform engineer in the math work. And I also led the 1.22 Kubernetes team. I've been an active contributor to the community. And the main reason I'm here, I'm doing this is because of the community. I just love the people. I'm going to hand it over to Gwen. Good morning, everyone. I'm going to be your stanker. I have been part of the Kubernetes community for years now. So it's super exciting to see old and new friends on the call today. I was emeritus advisor for this current release 1.22. And that's basically a role that you hold if you have previously led the Kubernetes release. So I basically get to have the joy of being, you know, being the cranky old Kubernetes lady in the corner and watch everyone else be awesome. So and with that, I will pass it on to James. Hi, thank you. My name is James Laverac. So I work for a company called Jetstack as a senior solutions engineer. If you haven't heard of us, we're a UK-based software company kind of building and securing collaborative infrastructure, especially with Kubernetes. And we also were behind certain Azure to begin with. Some of my colleagues work on that which you probably have heard of. On the release team for 1.22, I was enhancements lead. I've been on the release team in one form or another since 1.18 back last year. So I've been doing this for a little while now, not as long as many others here, but still long enough to kind of get a taste of things. And super happy to be here. Awesome. Well, thanks everybody. So for our audience who has not, you know, been a Kubernetes contributor for a long time, which is probably most of them, do you want to explain in general what the release team does and even maybe a little about what the release team doesn't do? So do people have an idea of what your job was for 1.22? Sure. I can take a stab at it. Basically, the role of the entire release team is facilitating the features, the applications, and so many enhancements that have been developed by the contributors make sure they get into the release. Taking a step back a little, so Kubernetes has a release cadence, which recently changed to three releases a year. So the release team rotates every cycle. We get new phases in, new contributors in. You get to learn about various roles and it's like a 360 degree view of the ecosystem. That's how I saw it when I started as a shadow and every cycle I learned something and I'm still learning even after I let the release. There is something for everyone and you don't have to have any experience to start contributing and what we don't do is that we don't, I mean, the release team members can actively work on an enhancement or something, but we don't actually decide what gets to go in and what doesn't get to go in. The power is with the contributors and the community. They can opt in whatever the future they want to ship in the current or future releases and we make sure that that adheres to the deadlines and that has all the criteria like it maintains the stability of the project. It's keeping the project reliable and we basically help them to get their features in. So please feel free to add anything that I may have missed. I'd agree. I see our role on the release team very much as an enabling role. We enable other parts of the community either in the form of technical leadership to choose what does not go in and we enable contributors who are actively writing features and implementing code as a way in order to get what they want into Kubernetes in a way that is sustainable and meet all the criteria for doing all these releases and things like this. It's very much an enabling role. Yeah, that's how it's it. Yeah, James, I'd agree and I, contrary to others here, I'm probably the newest. I'm newer than anybody that probably was on the team. This was my first cycle and I very quickly identified the role and the set of roles in the release team as really a community service type role. You're really just showing up. This is the epitome of Chopwin-Carry Water. It's just show up, help people do their job, help people, like James said, sort of enable others' success. We're enabling the release to happen. Largely, it's down to sort of hurting cats and lots of spreadsheets and if you like that sort of thing, it's quite a lot of fun and it's very rewarding to see it go out, especially if you're, you like the idea of supporting others and you like sort of helping things happen. It's a really, really great experience. So I can talk a little bit about what the release team does not do. We don't plan features. We also don't really get to keep features. There are different parts of the Kubernetes community that handle that. SIG release works with SIG architecture to basically keep a good eye on what features are being proposed, what features are being worked on and what features get accepted and approved by the community process. But again, that all happens before it reaches the release process. And the other thing that sometimes happens is that people see us as, you know, the gatekeepers of the release, which could not be further from the truth. It is only that we have a global community of thousands of contributors and there have to be, there has to be a way in which we make a decision and say, this is our current Kubernetes. Here you go. And because of that, it's, you know, sometimes it happens that certain features don't make it into a release. And that's okay. Because there's always going to be a next release. And if you want to make sure that features get in, you can be part of the process. Because again, you don't talk to us about, I want this feature in, you talk to whomever is the SIG that is related to the feature you want and you implement it together. Josh, you're muted. Josh, you're muted. So when did the oldest start for you? When did 122 start for the team? Yeah, it was hard to remember. It's early April. I think we waited a little bit for the cadence kept to be approved. So I want to say it was on the weekend of 19th. It's a blur. I should be aware of that, but it feels like a really, really long time ago. Sorry, go ahead. Oh, go ahead. Go ahead. I'm just trying to recollect the date, but I'm not able to recollect the actual date. Week one started April 26th. I also wanted to come to your defense because especially if you're really asleep, the release starts before the official week one. Because you have tasks such as, you know, assemble the team before week one, set all the schedule before week one starts, that all happens before the release. And I mean, the same is true for me, the hand of period with the previous emeritus advisor and the current one is always kind of mid towards the end of the previous cycle rather than, you know, week one, let's figure out everything from scratch. So of course, early April is that makes total sense to me, Zavita. Thanks, Glenn. And thanks, Jesse. So you had the date right for the external people who are not part of this on the 26th. I'm communicating. So this was the first release with a planned four-month cycle as opposed to the last three releases that had, you know, kind of chaotic date setting because of COVID and other things. And then prior to that, you know, Kubernetes was releasing four times a year with a three-month cycle. So first four-month cycle, how did it feel? Did having the extra month, did it make things easier? Did it make things harder? Did it not make a difference? It still went by quickly, it sounds like, regardless. Time moves quickly when you're having fun, right? That's what they say. I think a four-month cycle is quite interesting. I think it made it less, certainly from my perspective on enhancements, it made it less stressful under certain parts of it. From the enhancements point of view, the other thing we did is we brought enhancements freeze forward for this cycle. So in previous cycles, enhancements freeze, one of the major milestones for getting features ready is like having the spec complete, not necessarily the code with the specification. And we call that enhancements freeze. And that is normally four or five weeks in, I think. And this release, it was three weeks in. So it was a lot earlier. And that's something that the community kind of came up with this idea of and kind of push forward. And we implemented it, to speak. So from the perspective of enhancements, that was the thing that was really different this cycle. It's not so much the three months versus four months. It was the earlier enhancements freeze. I want to add to James's point. I also felt overall the cycle was less stressful compared to the previous ones that I've been a part of. Probably it was because that we had a lot of time between the enhancements freeze and the code freeze. And we communicated all the deadlines before had we had enough time to go through the exception request. I don't think there was one time where we felt, okay, we should do things in a hurry. And we as a team, and the role leads, some leads did a wonderful job. So the end of it, I didn't have a whole lot of things to worry about. It was all like working together and learning from each other. And also I want to add one thing. We also took care of the teams while being this time around. We have been trying for the past couple cycles, but that's something that I am super happy about. I don't think any of us worked a lot over the weekends. We made sure that folks are not working on the weekends. At times we did one for a little thing. Some deadlines fell on Friday, which we couldn't avoid. We tried really hard. But that was after talking to the sub team lead and asking, like, are you okay to do this over the weekend? Or you can wait till Monday. You don't have to do this over the, like, after hours, weekend meetings. If it's off time, you don't have to attend, just add your updates to the file document, do the document. And you can also have one of your shadows or someone represent one person from the team. So I think for me personally, I felt less stressed adding to James's point. I didn't have context coming in. As I said, this is my first cycle. But I've been in, you know, I've been part of and managing large scale software projects for two decades. And I found this as a community effort as, you know, sort of just a bunch of people that are stepping up and willing to help. I found it was effectively, I mean, incredibly smooth and very effective. And like, for, yeah, I like how I accentuated the wrong word there that was like I put the wrong emphasis on the incorrect syllable. So I found it really effective and really impressive. And, you know, kind of coming from three months, I just can't imagine doing it. But then four months is not that huge a difference. And it was just very smooth. Savita did a great job of just sort of making sure everybody was doing the right thing. All the leads just sort of did the right thing. Gwen was there to sort of hold us up and we just kind of move through it. It felt very, it was not stressful. You know, it was really, it was very impressive from my, you know, from my perspective as a newbie. It was, it was very smooth. And did you have any pushback from the community about the change in the release cycle? Oh, gosh. I posted the blog post earlier, I can post it again. Anytime we discuss it with OpenSec, we get a lot of it. So I was just curious how y'all were had. That's an awesome question. From what I observed from my, you know, ivory tower of being there just in an advisory position. I think one of the biggest pieces of feedback we got was that code freeze was really long. And that people really struggled with having the entire project be in code freeze and just like, you know, for weeks. And that might be something that we might reconsider. It is, I think, I don't, I haven't quite figured out the retrospective topics yet. But I am fairly certain it's, it's in there, it's in the retrospective, there is a really long code freeze as a result of this. So that's one of the pieces of feedback we got. We also got some feedback that, you know, had to do with like, oh no, things change. Why did things have to change? But that was mostly from the community itself. Ever since I've worked on Kubernetes, all of the end users have been, dear Lord, four releases a year. We have to upgrade all the time. This is hard. So I think from the perspective of the end users, this is actually a welcome change. And Gwen, you have some perspectives being lead on previous releases, right? Like, I remember chaotic releases of the past that you were on or anybody was on. And was there any last minute chaos this release, like there has been in the past? Or was, was it genuinely smoother at the end? So I think that for the team, it was smoother. For the most part, couple caveats. I think that people were nonetheless going, you know, going really hard towards the end of, you know, towards the deadlines. From a contributor perspective, people were just like, oh, I need to get, you know, I need to get the deadlines figured out. And so that was the same. Quite honestly, people are like, oh no, it's 11 o'clock and midnight is the due date. So here I go, you know, making sure my feature makes it in before the door closes. I get that. I'm a procrastinator myself. So I didn't really expect that to change. One thing that I still think that I've seen at almost every release and sick docs can probably, you know, corroborate this, but the docs, the docs sync to the release is always as we still haven't figured out how to, how to remove the friction there completely. So that's one of the things. In any other road bumps, any, any other things that, that people ran into this release that, that were particularly difficult? Yeah. Everything Gwen said, less, I just felt the enhancement freeze, right? Some of them are so happy, like the freeze has been moved and like we reduced it from five weeks to three weeks. And, but that this was the first cycle that we introduced it. And unfortunately, KubeCon fell in one of those three weeks. So which made it difficult for so many sick chairs and PRR reviewers, we have a limited tool of reviewers there to accommodate every single request. So I personally felt there was a bit of resistance there. And I felt the initial few weeks of the cycle was chaotic, then that later end. So I just have a whole different perspective. And as Gwen said that there is always like someone who wants to finish the feature. And now that they also realize all the contributors and everyone feel I think that they have to wait another four months. It's not three more months, they have to wait another four months. And then cycle to graduate a feature, like probably say a feature graduates and four to six cycles, just a ballpark, I could be wrong, maybe a little bit more earlier than that. But now that actually extends their timeline, because every cycle is longer. So I saw a bit of contributors rushing like, oh, I want to get this and I want to get this and because I don't want to miss this. And I want to, I cannot wait for another four months because that will obviously delay the graduation of feature XYZ. So that's one thing that I felt. Just going on. Yeah, that was a big, that was a big worry about making the release cycle longer, that it would make people push harder to get their feature into the current release. So you guys, you saw a little bit of that? I think we did. Yeah, I think especially when we were we have this exceptions process where we have certain deadlines and they're not fully hard deadlines in the if you if you miss them, you can submit exception requests. And a lot of those that came in had a load of people saying, you know, we'd really like to get this in and we don't want to, just as we've said, we don't want to delay that. So I think we did get that as direct feedback from a number of a number of contributors. Just generally about the business of the release, like enhancements is always really interesting in this aspect. So I've done a number of different roles on the release team over the past few releases. And back on like, when I was doing release notes, we do nothing for the first part of a release where there was no features in to generate release notes for. And then right at the end, we'll be generating the major themes documents and the release notes and all of this. And enhancements is a complete opposite experience, because we started out with, you know, our three weeks enhancement freeze, we exclude include kubecon, we had two weeks in order to get everything reviewed and done and in. And then we had a little bit more business around about code freeze later on. But when we got to the last two three weeks of the release, you know, we were having daily burn down meetings to discuss it. And I talked to the enhancement shadows. And I just be like, okay, he wants to go to the meeting today and say no change, because we're fine. We've done everything we needed to do before ready, which is kind of surreal experience of watching everyone else be really busy. That's an indication of the just the different roles within the release team of like, you know, sometimes, you know, one or two teams are really busy at the same time. And other ones are sort of idle. And, you know, at least in my experience, there was a lot of a lot of sort of cross team collaboration, like, hey, we're kind of idle. Do you need any help? Can we help with reviews? Can we help you, you know, herd the cats? So I found just the team was overall really effective. And like I said, I don't think Savita ever really had a downtime, I think as a lead, you're sort of always sort of at this maintenance level of kind of keeping an eye on everything. So I think when the team functions that way, it's easier. It's easier for everybody. So but yeah, I had experience on on comms, you're you're really primarily responsible for just a couple of things and then planning the release blog, you know, talking about the release and then helping sort of the job is still going for me because we're putting out these feature blogs of specific features that are really interesting. We kind of help get those reviewed and out the door. And so I was really busy at the end and James's team was sort of like, how you doing? It was, you know, it's kind of interesting that as as a unit, it sort of balances out. So actually speaking of features, so any favorite features out of this release, like like a personal favorite feature, either something going to use or something that you thought was really offbeat or something that you thought was really creative. I'll just throw out there. This is a this is a gimme like everybody should be psyched about this. In alpha, we now have default set comp profiles. So that's just huge, right? And you know, something that I think even people new to Kubernetes look at it and go, oh, oh, okay, I don't have to worry about all of that just yet. Obviously, you can still customize your own profiles. You can support those in place. But if you don't, you get a sensible default. And I think that that's just it's going to make a lot of people sleep easier. It's going to make it a lot easier to sort of start a, you know, secure by default, sort of deployment plan. So I yeah, that's that's my favorite. I mean, there's a lot of great stuff in here, but I don't I won't hug the I won't hug the mic. It's I have to say it's a big change because I remember installing Kubernetes 1.0 and pretty much having to turn off every security feature I had to get it to run. Yeah, this is this is a really great, great thing to have the sort of in in the project, right? It comes sort of by default, you get default, default profiles. That's great. James, Jesse is still my first favorite. So I'm just going to go for the next one. So I I am excited about the node swap support feature. Because there are it will definitely have so many workloads on bird EC, the more and more that we are adopting more and more that we are going towards the like everyone is adopted container technologies. Now most the companies are running it and still we have issues with Java applications, which needs a lot of memory and resources, the boot time, but they don't need it while they are running. So that feature is definitely going to help some of that. So I want to give a shout out for that one. I do have other features favorites, but I'm just a wait for others to chime in before I just tell all the features on the and call you as a former database geek, you actually hit my personal favorite feature. Yeah, I was about to say Josh, you must be happy about that. Yes. So my number two, just kind of coming from Unix to Linux years ago when I went, oh killer, what's this? Oh my God, what is this? Like, I'm just super psyched that this optionally is here. I think the swap thing surprises people sometimes like quite often when I've explained how to deploy Kubernetes to people. I've been, they've been like, well, how does swap work? I'm like, it doesn't set it off. I'm like, what? I might just have a bigger node. What? Yeah. So it's, I understand why it is the way it is, you know, it's a very complicated problem, but it's lovely to see that that kind of be worked on. Some of us may have been running Kubernetes with swap anyway for years in a hacky way. Wow. I think my personal favorite change is actually, so this is something that had a really small change this release. And it's actually first introduced a while ago, which is the ephemeral containers work. I'm just really excited to see ephemeral containers like become more of a thing. I can remember back when I first started using Kubernetes, I was applying like closure applications in containers. And there was this whole discussion of, well, when we deploy for production, we want to enable like nothing when it's completely locked down. And when we deploy it for dev, we want to like deploy it with something we can hook into and do remote code. And I was like, well, that means we need two different containers. There's no, there's no way around it really. But with ephemeral containers, and you can hook the boogers and all sorts into it, it's amazing. So I'm really excited to see if ephemeral containers kind of move into beta. I know they're targeting beta for the next release maybe. So I'd be really excited to see that work. That'll be a fun feature to use, I feel like in the future. Go ahead and you have a favorite. You know, I just really, I just really like, I just really like the part where you can now have non-grid users and you have on the control plane. It's, it, I don't know. I am used to have root privileges in all of the systems that I work on at GitHub. And I'm used to be able to just take them. But so I feel a little bit like a hypocrite saying this, but I actually really like the ability to just, you know, have this maybe be an administrator, you know, the administrator's prerogative to set that out on behalf of others. So it just feels better. I know there's going to be more knobs to twist if you implement this feature, but it's probably a really useful, helpful thing for most cluster administrators. So that would be me. I, this, it feels weird, but I actually really, really like that. It's also good for the optics, right? People are always like, oh, ha, ha, you escaped the container. And then, you know, and then it's like, or, you know, in this case, it's the, it's a control plane, but still, it just feels better. That, that, that, that wasn't my list too. So all my list was made up of predominantly security-related features. I'm a cluster, I do cluster administration as well. So so many of these features actually led the administrator's sleep well, if configured properly. If not, it's an administrator's nightmare again. So there was another thing that I wanted to shout, give a shout out for. It's the windows privilege containers. I am so happy to see the window side of the ecosystem is also keeping up and make sure that it gets like all the good features that were supported. I shouldn't call the good features and I shouldn't be biased, but all the features that were like in Linux is slowly and steadily getting forwarded to support windows node as well. So I'm excited to see that growth. Yeah, if I can throw in there, I was going to say, once, once we wrapped up our favorites, because I didn't, I didn't think windows in general, all of the little things would make the top of the list. However, I think we'd all agree that all of these changes together, plus the windows development environment that Sig Windows has put together, makes a really compelling windows case for this release. And I just, I wanted to kind of give that Sig and that community a shout out. I think it's a really good example of a community enabling its own presence, right? And just saying, look, we're going to just do this and make it happen. And like you'd said to me that every release, every change is just a little bit more parity, a little more, you know, capabilities. I'm sorry, I think that that Sig has done an outstanding job, especially in this release, there's a lot of things for Windows, Windows users. So in the realm of least favorite features, there has been a little scuttlebut in social media, et cetera, about the API deprecations. Is that a big deal? Is it people making a lot of noise about nothing? What's going on there? Anybody mind if I take a run? No, please go ahead. So from the vantage of comms, I've been trying to look at this and say, okay, are we missing anything? Communications-wise, are we missing anything for the community they need to hear? So then the first thing to understand with this release in particular is we only had three very minor deprecations. What people need to plan for are the removals of deprecated APIs that have been deprecated for a few releases now. Kubernetes tries to take care of the end user community by saying, okay, we're going to deprecate these things, and we're going to keep them deprecated for several releases. Three is the specific number. And then after three releases, these APIs or features may be removed. And so in 122, you have a set of beta APIs, which never achieved stable, which have been deprecated for three versions, which are now removed in 122. So this plays out interestingly because I think the project has been learning how to communicate things over several releases. There's initially a knee-jerk reaction to, oh, here it comes again. It doesn't always have to be that way. And I think we do now have some pretty solid voices out there in the community. Cat Cosgrove comes to mind where they just get out ahead of it and they just start these threads that go viral and everybody knows it's coming. So that's really great. The other thing from the Vantage of the Cons team, we have a very active tech lead in SIGDocs named Tim Bannister, and he had proposed sort of putting a blog out together ahead of the release. And that aligned with an idea that our team had, which was to say maybe for every cycle, we always put out a blog maybe after code freeze and before we start putting out the later beta builds to say, hey, in a few weeks, a month and a half time, this is what's coming. And so we're actually going to talk about that at Retro. I think that that might be something we add to the docket. But I think this time we did a pretty good job of that. Thank you again, Tim and everybody that was involved in that blog. So I think at the end of the day, this is about now the community starting to catch up to the progress and the growth and the learnings that the release team has had, saying, okay, they sort of have the best plan that they can make right now. If we have beta APIs, we have to pay attention version to version. They may change, they may go away or they may graduate to stable. If they do not graduate to stable, they may become deprecated. And if they become deprecated in a few releases, they're going to go away. So that's the place for everybody has to get. And I am so not throwing shade at the community, because like I said, I come from enterprise software where people pay for the support and they don't do it either. Everybody kicks and screams and holds on to the things that they have. So no one should feel bad about it, but we do have to plan for it. So that's my take. So this release, just to summarize, we're removing, they're no longer served a bunch of already deprecated beta APIs. That's what we're planning for. As far as new deprecations, there's only a few, and they're in the release notes. So a question because I'm from outside the community and in another community. You mentioned that things are deprecated for three releases, but because of the quick release cycle, it's deprecated for even less than a year. Do you think that's why maybe there was the vocal pushback? Does that make any sense? I have a take on this. I would like more experience Kubernetes community members to answer, but I have a take as a newbie. Looking at this, I saw that, for example, the increased release cadence is to help this. I think the project looked and said, wow, almost all of our users are not running the latest release. And data shows that more than a third were running releases out of the support window. I don't expect that to actually change. Like Josh said, he worked on something that was supported over five years. I worked on things that were supported for 25 years. People hold on to the things that they have. So I think what it does is it gives us more time to communicate and more time for folks to plan. So now we're at a three releases a year. You have basically a full year of knowing something is deprecated before you have to move from it. I think the lesson to learn is you should be moving from it before that year is expired. And my experience with software with a much longer deprecation cycle is it doesn't record as your users simply do not pay attention until the feature actually goes away. Absolutely. No matter how many times you announce that it's deprecated, no matter how many times you put messages in the log saying, please stop using this, it's deprecated, they just don't look. And by the way, so most of those sort of deprecated APIs, in a lot of cases, are features who graduated to general availability. And so they have an old beta API that's slightly different from the final general API. That's exactly right. And we're not going to keep the beta API around forever, right? Because at some point we're not actually dropping features in 122. It's that they're here to stay. So everything that you might be using that's beta that you have to move away from, you're moving to something that you can now actually have more faith in being around for the long haul. So this should really be not a huge painful change, but it, you know. I take this a little personally, Josh. Yeah. And 117, which I led. This was one of the major themes that came up, started to actually deprecate and move to fully supported stable versions of the APIs. And internally at GitHub, we have a lot of automation and scaffolding based around creating Kubernetes objects for people. And I paid attention and I said, hey, we should not only change the scaffolding, but we should just like, you know, create tooling that helps people update their objects. And so on some level, I get it because we definitely had some users saw the PR and were like, what do you mean I have to remove the beta? Okay, whatever. It's still working. And then, you know, several months later, they were like, so my app just broke. Totally a thing. But this is why it is so valuable to have a voice in the community. And actually not a voice, but an ear. Right. If you have a finger on the pulse and see what is happening going on, then you can go back and tell your employer, hey, by the way, we might want to change this. It's just, and then I just feel like that is the best way to avoid surprises on all ends. And it helps everyone. So I mean, I think that I'll be honest, I haven't looked too closely at the discussion around the deprecations for 122. But I kind of reminded of the kind of archetypal recent example of discussing deprecations, which was a whole docker shim deprecation from a few versions ago, where someone said we're deprecating docker shim and everyone went deprecating docker, how are we going to build our containers now? And the work Twitter was on fire for about two days until people realized that actually, for most people, nothing has changed at all. And it's not quite the same thing. But I think that the release team and the documentation team learned a lot about how best to communicate off the back of that. I think that things like, as Jesse was saying, the kind of careful communication around that is really driven by that experience. And I think that's that's a process that's going to continue to improve as we go forward. So we're going to learn how best should we communicate with end users. That'll be good. So 1.22 is out, right? It's been released and that sort of thing. So I, given that what's next for each of you on the Kubernetes project, or maybe you're burned out in Kubernetes and go work on something else for six months. But what's next for each of you? I am personally taking a step back from the SIG release a little bit because I've been there around for a while and I want to focus on other things. So I feel like I wanted to do a lot for SIG Contributex and I didn't get the chance even to put certain. So I volunteered for doing some new contributors stuff and I haven't had the chance to do it because I focused a lot on one area. And now I know it's 1.23 is in good hands and there are like so many contributors and I want to focus on the things that I thought I would do. So predominantly I'm going to focus on two. One is Contributex, another one would be SIG Security. I always have a passion to learn more about securities and I also help lead a sub project, SIG Security documentation. The main idea is to improve the security related content in the K website. So that's where I'll be focusing another six months. So I'm jumping straight into the next release. I'm on the 1.23 release team as a release lead shadow. So I'll be working with Ray who's release lead for 1.23 and we're doing this all over again. In fact, it's interesting to talk about 1.22 because next week is week one for 1.23. So we're onboarding and cycling up for that now. I'm with James. I'm jumping right into the next release. I'm going to be on the SIG DOC team and yeah, I'm really looking forward to that. I'm just trying to learn all the different moving parts and try to help where I can. So that's where I'm landing for 1.23. See you there, James. And just taking a moment to say thanks to Sabita. I think you're being humble and saying you've been around for a while. You've been really, you've contributed to a number of releases back to back and finally culminating in leading 1.22, which you did so well. So enjoy your brief hiatus or your change away from the release team. You're still in the community. We'll still talk with you and yeah, just thank you for everything you've done. Yeah, I wanted to echo that. I mean, we talked a little bit earlier about how everything was smooth and really easy. I think that's because Sabita just put in an enormous amount of work getting this so smooth. So thank you so much for your leadership in this release, Sabita. Thank you. No, you're all going to make me tear up. It's just not my effort. Everyone's effort. And I also want to say like it's a fangal moment for me. So this happened 2018. This is a little story. 2018 Seattle, Kubecon. And then came that was my first Kubecon. And then the second one was like the San Diego. And then that was my first contributor submit. I didn't know a contributor submit existed before that. And then I saw Gwen and given was leading like, or she just made one dot to my channel. I just stopped and I said, Oh my God, she was, I was attending all the calls and stuff. I'm like, Oh, this is the lead. And I get to say hi and everything. And I like, this is like a full circle and she was the EA. I'm like, I'm still so inspired. I'm like just like, Oh my God, this is like a real fangal moment for me. I'm like, Oh my God, this is happening. This is happening. So my inspiration and motivation comes from the community. And thank you, Gwen. And I don't think I'm going to stop saying the story. I'm going to keep embarrassing. I have actually, I said hi to her and stopped her in a room. So I'm like, I'm just keep embarrassing you. But this is this is what like keeps kept me motivated. And I'm glad to know that I I did something good. So that that's that has made my day probably my week already. Thank you, everyone. You did great. I don't, I don't, I have to just, you know, add to what Jesse and James said. It was, it was awesome to like watch you and just, I don't have to do anything. I just had to watch and be like, No, we all doing great, especially Savita. And yeah, I, I don't know. It's I'm really, really happy to hear when people say something like, Hey, I saw you give this talk and that made me want to come be at the release, or I met you at the thing. And because I got so much from this community. And it's just, you know, sometimes there are always these days when like, what is, what is, you know, these days when you're like, I don't know, what are we even doing here? And then I hear these things. And I'm like, Yes, there it is. That's why. So it's, it's, it's just, I'm happy to hear that I could be helpful in a tiny little bit. Because maybe it means that I paid it forward when it was my turn to receive inspiration. I think that's the important part of communities that we all get out of it. No, that's what drives us. And I can't wait till we can like meet in person again, because we're missing those connections, which are so, so important. Yeah. Well, we'll, we'll see about Los Angeles, whether, whether most of us get to see each other or not, even so, won't be everybody. Yeah, it's still going to be a small subsection of everybody, but it'll be better than nobody. Well, thanks everyone for, for joining us and for talking a little bit about the release and your experience. Any final thoughts? That feels like a good place to wind up, right? That's a good, good final thought. The, for anybody watching this, by the way, who is a member of the Kubernetes community, etc. I think it's a little too late for 1.223. Yes. But when 1.24 rolls around at the end of this calendar year, the 1.24 team will be recruiting new release team shadows. And so if this sounds exciting to you, you too could be part of the release team. And there's a whole sort of training cadence where you're a shadow and you learn how to do stuff. And then you take over that position for the next release. So consider joining and helping out. And in the meantime, consider helping out in other areas of Kubernetes because it is, it's our project. And, and thanks so much. So Vita and Jesse and Gwen, James for joining us and talking about the release. When is the retrospective, Gwen? Oh, yeah. If you want to have a little bit more community participation, the 1.22 retrospective is during the regular Kubernetes community meeting time this coming Thursday, 10 a.m. Pacific. I apologize. I don't know the UTC for that off the top of my head. But everyone is invited and can join. It's, it's a public Zoom meeting. And we will be, I will be running that, that meeting and we'll just sort of talk about past past things we attempted to improve and future things that we need to work on and also things that we did really, really well. So we can continue doing that. Hope to see you there. Thanks folks. Thank you all for joining us. We really appreciate it. Thanks for having us. Thank you so much. Thanks for having us. Yep. And for the Cloud Tech Tuesdays audience, we'll see you again in two weeks. I've forgotten now what our next show is, but we'll see you in two weeks. Yeah, I can look it up if you really want me to. But yes, two weeks from now, we will be on with, never mind my browser froze, of course. So tune in in two weeks for Shipwright, I think. Oh, okay. Awesome. Right. Shipwright. So build, build your, do your containers builds on Kubernetes with Shipwright. So see you then. Take care, everyone. And thanks for coming and joining us. Mai, we won't take care.