 I also posted the meeting minutes. So if you're attending, please add your name there. Is Sylvain on? I know some folks are on vacation. So, hey. Hello. I appreciate it. I know it's apologized on timing. It was hard to get everyone. No, it's fine. Okay, cool. I know Tammy is also on vacation. So I don't know if she was gonna be able to make it, but we'll see. I think she said she was gonna catch the next one. Yeah, I know. Right now, you know, I don't blame her at all. Yeah, it's hard to schedule everyone, but this will be fine. You know, these things always have, like, humble beginnings to start. So we'll give it another minute, and then I'll get started. Oh, cool. Got someone from Poloski. Okay, cool. Awesome. I'm talking to some of your folks tomorrow. Mikheilish, I don't know if you're on mute. Hi, guys. Adrienne Cockroft here. Just joined. Adrienne, how's it going? Good. We'll get started. We're putting this together. No worries. We'll get started in a minute. It's a bit of an adventure to kind of schedule everyone, but to kind of get things bootstrapped, this will work out. Is Mikheilish from Bloomberg here or no? Or are you on mute? All right, I'll assume he's on mute or on the phone. This is Nora Jones here as well. Say that again. I'm here as well. This is Nora Jones. Oh, Nora Jones. Cool. Pleasure to meet you. Nice to meet you. Yeah. I'll put you on the attendee list. Give me a second. Hey, this is Deepak Srinivasan. Cool. Good to meet you, Deepak. Hey, good to see you all. I'm from Capital One. Okay, cool. Make sure to add yourself on the Google Doc meeting minutes, please. I don't see you there yet. Sure. Hey, everyone. This is Brian Hammons from AWS. Awesome. Great to meet you, Brian. Yeah, nice to meet you too, Chris. Hi, everyone. I'm Karthik from OpenDB. Good to meet you, Karthik. Thanks, good. Thank you. All right. So it's about five minutes past. Generally, kind of the buffer we give folks. So I kind of want to thank everyone for attending this kind of bootstrapping meeting for building a chaos engineering working group in particular. I'd kind of like to thank Sylvain and Tammy who couldn't make it because she's on vacation to kind of prodding us to kind of do something. And we've had a lot of members in the CNCF community that kind of have built their own and kind of homegrown chaos engineering approaches and have asked these CNCF to kind of come up together to see if we kind of get people together and share practices, tools, and kind of see if we kind of do something to help improve a state of chaos engineering across the industry. So I'm gonna kind of dive in and go through a presentation introducing kind of the goals of the group, kind of what are expected outcomes and how we'll be forming this over the next few months. But before we fully get started, I might as well introduce myself. So my name's Chris Anizic. I have a fun job of running the CNCF, Cloud Native Computing Foundation. That's part of the Linux Foundation. So it's been kind of an interesting journey seeing this foundation grow over the last couple and a half years. So we kind of have all major cloud providers involved with a variety of kind of startups that are operating in the container in cloud native space. So that's me. So I know some of you have mentioned your names, but I'd love to kind of go around and feel free to say something a little bit about yourself, where you work and kind of how you're involved with chaos engineering. All right. Okay, I'm Chris Short. I work with SJ Technologies. We do some DevOps consulting type work we're big in security right now. So I'm trying to drive chaos engineering as a way to enhance security within organizations. Thank you. Hey, I'm Michael Keough. I'm from LinkedIn. I'm a partner to our WaterBear team, which does a variety of different resilience or chaos engineering efforts within the company. Thanks. Hi, my name is Brian Hammons. I'm a solutions architect at AWS. So I was over at CNCF and was able to kind of sit in to one of the workshops and I really resonated with me. So actually Kubernetes SME over here. So I wanna kind of see how it kind of applies with that type of containerized methodology and kind of explore that a little bit more. Awesome, Brian. Thanks. Paul Jones, a software engineer with spoke to Sylvain at QCon last week. So I'm really interested to just get more involved, really. Hey, so Adrian Cockroft here at AWS. Been talking about chaos engineering and the architectures for this for a while. And been talking to, you know, Sylvain and also the board rep for CNCF. I've been working with Arun. Arun Gupta, the two of us are kind of the key CNCF people at AWS. So glad to see this come together. Hi, Nora Jones. I work at Netflix on the chaos engineering team and we're part of the greater resiliency engineering work. I've been doing chaos engineering for the past couple of years now. And Netflix is definitely interested in getting a little bit more and getting a little bit more involved in this chaos community and seeing what it's about. Hi everyone, this is Karthik. I contribute to the OpenEBS project. OpenEBS is a content-raised storage solution for Kubernetes. So I'm part of the DevOps and the E2E team. So I've used tools like KSQ, Pumba, et cetera before and I just charted up with Sylvain before QCon was really interested with what we were going to do with chaos engineering. I'm looking at chaos engineering as a tool as a method to test the resiliency of the storage solution. Not just for OpenEBS, but for StripLoverClose in general. Oh, thank you. Cool, I'm Ryan Dooley. I work at a large fruit stand in Kipper Teenhill and we're working on building out a chaos engineering practice. Cool, thank you. Hey everyone, this is Deepak Srinivasan. I'm from Capital One, I'm a software engineer here. So chaos engineering has been evolving in our organization here and we've been doing some exercises at production level. We have a homegrown solution as well, but I'm also interested in partnering with the community and then talk about the best practices and collaborate here. Thank you. Hi everyone, I'm Michael Daniela. I work at Carbon Black as an SRE. I'm interested in building out chaos engineering within our org and I was also at KubeCon and Copenhagen, got excited about the stuff. So here I am. Cool, thank you. Hello, my name is Reda Banzer. I'm VP engineering student, but also a science ambassador in France. I'm managing the Meetup at the Paris Science Air Force and helping the community to grow in France or the initiative around also cloud engineering. Oh, thank you. My name is Matthew Brahms. I'm an SRE here in Austin and I heard about this for the first time at SRECon this year and would hope to build out a program here and see how it can help out the CNCF. Thank you, Matthew. Hey, I'm Matt Fornesseri. I'm a CTAO and co-founder at Gremlin, which is aimed at bringing chaos engineering to the masses. I got my roots in chaos engineering back in 2010 over at Amazon when we were running game days on the retail website. So it was real fun to see back in the early, early days. Awesome, thank you. Do we miss anyone? Anyone else? Hi, this is Amit. My name is Miko. Sorry. Yeah. Go ahead. Hey, this is Amit. I am from Open EBS, the same team that Gothic belongs to. I too, I'm looking at chaos engineering from storage perspective. How can we build resilient storage with chaos engineering and factors and tools? Thanks. Cool. Thank you. Go ahead, Miko. So yeah, Miko Lai, everybody calls me Miko. So go ahead, call me Miko. I work at Bloomberg. We work on microservices platform internally, kind of like AWS Lambda for the rest of the company. And we started doing chaos engineering about two years ago. And in Austin at KubeCon, we open sourced the power for steel. I was the main contributor to that. And yeah, nice to meet you guys. Hey, this is Sylvain. So I'm just here to balance Americans versus Europeans. I know I'm a city of chaos IQ and I'm the main maintainer of chaos toolkit. And I was doing those stocks you saw at Copenhagen. There you go. Thank you. Did we miss anyone? All right. Cool. Thank you everyone for taking time to intro. I'm gonna go share my screen right now to see if I can make people's lives a little bit easier. See everything okay? Sorry for those folks that are on the phone. I'll take that as a yes. Yes, yes, yes. Okay, cool. So yeah, agenda. So yeah, we did all introductions. Thanks everyone for taking time to introduce themselves. I'm gonna kind of dive in and talk a little bit about little background on CNCF for those that are kind of new to the community. Then I'm gonna dive in on kind of why we're doing and spinning up this effort in CNCF as a working group. And then kind of just some basic logistics of setting up a recurring meeting time and agenda. I know since we have kind of a mixed audience of North American Europe. And I even know we have some members in China that are interested in attending. It's gonna be difficult to find a time but we should kind of put our foot down and just get something recurring so we kind of keep moving forward with this. And then just kind of opening up the question to kind of share what people feel about this group. So feel free to stop me at any time if you have any questions but let's kind of get going. So there are introductions, chaos engineering. So like I said, me being kind of new to this space it's been interesting to kind of see the interest in the CNCF membership community around chaos engineering. And from my perspective, chaos engineering is basically table stakes for building like large, cognitive resilient systems. You kind of really need to have a chaos engineering practice to ensure that these systems are resilient. So I've been doing some explorations in the community learning a little bit more about the tools, the history and so on. I found this crazy, you know, coggle diagram that someone put together kind of linking the different community and different tools out there. So huge thank you to whoever kind of put that together because it kind of helped me a little bit to kind of understand some of the history and folks involved in the community. So a little background for folks of, you know, what is CNCF? We were founded about, oh boy, it's been like about two and a half, three years kind of late December, 2015, you know, basically with the intention to be a home for Kubernetes which is a fairly popular orchestration platform but also to be a home for more than just Kubernetes. So essentially the idea was to promote the notion of cloud native computing which essentially means running services, package and containers at high scale. And, you know, we've kind of grown to accommodate a variety of projects and working groups to kind of help, you know, accommodate this mission of cloud native computing. We have over 200 members of variety of companies involved. We have folks like, you know, AWS, you know, rest of the cloud providers, bunch of startups. I'm not going to kind of dive in there. There's really no interest for me to talk about that since I spend a lot of time talking about that but feel free, you can see all that stuff on our website. So did someone have a question? Sorry, I heard someone pipe up. All right, I'll assume no. So, you know, moving on, you know, really two things, you know, we're a neutral home for collaboration, you know, across companies, organizations, you know, whether they're, you know, academic or research focused or just businesses. So we have a set of values that I expect, you know, as a working group to kind of follow that is consistent, you know, with CNCF. So I listed them here on this slide, but you know, simply just basic things like, you know, we're open, we're fair, there's kind of no pay to play things, we have a strong technical identity associated with our efforts. We're platform and cloud agnostics and so on. So just something to keep in mind as we kind of spin this up. So CNCF working groups, you know, we've had a handful of these within CNCF, you know, essentially the purpose of these things are basically to study a particular focus area and kind of make recommendations to the wider community and our kind of technical board on, you know, potential project ideas, maybe producing kind of a landscape of the different technologies out there or even kind of like a white paper just detailing like what is this particular, you know, topic area. So just to kind of give you a concrete example of kind of how this works within CNCF is we recently spun up a serverless working group. It's probably been about a year. You could feel free to look at it on GitHub, but essentially they produced two things that I would kind of like this working group to to kind of help produce. One was a simple like kind of lexicon white paper of different terminology involved in chaos engineering, you know, from talking to a lot of folks on this column within a community, I've realized like there's even different aspects of chaos engineering, you know, I was introduced to there's some crazy folks kind of using doing like security focused chaos engineering. Well, they're purposely introducing security issues to kind of see, you know, how their systems react, which is I thought was pretty cool. So basically working to kind of define these different areas in a paper that we kind of share with the wider community would be awesome. You could kind of look what the serverless folks did. I think it's kind of a good example to go on. Another thing is almost every CNCF member that has a fairly large cluster of, you know, Kubernetes cluster, whatever they're using, generally has created a tool. So like the folks from Bloomberg or from Miko have created a powerful seal. There's a bunch of other ones out there that kind of been created. So just kind of indexing and cataloging the different solutions out there. We have this notion of a landscape in CNCF. So I linked to it. If you go to s.cncf.io, you could see all the serverless ones, but I'd love to produce something for the different chaos engineering projects out there that kind of have been collected and built, you know, over the years. So I'm looking for help, especially from this community to kind of help this kind of build this out. So before I move forward, oh, this is the chaos or this is the serverless landscape example, if you kind of want to see like a concrete of how this looks like. So before I kind of move forward, does anyone have any questions for me on CNCF or kind of how we expect this to work? I've got one, Chris, how are you, as you know, is the CNCF monitoring, when I say monitoring, how do you drive the working group? Do you leave the working group to the other thing, you know, on their side, or do you, you know, does it work basically? So yeah, so generally the way it works is, you know, we're essentially what we consider in bootstrapping phase. So we're getting together a bunch of people that are interested in forming a working group. You know, I, from the CNCF staff will kind of help drive this kind of in the bootstrapping phase eventually. We'll have someone from our technical board, we call it the TOC that will sponsor the working group and kind of be involved with it. But kind of like when we're in this like bootstrapping formation phase, I'll be doing a lot of work paired with, you know, whoever else is interested in helping drive this. Sometimes we have a like a working group chair. So if there's folks that are interested working with me and kind of, you know, setting up the basic agenda, meeting minutes and all kind of all the boring stuff behind the scenes, I'm more than happy to take volunteers, but I'm happy to kind of drive things while we kind of get things grown. And I know that I think Sylvain and Tammy have both expressed interest in helping kind of chair kind of move things along, but I'm more than happy to take volunteers from the community. Does that answer your question a little bit or no? It does, yeah, thanks. Cool. So, so moving on. So, you know, I kind of talked about this a little bit of why we're essentially doing this. Like I mentioned, like, you know, at any scale, most of our members kind of have experienced either, you know, with KS Engineering have written their own tools. I've listed a couple, at least from, you know, that are Kubernetes centric, but there's, you know, people have obviously built KS Engineering tools, you know, on all different types of systems, but small list here. The other kind of, I guess, you know, selfless interest I have is, I've noticed a trend where there are cloud providers out there that have started to offer KS Engineering APIs for a lack of a better term. So, like, you know, Azure, for example, has like this, you know, KS Engineering API where it could start chaos, stop chaos, and produce a report. I don't know if other cloud providers are offering this. I have not dived in. I don't know, maybe Adrian, because Cher from the AWS side, but I expect this to be a continuing trend. And it would be great if we could kind of get together and maybe, you know, help, you know, write out a spec or have a kind of a standard interface in place potentially. I don't know. There's also startups out there like Gremlin, KSIQ that are kind of interested in offering KS Engineering as a service. So, you know, one big aspect of CNCF is we would like to ensure that we could build stuff that, you know, aids, you know, portability and makes the lives of our members and community easier and potentially trying out these different tools. So that's kind of my selfish, you know, point of view. And also in general, KSIQ Engineering is still kind of new to a lot of folks. And I think we could do a great job in kind of spreading, you know, and formalizing this practice, at least within the CNCF community and wider industry. So those are my, you know, kind of selfish goals. Sylvain, I don't know if you want to kind of speak to this or, you know, Adrian, you want to comment on kind of your background because you've been involved in this for a long time. But I kind of love to hear, you know, other folks' thoughts on this idea. So Adrian, there are some AWS capabilities that are very well known, which let you do chaos things like the Aurora, my SQL database has some SQL queries, which will actually cause nodes to fail and partitions to happen. So there's some services that do that. We also got some ways to do a zone isolation that we need to kind of look at. We just came up with something recently where you can basically cut off a zone from an API perspective. So not exactly the sort of start chaos kind of thing, but I think you can gather together a number of capabilities to come up with something like that. This is very helpful. And I think it was a good summary of where we are right now. So it looks good to me. Cool. Thank you. It's news to me. So I'll definitely write some of that stuff down and then reach out to kind of help collect collating a lot of this information. Anyone else want to make comments on this idea, what they've seen, Sylvain? No, I think you've done a beautiful job of covering it all. I wonder with all the Kubernetes-centric or oriented open source tool, if there is an interest from the community and from the Kubernetes project to have actually something native inside the department. So our attitude at least within CNCF is we're not a king-making organization, so we're not gonna have like the one-only tool. I think specking out an API or something like that could be interesting, but it takes time to kind of do these things. At least within Kubernetes, we'd have to go formalize like a SIG or a working group within that community and kind of push it. But for right now, I'd rather for us just to like, let's get the right people together, share kind of the tools out there, what the different cloud providers are working on, what the startups are doing and kind of go from there before necessarily targeting a specific project like Kubernetes. Because honestly, I'd love to see some of our other CNCF projects kind of offer chaos engineering specific abilities. At least that's how I view things. And I know that CNCF is more than just Kubernetes, there are other kind of orchestration systems out there that are involved in the community. Sounds good. Yeah, I think that's right. There is definitely, you're sort of gathering together lots of capabilities. And so it's not necessarily that you need to say there is a feature here that implements chaos engineering. Yes. Some of it is sort of a bit of IP tables. It's a bit of killing nodes, a bit of doing configuration changes. So mostly it's manipulating the configuration in certain ways. And then if you look at some of the chaos toolkit, it's basically having a hypothesis that if you make this change, that something else won't change, hopefully, you can break this thing and nobody will notice is the general idea of this. So setting that up is something that we can sort of gather together. Are there any kind of like end users on the call like Bloomberg, Miko, for example, like is this kind of, or Nora, like is this something that's just like ingrained in the company that you just kind of do this on a, you know, active basis? Hey Chris, this is Uma from OpenEBS. Good to meet you. So, yes, at OpenEBS, chaos engineering kind of, you know, the core theme. And we started a project called Latmos. The idea also is, you know, to integrate the end-to-stage workflow in as part of the chaos engineering. We're at the beginning and this is a good start, I guess. You know, you summarized it and we are planning to contribute as much as possible from the stateful workloads perspective. But I'll take a look at it and see, you know, overall how to put things together and I'll be happy to volunteer a little bit more on defining a landscape from others. Yeah? Okay. Thank you for... Hey, this is Nora here. It's pretty ingrained in the Netflix culture at this point. You know, people do expect that things will fail. However, that's not to say that, like we have new chaos tools that we're building and trying to implement all the time. And those all require a new degree of like internal evangelism, internal adoption and in certain ways. So like chaos monkey right now is turned on by default, right? Some people don't even know that they have that enabled on their service, but you know, a new tool we have is an opt-in model right now. And hopefully eventually we will evolve it to an opt-out model, but all of our chaos tools operate under the assumption. If I run this experiment or if I run this chaos test, I expect I will be resilient to it. If we know ahead of time that, you know, this will cause customer pain or it is gonna cause some sort of pain, there's a definitely a different process there. Okay, cool. Thank you. I think there's two layers to this that might be worth separating out this. I think with Kubernetes, the particularly interesting thing is that there are APIs which you can use to manipulate applications. So at one level, what you're trying to do is say, I want my application to be resilient to various types of chaos. And those are mostly hitting the Kubernetes APIs or maybe container APIs or network APIs to disrupt certain things within the application itself. So that's one area that is particularly interesting. And it's interesting for me because it's a much more portable way of doing this rather than customizing this for every customer and every place and every vendor, every provider. We get something that's portable and that helps commoditize the patterns better. The other layer is Kubernetes itself. And we want to be able to do chaos at the, to the control plane, to the nodes and say we have a multi-zone and eventually there's federation and multi-region. We need chaos engineering to basically attack Kubernetes itself to prove that this is, see what the platform does under certain types of failure mode. And it's really got nothing to do with the application level at that point. You want to make sure the application keeps running. But I think those are two different layers and maybe we're separating those out into different, sort of different work streams or something like that within the group. Yeah, definitely. Any other comments before I come in on? I just had a quick question. You talked about gathering kind of like the landscape and then eventually moving towards an API. I think you, I mean, I talked about briefly, briefly about like sort of the first step of that though being sort of solidifying a definition like a universal definition. Yep. So kind of, okay, cool. Yeah, so that would be part of the white paper. And so for me, like I'll be upfront, like I am new to this community. So I don't have a lot of understanding of kind of, I know Netflix was kind of a original steward of what is like the chaos principles or something. But like I want to make sure that like whatever we do has input from everyone and we kind of have a, we put forward something that doesn't kind of cause any political issues if I'll be blunt, like I just don't understand the community well. So I'm good at kind of gathering folks and doing things in a neutral way, but that kind of don't understand the history of the actual chaos. Totally. My engineering community. Totally, yeah. I just wanted to make sure that there was, there was going to be an effort to sort of, I guess, I don't know, I just see solidifying a general sort of definition to be sort of the first direction. Yeah, I mean, it'll be part of the white paper, essentially. And like, you know, we could say, hey, here's what we've done based on our research within the community. Here's the opinion of the working group of, you know, the different values and what chaos engineering is. And my whole thing is I would definitely make sure that we have end users reflected within the group, not just only vendors. So that's kind of a key tenant of CNCF. Any other thoughts? Otherwise, you know, I'll kind of go into the logistics of, you know, how we're going to move forward. So, you know, very simply, I prefer to do most of our work stream stuff just on GitHub and through Google Docs. This is kind of how it works well for other working groups within CNCF. You know, I am fine kind of leading all these specific things and kind of organizing, but if you're interested in, you know, helping with the white paper, please ping the GitHub issue and we'll kind of start moving from there. If you're interested in kind of providing input to the landscape, please ping yourself on the GitHub issue and we'll basically start collecting all this information via Google Docs and kind of build this out and kind of over time, you know, present kind of new ideas and what we find to the working group every time we meet. The kind of structure of how we do these things within CNCF is generally we'd like to meet regularly every two weeks. The way we kind of structure a meeting is, yeah, we have a brief agenda. We always like to have demos from the community. So personally, for me, like I would love to see a demo of some of the work from, you know, PowerSeal, you know, Gremlin and the OpenABS folks, Castlekit, maybe what Netflix is doing from Nora. So I'd love to kind of find volunteers to kind of showcase what they're doing because that's kind of how we'll learn from each other and then just kind of updates on where we are with landscape definitions and so on, which you can see how it will help with. So for me, coming up with a time is painful. I don't know what works best. I know since we have folks that you're involved, we generally have to do something early on the Pacific time. So generally eight or nine a.m. I don't know if there's any strong feelings of whether we just keep this time and kind of roll with it or just do another doodle poll and kind of see where we end up. I know I have some folks from China that want to participate from Ali Cloud, but you know, it's hard to please everyone when it comes to timing. So any thoughts on particular meeting times or I'm just gonna throw out another doodle poll and kind of see where it lands? 8 a.m. Pacific time sounds good, Chris, but I'm sure those are going to join from Bangalore. So that's perfect in the evening. Okay. Oh, we have Indiana mix too. So, okay. Yeah. Yeah, that definitely works for me. Yeah, 8 a.m. would be great. Okay. It can make it work. 8 a.m. would be great. All right. So okay, I'll throw out a doodle poll for 8 a.m. on specific days that try not to conflict with any other scenes. You have specific things and we'll just kind of land and pick a day and do it every two weeks. So some other kind of small tidbits, you know, so yes, I'm looking for volunteers for demo. So if you're interested in demoing in our meeting in the next two weeks, let me know. Think Sylvain's volunteered KS Toolkit, but I'd love to have find one more demo from the group. So please reach out to me after the call and then we'll kind of get you scheduled. So a couple kind of tidbits before we kind of open things up for questions and kind of ideas from the group is the folks from Glenn Gremlin have created an event called KSConf, which is great. You know, we love to kind of see, you know, events in the community kind of around specific topics. That's really how you get together. CNCF, you know, has sponsored the event and you know, basically essentially donated the money for the purposes of diversity and inclusion for scholarship. So we're super excited to support that and support the event in general. And thank you for Glenn Gremlin on putting this on. It's a bit of a challenge always to put on events. It's a huge time sink. A lot of people don't realize what a pain in the ass it is. We just put on KubeCon last week. So we're still recovering from that. So thank you again, Gremlin. We really appreciate the support. Thank you. Yeah, so hopefully we'll see a lot of folks there. So thank you again. We also have an event coming up in Seattle in December for the cloud native CNCF and Kubernetes community. I'm totally open having a chaos engineering or resiliency, you know, whatever name of it, I'm open to essentially providing a track for this community there. So if people are supportive, I'll just make it happen. So please, please let me know. If I don't hear anyone opposed, I'll just make it happen. It sounds good. Yeah, I'd be happy about that for sure. Cool. Let's do it. Awesome. All right. Let's talk about some boring governance rules. So, you know, the unique thing about CNCF, you know, compared to other open source foundations, we generally allow projects to basically define how they kind of run themselves, right? As long as it's done in a fair and transparent way. And so I just basically cargo-culted, you know, kind of what other working groups have done. So generally, you know, we represent different organizations and companies here. And, you know, I'd really like us to just operate as much as possible by rough consensus. If there is something that kind of flares up and, you know, we're not sure how to proceed and we need a vote, you know, we'll essentially employ a rule where, you know, single organizations essentially get one vote associated with a specific issue. So I added, you know, kind of this policy in the governance.markdown file in the GitHub repo. If you would like to be considered a maintainer, please send a poll request, because these are the groups of folks that we're essentially will use for voting. So please send a PR there. We'd love to kind of add you there just for kind of logistics and housekeeping reasons. Any questions on governance or thoughts here? This has generally worked pretty well for other efforts within CNCF in terms of working groups. So I'd like to just kind of keep this and then move forward. Cool. I guess not hearing any objections. So I'll take silence as a consent that this is generally okay to move forward with. Can there be more than one person from the same organization? But yeah, okay. Yeah, just, yeah. You could add yourself to maintain us all, but if it comes to a vote, that organization will only get one vote. Cool. Okay. All right. So yeah, to kind of wrap things up, you know, I'm basically going to open it up to kind of the, you know, community here on this call to see kind of what they would want to see any particular topics to discuss. I know Adrienne has kind of mentioned separating out work streams, but I'd love to kind of hear from folks what they would kind of talk about next. I would like to firm up presentations for next meetings. So I know Sylvain has volunteered KS Toolkit. Is there anyone else that kind of wants to move forward and kind of do like a, it's basically a 15 minute presentation to kind of how you're doing chaos engineering or a tool that you kind of built that you'd like to share with the community to kind of get feedback and put on just to, just for learning purposes. Chris, I should be able to demo some of the LinkedIn stuff. Okay. I'm willing to volunteer Tammy, but in her absence, I could definitely do it. Okay. All right. So we got two, that's perfect. You know, essentially we'll just, I'll add it to the Google box that lists the meeting agenda and we'll just try to get, you know, to try to do a cadence of two kind of community presentations per, you know, per meeting for kind of the purpose of sharing and learning from each other. So cool. Thank you. So other than that, like what, you know, what other folks, you know, out there kind of want to see from this effort? So like, you know, I see the concrete outputs being the landscape white paper and just like learning what people have built. You know, I'd love to kind of get feedback from folks. Otherwise, we could kind of end this call early, but you know, I'm here to basically help from a CNCF perspective, because this is just a super interesting topic for our membership and community. And we love to kind of promote the, you know, promote the practice of chaos engineering across the industry and our membership. I think there's a reference into the, whatever the testing scalability working groups. Yeah. So we should be, if we do this right, we'll be generating things that can be used to test Kubernetes and that aspect of it and how the groups relate to each other. But it simply makes some sense. Yeah, no, no, absolutely. I mean, there'll be a time when we're a little bit further along that we will formally present us to the CNCF technical board slash TOC to kind of, you know, get it approved. I'm going to try to do that over the next, next probably four to six weeks. Once we're kind of a little bit, you know, moving along and kind of, you know, have a good cadence going. And then presenting to the SIGs and, you know, relevant working group sounds, sounds like a good idea, Adrian. Any other thoughts from folks on the call? If we're gathering tests or test scenarios together, the question is, so where should they live? And, yep, to what extent, if we're building a repository of executable test cases, yep, where the user particularly, let's say if it's, you know, it's events talking about this chaos toolkit having a library of tests. Yeah. So there'll be a sub-library of those, which is something to do with Kubernetes. And the question is, where does that live and how do we reconsider or accumulate so that people can find it? Yeah. So, yeah. I mean, ideally somewhere on GitHub, right? I would start within our repo, at least referencing where things may live in different projects and so on. So, you know, there's also discussions of us making recommendations to the CNCF TOC of like, hey, maybe, I don't know, Paracel or something whatever project could come into CNCF as a kind of a sandbox thing or a recommended effort or we just create our own project that lists these things and propose it down the road. I don't know, I'm all ears here. Any other comments or thoughts? Seems to me that we could do with a lot of educational material. So that'd be brilliant if, you know, various people in this community could scum up, you know, with whatever they think is right to help others to actually get there. So I have some ideas on that in terms of, you know, kind of once we produce, you know, a paper or kind of a, you know, opinion piece from the group, the CNCF could help promote that, no problem. I also have some very fun ideas around, we kind of have these Kubernetes certification exams and I'd have kind of like a little selfish idea of adding like chaos engineering to that or like how to do it, you know, within your systems from a system administrator perspective, at least that's kind of a selfish goal of mine to push later on as kind of an education thing. And we also have courses that we've kind of partnered with organizations like edX.org. So like if we actually wanted to do like an intro to chaos engineering and have it freely available on edX.org that CNCF is more than happy to kind of sponsor that initiative. We've done that for Kubernetes, we've done that for Linux and other efforts. So that could be an idea. Hey, one thing I wanted to make clear is we talked about the APIs and specs for actually conducting the actual chaos scenario, right? So are we also going to come up with probably a structure around like what are we validating out of this resiliency? Like how am I going to put up a report out of it? Like are my alerts firing? Are my resiliency under time limits and all that? So probably some good examples around that will be helpful, I believe. Yeah, I mean, my first hunch is just to like let's just catalog things and learn from each other and see how everyone else is doing stuff before going down the approach of trying to spec things out. We have, I mean, there's quite a few presentations that I've done, there's videos of them, there are others that we've done. So how do we accumulate links to slidex and videos? Is there something we should just accumulate into the working group in one of the files? Yeah, we have a doc. So I would do it in the working group proposal doc. There's already kind of a landscape of like all the different projects out there, but I would just create a section on presentations and other things. That would be great. I'll get sent it to you, Adrienne. Yeah, I mean, I'm looking at the GitHub site. So in the draft proposal doc itself. Yeah, in the proposal doc. Take it in from there. Yeah, I would do it there. Just create a new, there's a section on resources. I could create like a sub section or, this doc needs a little bit more love in terms of organization and so on, but I'm hoping as more people go involved, they kind of have ideas on how to structure things. On the landscape side, I have a personal like, how do people like break up these different tools? Like, you know, from CNCF perspective, like there's some for me that are like Kubernetes native, there are some that maybe focus on security, like having an idea from the group of how they think about and how to break apart these different tools would be great because if you look at a, if you look at a serverless landscape, for example, we have these kinds of subsections. We have like, you know, things that are related to security tools, what we call, you know, platforms, which in this case may kind of map to like, maybe hosted chaos engineering as a service things like Gremlin and then chaos IQ and so on. So having an idea of how to like, break these things apart in different areas would be super useful for me. I don't know if people have thoughts here, I'm sure you do, but those are kind of things that I need to kind of figure out to kind of move forward on generating a landscape. And maybe we can come with agreement on a group on how to do this properly. I'm sure you have thoughts on this, Adri. Yeah, that's fine. Cool. Yeah, I'll let it, there's links and things into the, yep, into the resources there. Awesome, cool. Any other questions or thoughts, ideas? All right, if there's no other questions, I'll end it a little bit early to give us about 10 minutes back. I personally wanna thank everyone that has attended this first kind of bootstrapping meeting. Thank you to Sylvain, Tammy and other folks that have done a great job in terms of introducing me folks in this community. I think this is gonna be a super useful project for a lot of us and I kind of look forward to us, outputting a landscape, white paper and kind of bringing the practice of chaos engineering to the wider CNCF community and industry. So thank you all. And I'll send out a doodle poll to figure out when we're gonna meet next in two weeks. Okay. Thanks. Thank you. Thank you. Thank you, guys. All right, take care all. Thank you. Thank you very much. Thanks everyone. Thank you. All right, bye-bye.