 Well, hello everybody. Welcome to another episode of Kubernetes by example insider where we like to interview the actual engineers who work on various aspects of Kubernetes so that we can get a sense of where they feel like the project is going. Obviously, you can always talk to product managers or project managers, you know, and those kinds of people. However, the both the good thing and the bad thing about open source is often the engineers have direct control over what actually lands. And so we find it useful to actually talk to the engineering community to see where, you know, what they are passionate about what they want to see happen next. Because I think we gives us some better insights into whether, you know, what what's going to happen, basically. So I think we're on our 10th episode. And I would like to welcome our promoted, I don't know, co host of Savita, who was on the show. I want to say episode six rings a bell. But, you know, Savita, do you want to Oh, sorry, I forgot to introduce myself. I'm Langdon White. I am currently a faculty member at Boston University in the School of the Faculty of Computing and Data Sciences. I teach data science as well as some practical classes doing basically engineering software and machine learning projects for third parties. So that's the program I'm involved with. I was formerly with Red Hat for a long time. And Savita, why don't we have you introduce yourself. And then we will introduce our guest. Sure. Hi. Hi, everyone. My name is Savita. And to be here on the show, I think I was on episode five or six, it was like five, six months ago. And if the same excitement that I felt sitting on the other side, I am a software engineer working on data protection area. And I also contribute to upstream communities and conveyor community. And I have, I picked up a crocheting as my hobby during the pandemic. So that's going on the side. Moving on to our guest of the hour. Sasha, would you like to introduce yourself? Yeah, hey, thanks, Savita. Thanks for having me on the show. And nice to see you again. I mean, we already know each other from the release team. So I'm Sasha, one of the contributors. So I consider myself as a contributor to Kubernetes. And I work in multiple directions on the project. So I'm part of sick release acting as a chair. But I'm also very working with Redhead on the lower level bits of Kubernetes. So I contribute to projects like the container on time cryo and some related projects as well. So I see myself as an all rounder in that case. And yeah, I'm happy to be here on the show and to answer any questions. And I would like to clarify, I appreciate you mentioning, you know, Kubernetes community member, because really, that's who we interview. We actually, you know, sometimes it's engineers. But you know, we've had people who are kind of like on the dev advocacy side, we've had community liaison type people as well. I just have the old, you know, kind of open source contributor, auto language right around engineering, which is a bad habit. But one of these days, I'll fix it. So thanks so much for coming. One of the things we like to start the show with is what got you into open source in the beginning? Or, you know, or if it's directly Kubernetes, what got you into Kubernetes? Yeah, I mean, we have to go back in time. When when answering this question, right? So I was starting to work for software related projects 10 years ago now, which is amazing for myself because I never had a profession which was was that long, right? So it's just the first time I lived the first time. And the idea was I never was really into open source before. So I really started working on software projects. And then I realized that all those companies are using so much open source, even if they don't contribute to open source at all. And then I thought, okay, those companies would probably not exist at all if they if there wouldn't be open source. So there's a whole economy hidden behind this huge open source effort. And many folks are thriving and upstream. And yeah, this got me into open source, actually. And I was more and more interested in creating I started with creating my own projects. And sure, surely I failed because I failed very often because those projects, yeah, nobody really had interest in or they are solving a particular problem, which is not really, which is out of scope of other problems. And then I was iterating on those on those cycles. And when I was getting more and more interested in new technologies, for example, broken language, languages like Rust, then I started to understand that I have to contribute that I have to bring myself into a community, contribute to them, and then get something back in terms of being part of that community. And and at some other company, there was a project where we had to where we had to create a microservice application, which had the boundaries that it should be highly available. And it should be for free, for sure. So we had been choosing Kubernetes. And I had the chance to work myself very deeply into the Kubernetes tech. So this was at a time of one dot 12. So in early, not in early stages of Kubernetes, but it was some years ago. And therefore, I worked myself in the Kubernetes, we created an application stack, and I had a chance to teach my knowledge to my colleagues. And this was really an amazing experience from my point of view. And but in the end, it wasn't enough. So I really wanted to be part of that community. And I was actively searching for a company who is contributing to that project. And therefore, I came to I came first, I came to SUSE, and then I came to Red Hat. And I'm really happy that that our companies around those projects and who continuously contribute to Kubernetes. So I wanted to ask you about that. The well, first up, I think I'm pushing 25 years. So yeah, I know what you mean. But next, I was going to say, you mentioned the community, I don't know, seven, eight times in that statement. What, like, what is it about a community? What's what's it giving you that's kind of over and above, you know, kind of writing code, right, or, you know, or getting validation for building software? Yeah, I would compare to to actually using the possibilities that internet or the modern internet provides to us, right? So information is everywhere. So we can learn everything without having the need to interact with people. But I would say having the opportunity or learning by coding software, for example, makes it way more easy to fastly learn things directly from people who already know it. And that's the and that's the real benefit. So I don't see it. I see the benefit of company wise when looking at a higher level. But I really appreciate this opportunity to get in touch with people directly by using a chat, by going to a meeting or by just texting them, and then getting the information we actually want to have. And I think this drives innovation and on the overall project. I think I think you bring up a good really good point. I think software, you know, kind of engineering or whatever is often considered to be kind of a lone, you know, our loner activity, right? But it really isn't in a lot of ways. And one of the things I mentioned a lot, actually, that I've found really interesting, basically over the course of the pandemic is the growth of Twitch in kind of the engineering community, because it is a really good way to connect with another developer, where you can kind of watch somebody else program, right? And as odd as that sounds, it's a really good way to kind of learn, you know, like what I often say is like, if you if you watch an expert fail, watching them and what they do to get out of that failure, I think teaches you as much or more about like how to be a good programmer than then almost any other mechanism, because it's it's so hard to teach that. And it's one of the things you only get really through experience. But I think with something like Twitch, you get a lot of opportunities to kind of see it in action. I was actually talking about this with a medical doctor the other day. And medical doctors do something similar, except they basically fake these scenarios, right? And then they go through. And it's kind of a continuous training exercise, but they they fake them. The nice thing about the Twitch is a nobody, you know, we can do it for real. And nobody has to like die or be ill, you know, to to learn from from real examples in a sense. So I was going to hand it to Savita. Did you want to ask a question at this time? Yeah, yeah, sure. So I wanted to add something to what Shasha said, like, it's also the so for the communities, communities, little special. For me, I was searching for the place a sense where I would belong. And I found it there. In addition to all the innovation and stuff like that on your bed, it is the same way for so many folks who are like, looking for that kind of, you know, bonding. Even though I haven't seen many I haven't seen Shasha. I haven't seen like many of the contributors have worked with like two years. But for me, I just feel like it's my happy place. Just put it in like two words. So I do have one question for Shasha. This is something that I struggled with. I know like, you have a full time job, you are a maintainer for trial. You do an amazing job with sake comp profile and the new features that's getting released in communities. I think it's gone beta or it has gone beta the default sake comp profile. It was my favorite feature, by the way, in one dot 22. And you also do you're also the share of single release. So how do you manage these things? And that should having white light balance? Good question. No, no, I'm thank you for this for this big in the first place. I'm really trying to separate my work time from my spare time, especially since I'm working at home since a couple of years now. And we have a little toddler. So this two year old is running around and you have to focus on your work still even if he's back from nursery and things like that. But to me, it's, it's like finding or focusing for a dedicated amount of time. So I started contributing to cryo, but I'm completely sure that I can't keep up the same pace in the beginning, which I had in cryo, for example, when starting to contribute or continuing to contribute to Kubernetes or focusing on features. So I'm really happy, for example, that in Kubernetes, this whole release cycles exist. So we can have dedicated points in time where we can focus I can focus on enhancements in the beginning, when I'm planning for enhancements in the next cycle, for example, I can, for example, also take myself off of those enhancements for one complete release cycle and then focus like I did for 124 focus on the container image signing project. So I just can only focus myself on a bunch of projects and parallel. And when we talk about this on a weekly basis than only on one or two per week. So and I think the key is to not not to to be fast everywhere. But I think the key is to make progress everywhere over a certain amount of time. So the community kind of trusts you that you when you lay down some work that you come back and pick it up. And if you have committed on something, and you also come later on and pick those work up and finish it and bring it bring it over the finishing line, which is what one of the biggest problems we have probably in Kubernetes. And then they trust you that you will do is also for other parts of the project. And I think this is the this is the key you don't have to make you don't have to be fast everywhere. But it's important that you make progress everywhere you commit on. So so incremental progress everywhere is more important than major progress in any given spot. Yeah, I mean, I mean, iterating is also a good point, right? So not everything has has to be perfect in the first place. I mean, if we speak about enhancements in Kubernetes, then they have to be on a certain quality level. So they have to be docs and tests and things like that. But if we speak about the container image signing, for example, then we knew that that we can work iteratively over the whole cycle, because it will not go live until the end of the cycle, something like this. Right. I was going to comment, you look remarkably sane for a toddler. I've had three at some point or another. My youngest is now 13. So I'm a little past those years, which is very nice. But yeah, it's it's tough. So congratulations. So I was gonna bring up kind of the security profiles operator. I know that's that's something you wanted to talk about. So if you tell us a little bit more about what that is and why it's important. Yeah, I really I saw this is a really great project from my point of view. And we started it probably two years ago now. And the main idea was that we have one issue in Kubernetes that we fight when we speak about second profiles that we have to distribute them over a whole cluster that all profiles have to be available. I know that there are some other solutions around it, how to solve it. But the overall end to end user handling is not that optimal. And it's not even optimal right now. And there were some approaches in solving that, which had some other drawbacks. And I was just sitting together with those folks who were working on the on the overall solution. And then we started to think about, hey, can we solve this as an out of three enhancement? And then later on decide if we can bring it back into Kubernetes. We are now at the point where we have it as an out of three enhancement, and we have a bunch of features in it, which, which are great. And now we are at a point where we have to better prove those features. So for example, we are working right now on bringing it to operator hub IO, and then later on integrating it as an optional feature into OpenShift to get more user to get a bigger use of space on the operator. And the overall, so it solves the issue of not only distributing second profiles, I think the main issue with second is that it starts with creating the profiles for workloads. And because people don't understand, I even didn't understand it. And if I had initially read read some articles about second, how it works under the hood, and how it how to create such a profile, right, how to decide which this call should I add, or for which architecture and things like that. So we are evaluating different ways of recording those profiles. And we have two right now. We can pass, for example, lock files, and then we have also utilizing EPPF to record those profiles. So those are optional. And the interesting part is now that we also have maintainers, which really work tightly together with Selenux policies, and they integrated the recording feature for Selenux policies as well. So I mean, the project is growing. And also the folks working on app armor, for example, so we have those three security features that come up armor and Selenux, which are in scope of this operator. And all three have mainly the same problem of distributing the policies and also creating those policies. And that's what the operator is trying to solve. Yeah, the I don't know that there's all that many people who truly understand second, you know, in general. Yeah, it's actually interesting about the particularly Selenux, you know, a number of years ago, we're working on the modularity project, right? And and one of the challenges there, which I think is shared in kind of a containerized world, is that it all the policies were shoved into one package, right? Because when you're thinking about a, you know, a monolithic operating system, right, you that the key is to kind of minimize the downloads in a sense. And so we had to split a lot of that part of that stuff apart. You know, another example, right, is the not not GCC, but I think, like, basically the translations for the compiler, I think it was the compiler, also had kind of a similar problem, you know, where basically you had like every translation in the bucket, and breaking it apart is, you know, a whole exercise in and of itself. So I think you have, you have the problem kind of on both sides of that equation, both it's like, how do you get them out there? But then also how do you get that out there only the kind of minimal amount of stuff that you want to land in the target? So it's been a, I think, I would say going on, you know, seven or something years now, you know, a major effort to really think about how the distribution works to redistribute things in ways that we can target, you know, a containerized world. I just say it's one of those things I haven't worked on it myself all that much, or it's been more like a beneficiary of it. But I find it fascinating that, you know, it's just so different. And I think people don't realize how monolithic our operating systems have actually become, even though they have continuous delivery, you know, and things like that, because, you know, but it's still monolith, you know. Yeah, I mean, we have the same problem. Or I mean, I don't think it's a problem. It's just a different kind of software architecture. But right, same for Kubernetes, right? So we release Kubernetes at certain points in time, and we have a bundle of monolith, and we have a monolith, and this creates a bunch of components, and those are highly related to each other. So right, right. All right, I'm going to hand it back to Savita. Did you, did you want to talk about something else? Yeah, so I wanted to add that the second profile, but I used to be an administrator in a previous life. So all I cared about is like having something that would work without having to know everything about it. Because if I start digging deeper deeper, then I wouldn't be able to support any features for the platform, right? And I was deciding and working on supporting a platform service using Kubernetes and these little things add to it. And security is an administrator's nightmare. Everyone's nightmare. And it has to be implemented, right? And when I look at the second profile operator, all I see is that it's a one stop shop, because it tackles so many things, so many profiles. And like you mentioned, like three of those things, app armor, and two other things, which I cannot think about. The one thing that I can think about is that I did see something related to PSP. And now that we have deprecated PSP, or we are going to deprecate PSP in 1.25, which is like port security policies, and do you have any idea to support port security admission controller and PSS port security standards as a part of the operator? So that is one thing that I wanted to know, because I was curious. Now that I work in the admin world anymore, but I like to dab into it whenever I get some time. Yeah, I mean, the problem is always those upgrade and downgrade paths, right? So I mean, port security policies have been, they will be removed, right? Is that correct? Yeah, it's 1.25. Yeah, they are already deprecated and they will be removed. Yeah. In favor of those admission controllers, yes. And yeah, I mean, we would like to go making, for example, making Kubernetes more secure out of the box is something we probably cannot do by just moving features from the security profiles operator into Kubernetes, because those features are already so complex that they have a difference. So we would never get them in. But we have to, we would have to go baby steps. So for that, we, for example, this second default feature, which applies the runtime default profile to all workloads in a cluster. Right now, it's just a Qubelet feature flag. And if we enable it, then users don't know end users of the cluster will probably not know that it's enabled, because it's only visible to the administrators. And if you run a container, then you can inspect the container and see the second profile, for example, but the user, which usually don't has access to those lower level parts will not see that it's using runtime default and therefore probably fail. So and the next iteration from my point of view would be to make this visible to the end users or make it API aware and provide some upgrade and upgrade parts. And this is the tricky part. So we could probably say, okay, we applied a feature only to new workloads, but we cannot really distinguish new workloads from rescheduled workloads. So the complexity in Kubernetes would also then increase a lot. So, but, but really, I think, for example, we, I plan to remove the end, or we plan to remove the annotations, the second annotations in 125. And I'm pretty sure that this will also lead into upgrade issues by some users. So even if you mentioned it in the change lock, it will cause some, some disturbance. And this, that's a thing. That's a thing where I'm not sure if the, I mean, we say we support a bunch of releases for some features, and then we remove it. And then we always have some troubles about people not going to this upgrade path. And usually, for example, OpenShift solves this by adding custom logic on top of it. And I'm not sure how my question would be then, how could we achieve something like this in Kubernetes without having a, having this whole upgrade down logic, right? I mean, this is something we really, we probably really struck it in the community. So for our viewers, though, like we should definitely, it's, it's something be, excuse me, very aware of kind of in the 125 timeframe of, you know, this may impact your workloads. This is something you should be following otherwise you might get bitten. What do you, what do you foresee as a way to make sure the community is aware of those changes? Yeah, I mean, this brings me back to the challenge. That's the challenge, but probably a different software. I mean, we, we speak about software architecture. And when we consider something like a rolling release for distribution, then we decouple those components of the distributions. And we have, we always have dedicated packages, but we can't really, and we have needs some testing that which ensure that the packages work together right in their versions. And I don't think that Kubernetes is made to go this route. And that's, I think that's also why we mainly decided to go from four releases to three releases per year. And because the architecture drives the way how we release it. And that's, and that's the way how it is. I mean, that will be, that will be always people who will complain, but it's not a big deal. I mean, we are, we are happy to solve that by, by some distributions or things like that. Right. So that's, that's the way why that's the reason why OpenShift and things like that exist. Oh, totally. Yeah. I mean, it's, you know, there, there is value to be added, you know, on top of many open source projects, you know, that and ease of, ease of upgrades, ease of use, you know, those are, those are often a very big part of it. I did want to ask you, because I put out some tweets about it, about supply chain security and, you know, your thoughts on, or, you know, or potentially the collective thoughts of the release team on, you know, improving the supply chain security of the Kubernetes release pipeline. Yeah. I think we have to, when did we start with that? I mean, there were some parallel efforts in Kubernetes, which we consolidated into our roadmap and vision. And, and this vision kind of thrives our effort in release engineering and the release engineering sub project of Kubernetes. And one part of that is the Salsa compliance and the, yeah, the Salsa compliance. And before that, we were rewriting our whole tooling from Bash into some Golang libraries to be reusable and split them across three different repositories right now. And this gave us the opportunity to, after that, after the transition to do some refactoring on top of that. And also think about the Salsa compliance and the secure supply chain overall story. And this is also the headline for our roadmap and vision. So it's about an introspectable, introspectable, consumable and secure supply chain. And the secure part of that is the overall Salsa compliance when we speak about container image signing, artifact signing, and also image promotion. All those topics are huge for itself. And we own a bunch of caps, I think three caps around this topic right now. But the idea is to iteratively start working on it. And we started with container image signing in 124, which is now implemented. So it's great. It's a great achievement of our special interest group, from my point of view, because we managed to get all folks on board. So release managers who said they struggled with finding out what they want to do. And finally had an idea about what is the MVP of this container image signing, and also contributed to it. And we have, I'm not sure how many, five to six different persons working on this MVP over the whole cycle. And we finally delivered it. And I think that's a great achievement. And I think that's how it should work. I am so excited that the Kubernetes release engineering effort into like Salsa. And I also like do a little bit of subproject running with security. And I see a lot of folks involved from SIG security. And there is this cross collaboration between SIG release and SIG security, and many other SIGs within a Kubernetes ecosystem. So for those who are watching, SIG is a special interest group like verticals within Kubernetes community, where each SIG focuses on one component. And they work together. So I just wanted to give a little background for the viewers. So I'm excited. And there is also the recent release. I know the release 121 RC, the release candidate, I think it's supposed to be container. It's supposed to container images. The content images have been signed and I was so excited to see that you can verify it. So there was this tweet by one of my good friends who created this little demo. And you can see it in action. And that is like, it made me smile. So it made me happy. I know like little things. So I just wanted to say like kudos. Yeah, thank you. Thanks. I mean, that's, this is really cool. I mean, we thought about, do we have to provide something to verify the signatures or what can we do? But at the end, this brings me back to my contributions to Cryo because the container runtime folks which also maintain the lower level bits of Cryo are working in parallel on bringing container image signing. So we will probably see it again in Cryo and then we can close the loop, right? So from the, from the uppermost container image signing back to the verification of the signatures directly in the runtime. So this is really, this is amazing to my point of view. So you mentioned it a little bit in passing, but I wanted to kind of elaborate on it. You know, the release cycle has moved from four times a year to three times a year. What do you think that means kind of for the project? I think it was really necessary. We kind of, in the past release cycles, we kind of pressed the release cycle into the time frame. And now we, we don't gain that much. We gain four to five weeks per release, probably. And this gives us a huge relaxation on the release side and also on the development side. I already can, for my personally, I can plan better with features. It wasn't, it did not have a big effect on downstream. So they just adapted the new release cycle, which was, which is great. So we did a survey. We just have to evaluate the results, the final results. And I really think that that three releases per year is great. We had a delay this time about two weeks because of the goal line minor update. And now we are at a point. We, so this discussion is pretty fresh, but we have to reach a consensus. If you want to start, for example, after KubeCon, because we always consider the time in KubeCon as something where developers are not available at all. And this would also give us a bit, I mean, it's a bit pressuring because we have to put the next two releases until the end of the year. And we don't want to stop in December 20s or something like this. So mid December is the deadline for that. But we can also go for a shorter release. So this is totally, totally doable. I mean, it gives us more flexibility in planning. That's that's really great. So so what you're what you're thinking is that the the three releases won't be as fixed. Is that is that what I'm hearing you say? Yeah, exactly. So they'll be catching some folks are talking about four month releases. But that's not, I mean, that's not true. We are talking about three releases per year. Right. So. Right. We can also go for one long and two short. So we actually had we had a question from the audience. Actually, well, let's keep going and let me ask the audience member a question before I ask. So did you want to follow up on that? Did you have a comment you wanted to make? I wanted to ask, like, did you hear anything positive about moving the cadence and you know, from four to three was a shocker for so many folks and everyone's getting used to it. Personally, I love three releases per year because I cannot finally catch up. Otherwise, it was like I was just running behind the features without even understanding what they are. That's how it felt for me. But from other company perspective, another developer perspective, I understand that now they have to plan so like ahead and then implement because of them is one release. And then they just have to like wait for another that makes the feature graduation like the cycles longer and it can push the graduation graduations, the feature and like the same thing. I'm repeating myself. So do you have any insight to that? Or like, did you hear anything positive about it, negative about it? If you could share with us, they'll be awesome. Yeah, I just heard positive things, to be honest. But maybe that's because I'm acting as a chair for the release. No, I'm thinking. So from from our survey perspective, so from downstream consumers, we only got positive feedback so far because it seems to be more relaxing right now. And it gives more time for planning and retrospectives and things like that. On the other side, I think it did not change anything to the cycle itself when it comes to deadlines and the stress before deadlines. I mean, we also have those product readiness reviews, which have to be done this enhancements deadline and things like that. So I think it changes not much on that perspective. And on the graduation itself, I think it was it was good because I'm not sure if that's already done. But I thought that sick architecture is having a better guidance to when to graduate features and how many release cycles we want to wait before graduating feature, for example. What recently changed is that better releases are not part not enabled per default anymore because they are not considered as stable. And a decision like this already has a huge impact on the community, right? So because if I have now an alpha feature and I plan to graduate it, because then I would like to provide it to my downstream consumers, then it's not enabled per default anymore. So I have to enable it manually. That's one that's one point. So I think the change of the cadence has impact on many aspects of the project. We are probably also not aware of. Thank you for sharing that with us. And I also want to give another shout out to the well run release team shadow program, which is so successful that I hope to see it getting adopted by other other six within communities or which is already happening. I see a lot of shadow programs and I think it's so successful that it can be adopted across many, many other was the open source projects as well. So I have benefited personally and and that's there. Like this that's been a really great thing. So I just wanted to like highlight and say like when I think sick release, I think of the release team shadow program. Yeah, and you joined sick release in one eighteen, right? And you were part until one twenty two so for four releases, which is really, really great time. And you let one twenty two. I mean, really, I would like to give this shout out back to you. Thank you. I couldn't have done without all the support of the community. So thanks and moving, moving on moving back to Langton. Do you have anything on that? Yeah, I was going to actually take it totally differently. So upcoming releases, what are you most excited to see land? Whether you know, whether the things you you did or you know, things that other people have done, what are the things that you think are most important to be watching kind of going forward? Are we talking about one twenty four or one twenty five? Because you decide, I was kind of saying like, like, you know, kind of the next few releases, you know, whether it's the next one or the one after that or both. Or yeah, I mean, it's an interesting perspective, right? Because from a developer perspective, I'm already in planning for one twenty five. And for folks who want to upgrade, they are probably reading the release notes for one twenty four. So I'm really excited about the doggership removal, because we can clean up some code afterwards, and not only from the from a user's perspective, but from a code organizational perspective and also testing. And so this has a huge impact to test infra and things like that. It's great. And yeah, for one twenty four for sure, I love that we have the container image signing in. That's that's also a great feature. And for one twenty five, I'm really looking forward to also not for example, small things like removing the second annotations is something which really reduces the logic for example, when it comes to converting those annotations to the profile fields and the other way around. So we will can remove a bunch of code. And this also will automatically increase the security because having less code means higher security, right? So that's really cool. And we have we also have some some changes under the hood, which are about the container runtime interface. So we have introduced some kind of versioning from we won alpha two. It was years ago we won alpha two. And then we graduated it to we won because it hasn't been changed. It has only some fields have been added over the past years. And that's also now a point where we can remove the support for one. We won alpha two and therefore we can remove huge amount of conversion code in between those versions and things like that. So that's that's something where I'm really looking forward to. But it's probably not the most fanciest features. So yeah. Yeah, well, I mean, that's kind of that's kind of why I asked the question, right? Is that I wanted to what your perspective of the of what's kind of upcoming. The other thing I wanted to bring up is as I know you both are very aware is there's a certain event happening in Spain relatively soon. And I think you're both pretty involved. I wanted to be involved and then couldn't actually make the travel happen. And so can you tell me a little bit about QCon? You know, maybe I believe you're both presenting. But Sasha, if you could tell us a little bit about what you were going to be talking about. Yeah, unfortunately, I cannot attend in person as well. I kind of I mean, there was a bit of back of fourth in discussion and then I decided to not go because you can get all this content also virtually. I know there is this whole get together and things like that. But yeah, I'm looking forward to to have a chance in North America by the end of the year. But yeah, we have I have three talks, but it's not like that they are that they fall into the same category, right? Because we have this cry or update talk, which is which is something we really do every time. And I think it's really important for the community and also for us to get new maintainers on board to give an update on cry or what we plan and what we achieved in the past and also to reflect for us as maintainers. And then we have this equalese update, which is necessary for my point of view because we had it hadn't that probably us. Yeah, we had only one or two. We only had one and this is really something I'm looking forward to. And then there is this where I'm personally proud of is the second talk where we where I can present how we can craft custom second profiles. And this was I'm kind of proud of it because I did the submission alone and it went into the conference by the by the usual track, right? So the usual reviewers decided to let give this talk a chance. And I think there are only eleven or twelve talks from all submissions now part of the overall schedule, which is really amazing because this totally trumps down to to only let a small amount of percentage go through this whole review process. Yeah, yeah, no, definitely. Go ahead, Savita. I am so excited. Oh, no, I am excited to go watch that, like whenever it seems the second profile because we talked a bit about it today and I did my research and I'm like super excited to go to the one in addition to other maintenance sessions at KubeCon. And the thing that I like the most is that some of these can be since they will be available on the YouTube. So you're not in a hurry. Like you can watch and we watch and you know how to reach out to the main dinner or like the presenter so you can always like how questions reach out to them. So that is one of the things that that came out of this pandemic, the conference is moving virtual. I learned how to connect with people virtually. And yes, back to KubeCon. I have like three sessions, but one of them is a maintenance track for security, which I am excited about. They are awesome bunch of people to work with. They create a very warm, welcoming safe space. And I'm so proud to be a part of that session. And another one is about burnout. I signed up for way too many things because I wanted to like toxic KubeCon. I enjoy, I love KubeCon. I get to meet my favorite people. I get to meet new people. I won't call it toxic, but tiring, tiring KubeCon. I would call that I'm an introvert. So it's tiring and exhausting. And for after KubeCon for a week, I don't want to meet or talk anyone. So definitely training. So I have that one about burnout. Another one is a students panel. So I'm happy about that. KubeCon now has a student track because those are the future, right? Future of open source, future of engineering and future is in the hands of students. So having a space for students is like wonderful. When I was student, I didn't have these many resources. And now I see like how much we can help and give back and start nurturing from when they are like, you know, like when from a little seedling that's how I love plants. So I'm just sticking back to the plant analogies that make sense. So like, nurture them, like provide them with all the sources. So these are the little things that I love and I'm like so happy to be a part of. And I'm a little bummed, Shasha. I was hoping that I will see you in person, but there is always another KubeCon, right? This is the beauty of KubeCon. You don't have to feel like you're missing out. There is always another one, the same for Langdon. I was excited that oh, he's going to go to KubeCon with you. But now I will see you at KubeCon anyway, probably so. You have Detroit versus Valencia. Maybe we could have KubeCon and also in Valencia. But yeah, I totally hear you. Yeah, it would have been nice to be able to get to see some people, you know, being back to traveling a little bit. Speaking of students, I would also, you know, being a college professor that was part of that was part of why I joined. That's why I kind of decided to get into academics is try to see how we could, you know, point students kind of in the right direction towards, you know, software engineering. You know, a big part for me is actually been trying to build out on ethics and on, you know, making sure underrepresented minorities are, you know, supported and encouraged. So those are some of the really important things to me. So I totally agree. So we are, we're coming out on time. We still have a few more minutes, but I did want to ask, you know, so Sasha, I was looking around. Usually I try to find a hobby or something to talk about on the show. However, you seem to be a lot like me in that you get the only hobbies you really have or also technology. Is that, is that fair to say or is there something else that you're super into as well? Yeah, I mean, hobbies, right? So hobbies come and go. I mean, this little toddler is kind of my hobby now. Yeah, yeah. I've been speaking about spare time, but I'm really into making barbecue, right? So this is something, so cooking, grilling and all those kinds of stuff. I am also super into cooking. Yes. Okay, so what did you barbecue most recently? I most recently read a pizza on a pizza stone. Nice, nice. That's pretty cool. Yeah, I just did a pulled pork over the weekend. So I totally understand. Yeah, it's a lot of fun. And funnily enough, there's actually a, there's a Cosmopolitan magazine, which, you know, is largely targeted as a, you know, kind of a women's magazine from I think it's 1969 that encourages women to get into programming because it's just like having a dinner party. You know, you build a recipe and then you follow the recipe. And it's funny how much, like how accurate that feels to me. And I think that's why cooking really appeals to me. You know, it's kind of like programming. They're very, very similar in a lot of ways for me. I totally agree. I mean, also the time aspect is interesting, right? So you can't, some things you can't cook fast. You have to take your time and that's the same for software as well. Yes, yes, exactly. And I much prefer the things that go fast. You know, a lot of the time I prefer to make a stir fry than I do a smoked pork, you know, but I like the smoked pork result at least as much. All right, so Savita, did you have another question or any other comments you wanted to make? No, I think I am done with all the questions. The common though is that I love eating when you are talking about the cooking part because I cannot follow a recipe. I cannot follow anything to the tea. I struggle and every time I end up making something new and it tastes yummy, at least my husband says that because, you know, he has to live with me every day. So, but I can never follow. So I have like much respect like when someone says, oh, I baked this, I made this and I spent like four hours marinating this. I'm like, you are God living to me. I'm impatient. I just have to have a healthy meal and like preparation time 15 minutes. And eating time is like inhaling the food so I'll be like done at like five minutes. But the only food that I love, I take time with pizza. So that's fair. Yeah, what's funny is my kids have actually regularly asked me is like, why didn't you ever become like a chef? You know, you're a pretty good cook. You enjoy cooking. And because the reason is, is I don't wanna make things the same way every single time. Which if you're a good chef, that's what you do, right? In a restaurant, right? As you, you know, you find a really good recipe and then you make it exactly the same way every single time. So, Savita, I don't think you're in the wrong place making it differently each time. You know, as long as it's going, you know, upward, you know, as long as it's getting better. But I have definitely had some pretty massive fails with, you know, making it up as I go along. All right, so I think maybe we should wrap it there. We're a little early, but I think that's okay. And we will encourage everyone to, you know, find Sasha, find Savita at CubeCon, whether it's virtually or in person. And, you know, definitely you should try to attend, watch some of these talks. It's another good way to get involved in the community, both from a perspective of trying to understand what's happening and who is impacting the project, as well as getting an idea of what's, you know, coming forward in the future. We'll probably recap a bit of CubeCon in our next episode. And I think that was it. But yeah, hopefully we're gonna have a nice big KBE presence at the next CubeCon in NA, you know, and we'll be finally, finally maybe out of the COVID, you know, but we'll all continue across our fingers. Good luck with the toddler and they, and both of you, good luck with CubeCon. And thanks so much for coming, everybody. And we'll talk to you all again soon. Thank you for having me. Thank you, thank you everyone. Have a good night.