 Okay. Hi everyone. Welcome to the last day of QCon and kind of one of our, you know, traditions to kind of make the, you know, our technical board, the TOC, kind of more open and welcome to all as we generally host this TOC session to kind of explain, you know, how we work as an organization and have an opportunity to meet folks that are on the TOC. So, you know, we have technically 11 people on the TOC. Not everyone is here physically with us, but we have a good representation here. I will go and, you know, start introducing everyone here and they can kind of talk a little bit about who they are, which company they work for, or what project they're involved in. Let's go start with Richie. Okay. Yeah, I'm Richie. In the context of here, yeah, Permissive Team Member is probably the most important one. Hello everyone. Katie Gomanje. I'm currently working for Apple and end user organization. This is my second term as a TOC. Hi. This is Dimms. I do some stuff in Kubernetes. I shouldn't, I should stop saying that because I'm no longer on the steering committee. I work on several SIGs in Kubernetes community and my employer is Amazon Web Services. I'm Justin Cormack. I'm a Docker. We're involved in a whole bunch of projects, distribution, notary, container D. We're a very developer focused now, so I'm interested in the fact that we've got a lot more developer focused projects coming into CNC. And I've also been working with tech security for a long time. Hi, my name is Casey Zhang. I have been working at the, you know, serverless projects and those serverless related projects and also Kubernetes projects. Hi, I'm Matt Farina. I work over at SUSE and we contribute to a number of the various projects. I've worked on Helm and Kubernetes and Artifact Hub. Right. I'm Ricardo. I'm a computer engineer at CERN and I'm in the TOC as an end user representative. My name is Amelie Fox. I'm a security engineer at Apple. I am a security liaison in the TOC to tag security and I do a lot in the community and various foundations. Cool. Thank you. And for the folks that couldn't attend, I think Dave Zolo is at Spotify. I've been heavily involved in the backstage project. Aaron Boyd, who is at, nope, Red Hat now, back at Red Hat, has been involved in a lot of storage projects. And then Harry, saying from Ali, who can't make it here. But this is kind of our group of folks that overall decide the technical direction and vision for the organization. So I'll do kind of a brief kind of refresher for folks that don't really know how CNCF is structured. This is kind of how the sausage is made and less interesting in my opinion, but does give you kind of an important insight of how the organization is structured. So my name is Chris Anizic. I'm sort of the CTO of the organization. I helped started about seven years ago and the way the organization is structured, you basically have a separation between business governance and technical governance. So there is a board of directors, a governing board that decides basically, you know, the overall kind of, you know, how the budget is spent, how the overall strategy for the organization goes and kind of is shaped over time. It's mostly consisted of vendors, you know, that kind of build products on Kubernetes and other CNCF projects. There are some end users there. So they handle like the boring business stuff in my perspective. You have the technical oversight committee or TOC, as we call them. The 11 folks that generally have worked on, you know, CNCF projects or have deep technical expertise in some domain. They are the folks that decide which projects get into the organization, which projects get archived. They decide the overall technical kind of strategy and vision for the org and they kind of act as a resource and a liaison between projects, the board and kind of, you know, and also the mentors to kind of help projects out. And then we have an end user kind of group that essentially represents end users. People who are building and using, you know, CNCF projects in interesting ways, but actually not selling them. They're not selling cloning services or they're not really vendors. So this kind of three weird, three ring circus makes up the CNCF and the TOC is kind of, I have a view in the middle of it kind of bridging the gaps between these organizations. So one thing that the TOC does is help, you know, come up with a set of principles. This was recently refreshed. Thank you very much. I think it was Emily that did a lot of that work. So appreciate that. But in some, you know, to kind of summarize things, you know, the organization, you know, tends to put, you know, we're project maintainer first. So we're very project centric, you know, each project kind of operates on its own. Projects are self-governing, which for you who may have, you know, had experience with other open source foundation, whether it's like an Apache or an Eclipse or OpenStack, CNCF is a little bit different where we kind of leave projects to their own devices to kind of come up with their own way to operate, which is, you know, could be a little bit confusing, but gives people the flexibility to operate. Some have steering committees, some don't, some have a flat list of maintainers, some have senior retainers. So projects are very self governing in how they run and operate. What does the TOC look for? In general, they're generally looking for high quality velocity projects, but everyone has their own, you know, preferences. The other big thing here is there's a philosophy around no king makers. So, you know, generally we allow competitive projects. So there's, I can't even count how many service measures anymore. You know, there's budget get-offs projects, there's a little overlap in competition. The whole idea is to, you know, not have just one prescriptive, you know, solution, allow kind of competition and allow the market to kind of, you know, flourish and kind of decide what is, what is, what is best. We're not really a traditional standards body, so we don't really do long international ISO style standards. We more do de facto standards that are defined by code. Ideally, you know, everyone's seen that crazy landscape, love it or hate it, you know, I still have the fun job of maintaining it. The idea is to kind of make sure that we have a comprehensive tool chain that sits in CNCF that people could use these, you know, wonderful projects to build products or in some other way kind of fill the gaps is kind of the, the attitude we have. And like above all, you know, the TSC kind of wants to stay out of the way. They just want to help projects when they need it. So I think this kind of set of principles has served the organization fairly well and, you know, they're not locked in stone. It could always evolve these if we need to over time. A lot of people ask, how do I get involved in this like mysterious body? Sometimes well, the best way to get involved is to actually contribute. So we have a variety of technical advisor groups. We call them tags. They usually represent some topic area, security, storage, you know, contributor strategy, observability. These are the best avenues to get involved if you ever want to potentially, you know, run for a TOCC. It's a great avenue to kind of get started in my opinion. Sandbox processes, project processes. So there are three different types of CNCF projects. We have sandbox, incubation and graduation and they roughly map to maturity level. Sandbox projects are early stage. They're meant to be experiments. Some fail. Some grow into crazy large projects. Incubation, a little bit more mature. There's probably a little bit more diversity in the project in terms of maintainers, more companies involved. And then graduation, which really is the TOC's like stamp approval that, you know, this project is mature. You could bet your business on it and use it and not worry too much over the long term. So this is kind of the thing that they, you know, as a group control overall to ensure that, you know, end users and adopters of software have some type of stamp to look at, right? We do have a brand new sandbox process that was just, you know, refined. Thank you to everyone who worked on that. So we're moving it back to GitHub off of this crazy Google form that we had for a while. So you'll be able to just use the GitHub slash CNCF sandbox repo to file applications now and that will be done in a little bit more transparent fashion than it was done before. So, you know, we kind of keep this informal. Like, you know, from my time as organization, a lot of people have asked like, oh, like I would love to like go meet a TOC member to ask them about, you know, project or some questions. And this is really about kind of lowering that barrier. You know, here we are open to take any questions and, you know, meet folks that may have not, you know, met each other before. So I have some kind of like basic questions that I've kind of always asked. I think I'm going to ask a couple. And then really I would just like to hear, you know, from the audience of like, what do you want to ask these folks, you know, anything, you know, you know, anything, you know, dramatic or, you know, just like random questions of like, you know, what do you think about this? We'll have that option available for you. So, you know, my, you know, you know, we've probably accepted almost close to 30, you know, or so projects, you know, you know, this year. And, you know, I would love to kind of hear the TOC's thoughts on, you know, what it's like, landscape keeps growing. I'm merging pull requests almost every day on this thing. What is missing from like our comprehensive, you know, tool chain? Is there something particularly missing that you're interested in that you want to fill and see maybe our community help out with? Or is there something that, you know, you think we should focus on kind of like, you know, in the future? So like, either like, what's missing or what do you think are the future directions for us as an organization? Anyone want to start with, you know, potentially what's missing? Tim? So, like one pain point we've had for a while is we don't have anything to keep secrets. So, that is probably one thing that if we want to fill the void, we should probably start there. But there's so many things that we need to do and we should be doing. But from the point of view of the users of our ecosystem, they don't really have an option there other than WALT, for example, right now. So, we should try to do something about it. I can go next. I think the landscape has been growing a lot throughout the years and everyone can see that. There are a lot of means around the vastness of the landscape. However, I think nowadays we reach a maturity level where multi-tenancy has not been solved as a problem that well anymore. There are multiple solutions that have been multiple initiatives to do that. However, we don't have anything comprehensive that is truly open source based and it's not just delegating a problem to a vendor. Supposedly you don't have the money to do that. So, I think that's definitely an area that requires improvement. Another one I would like to mention and I think it's an ongoing thing is simplifying developer experience. It is overwhelming to consider how many tools you have to use in production. You're not going to use just Kubernetes. You're going to use at least a couple of tools for observability. You have networking, you have storage, you have runtime, secret manager. It's just vast. Like as an engineer you need to work with at least 10 tools and this is the minimal viable option for you to run a very successful production environment. So, in terms of improving and simplifying the developer experience, I think that still requires a bit of work from our community. YAML is great but maybe we need to look at the next best thing and try to include more people from different development backgrounds to be able to configure and deploy Kubernetes and anything related cloud native. And then the last thing I'm going to mention, I know it's not going to be very technically infused. However, I think we need to work better at developer retention as well. It's not necessarily like what's missing in terms of technology aspect but we definitely need to make sure that all of these projects are going to be long-standing as well. So I think it's like an ongoing thing that I just cannot not mention it. So here we go. I think we know that sometimes for same space or problems we have multiple projects. I think it's not very easy for the end user to choose you know which one should I use or should I deploy. I think one way we can help with that is we can have a very good document on what are the you know overlapping functionality, what are the differences, what are the different user scenarios, and also the architecture difference. And it will be better if we can have the pros and cons of each project. What is the pros and cons? I think that and the user scenarios I think that's very important to help users to choose okay for my scenario which one I should it's better for my user scenario. All right I'll mention something as well. I think one thing where there's still work to do is the area of managing multiple clusters. It's a common pattern that has been picked up for a while now and not only managing those clusters and the applications but also handling like scheduling of applications across multiple clusters. It's something that quite a lot of people struggle with and there have been multiple efforts to try to solve it but I don't think we're there yet. So there's still space there. I think there's still a bunch of gaps around developer tooling and I think you know we've done a good job of making you know getting Kubernetes out there and the bits you need to operate it but the the whole developer focus we started having a few more developer focus projects recently but there's still a lot there's a huge kind of gap there. And we've got a few WebAssembly projects which is kind of cool but there's a lot more scope there too. The tooling around what should actually exist arguably lacks something. Of course as Katie mentioned YAML is nice but when you look at where it's coming from it's a serialization format where you have something else which was compiled into this and the whole space of defining what should actually be running and what should be deployed is extremely hacky and there's no defective standards in this area. Cool that's good so I'll ask I think one more one or two more questions and then I'll we'll hand it off to the audience to tell us. So you know I had a crazy week at KubeCon probably met you know thousands of people attended a few sessions. You know what was kind of maybe the most interesting thing that you saw or kind of thing that surprised you in terms of maybe like a technology or project so for you know me I was kind of excited to see how much you know people are experimenting with WebAssembly you know today Justin for example you know Docker integrated with you know Wazem you know Edge and then kind of modified the container Dshim to support that in kind of the workflow so I'd be kind of curious if there's any TLC members of like what did you see that you thought was like interesting that you know caught your attention that you know you think it's potentially promising for the cloud native community. Looks like Matt wants to speak about them. I mean excuse me I was just gonna second WebAssembly. I think WebAssembly is one of the neatest things that I've seen in a while with its potential around performance resource utilization the security model. I'm really the speed at which it's gone from something that we're tinkering with to being something that you can really consider is is pretty fast and I'll be curious to see where it is a year from now. I expect a lot of great things. So well not necessarily at this conference. I remember early on when I got started in cloud native I was introduced to the idea of a sidecar and like how much coming from former government that sounded like agents on hosts all the time taking up compute and resources so it's interesting to start to see projects talk more about sidecar lists and what does that mean but the amount of innovation that can happen on top of that once that's removed from an entire architecture could potentially unlock new technology emergence. Anyone else? I think I want to add on what Emily just said. I think one interesting part is proxies service mesh. I think that one you know it will help you know reduce the overhead of the sidecar. That's a good that's a very interesting direction. I mean I always like to see all the new faces at KubeCon the new people who are coming along for the first time it's always really exciting but you know the people are people are still coming into the seeker system it's still growing still a lot of work to do to help them and it's that's always what I kind of find exciting here. Cool anyone else otherwise we'll I think one thing which I find super interesting is that initially cloud was like about breaking out all those old service barriers and making everything horizontally scalable and like making things much more malleable and you see this trend going backwards again like it's not all tiny microservices anymore you have a need for multi-tenancy their sidecars their service meshes like all those old concepts of how to deal with the total amount of complexity are coming back in this pendulum swinging back and forth as we try to figure out where the nice point in between us it just find this super interesting to observe while not super interesting what has become important to me is like just seeing the scale of you know how many clusters are out there across the cloud providers and how people are able to do day two stuff to upgrades you know scale everything and how it's becoming ubiquitous now with almost all like you saw some numbers right like Gatna was talking about like 95% of new projects will end up using some Kubernetes angle or so we want to get boring so it's not interesting but there is still a lot of activity coming from the Kubernetes team so you know there are certainly challenges around like upgrades and things like that but we would welcome more participation in the different projects not just Kubernetes to make the ecosystem healthy and make sure that it's going to be there to serve you in the you know future. Thank you Dims. So we're kind of a little bit about halfway through so I'd love to kind of turn it over to the audience the whole purpose of this kind of session is really to kind of introduce people to the OCE humanize make it more make them more accessible to to everyone to ask you know questions so does anyone have questions out there that they would like to ask the Steam TOC there's a gentleman in the back with his hand so Kristoff so we'll start with you and then we will see you else great so thank you so the cloud native space is really broad and a lot of the kind of edges of the space are even growing to things outside of cloud native where a lot of projects are getting use outside of that space so it's been some discussion about potentially dual homing projects or things like this with things like the open SSF and I just wanted to know people's thoughts about it thanks so much for the question Justin it's funny that you mention that I've actually been in communication with the open SSF technical advisory council as well as their governing board about what does it mean for projects moving forward as more and more foundations set up and there's a lot of overlap between the projects and the efforts and initiatives so I believe that the CNCF TOC Open SSF TAC and other foundations are starting to figure out what does that look like because we still want to be able to empower all of the projects underneath of each foundation in the way that those foundations are set up to be run and those projects are established to be governed but still allow that open collaboration across different groups because ultimately there's only a few folks with certain specialty skills that can translate between the different foundations and we certainly don't want to be pilfering talent from one another when collectively we need to move forward together there is an open GitHub issue I think where this is being discussed that you kind of follow and from a Linux foundation perspective a lot of these things are structured differently some are more focused maybe on specs or communities of practice some are security focused or maybe more policy so I think at the end of the day people have realized this is somewhat maybe confusing for end users I mean you need to figure out how to work together in a way that makes sense that doesn't make the legal side of who makes decisions who owns things how that's governed and it doesn't confuse that aspect with the actual needs of the community go ahead Right One second I'll finish this So far it's been people floating around the different organizations but you know we have done it before right like OCI arc and projects here overlap a lot because both deal with containers so I would like to turn that question to ask what is it like that you would see as a benefit of the collaboration and how what it should look like going forward that will help inform us on what we need to do on our end Yeah that's great in fact I was going to have a follow on comment which is to say I'm really happy with everything the CNCF has provided for Tuff and in Toto and you know think overall the CNCF does just an amazing job and so from my standpoint I guess my view is that it's another way that the word gets out about our projects to other communities because one of the problems that we had early days with Tuff was getting people to see it as something that was useful outside of cloud native and then once we in fact rebranded it as a new name Uptane that is now very widely used I was just at a conference last week where thousands of IoT companies are all using it for different things that they're doing and so we might I think we probably actually have more use outside of cloud native than we do in cloud native but we kind of rebranded as part of that and so I don't really know the answer to that question you all have been great but we're viewing it as another community that can ring the bell and say this is something that's useful outside of cloud native as well as in the domain there are definitely marketing aspects that will be useful for sure you know we have to also figure out like what is the community collaboration looks like as well thank you thanks for your question two hands up up here I don't know who was first so this is not actually a question but my comment on that based on the having been to the Kupecon there are lots of previous years because most of them do you have any plan to have a you know plan to encourage those projects to share the failure not success story because we when you know Duncan is you know on the stage that he tried to you know present lots of failure story not but not not only for the success story but so that most of the people think that you know failure going to be the inevitable but you can get back from failure to be successful so right now most of the keynote speech keynote presentations more like we're good we're great we're so good people we love you so much but you know the cloud native is more like you know the failure is the the fact or maybe is included then we have to make it to more reliable based on the failure to recovery with those kind of things so do you have any plan to encourage those projects to share their failure story or something there's a there's isn't there like there's a the famous like Kate's fail site whatever it is which is hilarious so we did start one as a community member started and all of us contributed to it it's called Kubernetes.af so if you go there you will see all the horror stories and we always encourage people to post their own you know journey so to say there are I mean if you just Google for it you will see why I didn't use Kubernetes right like there's lots of stories like that we talk about the failures all the time you know what went wrong and why we were not able to get a feature or like we had a feature we're gonna drop it because it was not working properly right so we talk about failures all the time yes we need to figure out how to do this in this environment where 60 percent are newcomers who don't know you know so it might turn them off a little bit so you know yes you're right we should do more of it and people will learn more from it than all such the stories yes thank you I have a comment to this one as well actually while you whilst you were asking a question I realized we don't really talk too much about our archived projects because they were actually very successful at the time when they entered the space and they were archived and this is a very normal step for all the life cycle it just didn't reach for example maybe the or didn't cover all the use cases that we had within the adoption base so I think maybe we definitely should have a highlight session of why the projects were archived and and celebrated because they actually did a lot of they had all the impact on the ecosystem and we actually should treat it as such so I think this is definitely something that I will think I will submit as the next keynote or keynote talk you cannot submit a keynote but you definitely submit a talk so I think that's going to be a very good insightful journey for the projects as well not just from the adoption side I think so yeah thank you for the question very good pointer we'll take that feedback as maybe to the program chairs of kubecon maybe we need like a fail track like let's talk about like all this or tag fail yeah exactly yeah so that's good and then I think yeah one more question yeah so about the sandbox process so we have a new sandbox process that's on github right and we've all talked about it what future improvements would you like to see to the process and is there anything that community members can do to help it so I want to just clarify are you talking specifically about sandbox or about all of the the entire graduation cycle so we actually had an excellent meeting earlier this week with a lot of the tag chairs a lot of them were able to make it in person some of them were available online but it was a good opportunity for us to hear a little bit more about their concerns with the current process because we do still have some communication challenges and ensuring the things that the TOC discusses and gets out of our head are conveyed in a way that's actually actionable both for the projects themselves but also the tags because we really rely on their expertise of the various domains that they cover to assist us and extend our body of knowledge so it's relevant and actionable for those projects so as a result of that we've been really thinking through how we can go about changing sandbox to incubation how do we set projects up for greater success how do we allow them to do better self-governance and ensure that the kind of like road bumps and detours that often happen with projects aren't a new learning experience for every project every single time so if that means defining milestones for projects to hit before they're eligible for application to incubation maybe that is getting sponsorship or recommendations for multiple tags who have looked at the project of their various domains because a lot of this stuff overlaps if it's security if it's networking if it's storage anything like that getting that feedback from them and also that drives a lot more contributions back into the tags as well so we're we're considering a lot of changes but we really need the community feedback those who have been through the process to understand everything to help us out it's pretty clear you want to I think part of the reason we've been changing the sandbox process a few times is just it's been incredibly successful we've led an awful lot of projects in and there's still more and more demand to come in so I think you know it's really you know we we know that the backlog is too long it takes too long like the all the original changes were to make this process faster but it's still it's still having to scale up because there's more and more demand and we have a lot more projects now so we know we're a bit we know we're kind of overwhelmed by the by the number of projects we have to review and we're trying to get make it easier and and continue to make it easier so you might have noticed a trend that we are using which is when we are having a discussion we try to put it in an issue so we don't lose track of it right and when people come to the Slack channel and say hey this is broken or this is not working we say go file an issue so we don't lose track of the things that you are telling us what is broken right so this feedback loop and doing it asynchronously helps a lot we earlier we used to try to do things in a Google doc and get to a consensus and things like that it was very hard and like all of us have like Google docs going way back which we never did anything about right or it was hard at that time right like we we kind of reached consensus but then you know something came up or something dropped so our focus changed and then you know we left so we are trying to do this consciously so you can hold us accountable for the things that you have told us that we need to worry about or fix or change so we are trying to do that consciously now so and we are inviting people to like help with PRs to existing documents and such as well so we want to you know we can't do it without you all right like so I would like you to participate not just in the tags in the TOC also okay two minutes thank you so I think there's another missing part we can help is we can help connect the projects which need more contributors to people who would like to contribute because sometimes we found out the project and do not meet the requirement is not because not enough people are working on it right for every aspect and then there are some people we know from some companies who would like to contribute but they don't know which one you know best match that skill set or which one need contributors so we're working with a contributor strategy tag there's a but tag I'm not like contributor board which you know you can go and then you know to reach out to them to tell them you know what contributors you need you need right in which area and then they will try to help to match that awesome so you know we're basically out of time so wanted to say two things TOC tries to be very accessible there's a Slack channel there's open meetings please join those one important thing to note is we will have elections soon so there'll be a blog post coming soon and and an upcoming TOC meeting we will mention the whole process so if you're interested in running and trying to figure out how that all works stay tuned we'll have all those details out there pretty soon but thank you for attending and thank you TOC members for for being here and then supporting the the community so thank you all to attend and hopefully you enjoy the rest of of Kubecon so yeah