 Hello, good morning We have a few regrets this morning. We'll be missing Lynn and Cornelia, but that's By and large, I expect everybody else. So give it a second. Oh Liz one housekeeping note the only sick that didn't have slides today was Contributor strategy. So if they're here, I'll maybe push them to the end. Not sure. Okay Is there a place holder for them or are we I've dropped them from the deck? But there's the place holder is if I see them, I'll flag you down. Okay If there's a placeholder, I'll see it and I will remember to check Yeah, I'll keep track. How's that? I'll just let you know maintain course and speed. What do you think? Should we give it a whirl? Let's do it. All right. Welcome everyone to today's TOC meeting All the usual preamble you've made it and I'm sure Amy will update that. So mostly we're here for sick updates and before we get into sick updates Amy, do you want to say anything about the renaming of six? It's still in voting. That is what I am saying about it. The vote is still open over in GitHub. Okay, the vote is still open fine I didn't know whether the vote where the vote was That is where that is the vote is still open. So if anybody has strong feelings about that Please go ahead and I can certainly drop that into chat in a bit in here But that's that's where we are on that Alrighty. Thank you very much So looks like first up is oh, um, there's a Question in chat that was like the the thinking around renaming of SIGs So we had a discussion on it I think it was the last public meeting if I recall correctly and the idea is to avoid Confusion with Kubernetes SIGs and Kubernetes SIGs got there first. That seems only fair for CNCF SIGs to come up with a different name and The name under proposal is technical advisory groups, I believe and There's a bit more detail and discussion in the GitHub Issue also of note. We talked a bit about the possibility of holding votes on GitHub Rather than on the mailing list and we're using this particular vote as an experiment To see how that whole process Goes and and how people like that. So I guess once that vote is closed. We should put something on the agenda to just discuss Whether we liked that format for voting And the link is up in chat so All right, so moving on to SIG app delivery Yeah, hello everyone. It almost feels in school always have to go first because you have the first letter in the alphabet So some project updates on our side. So there's a lot going on now again on the project front Our goal requested to move to graduation So this is an interesting one for us in app delivery because it's actually the first project that wants to move to Uh, graduation within SIG app delivery. There were already some commands, especially regarding CI batches from Justin I think they should be resolved now because it didn't have CI batches on all of the projects updated Um, I started to engage in the conversation obviously about other obvious things like security review and so forth um, but like as the other SIG people are here if Anybody has done or moved their project to graduation already and can give us some hints and tips. They are greatly appreciated Second project we had a presentation from gimlet.io and one chart. Um, for those of you who don't know these projects, um They call themselves a github store. We had a longer discussion about this so one chart is You could think of it more as a super powered Helm chart Depending what configuration you get in you get different things out of it from a simple Service and deployment all the way to like pretty sophisticated configuration Um, and makes it just simpler to um Not having to understand Helm and all the the market and Kubernetes markup in detail and gimleton is a graphically tool that more or less you fill out the proper values file in there Uh, interestingly how we came across them. We had from the last KubeCon this potato head project where we have like an examples for most of the delivery tools in there They posted any examples Uh, I looked at the tools that this is kind of interesting and might be helpful to what a lot of people are doing Especially as we see more people using standardized templates and then just let developers fill out What they want to fill out and the rest is handled automatically like everything obviously from deployments all the way to Open policy and so forth So, um interesting project there that gallant in their litmus Well, uh, actually tomorrow present an update and they also wanted to move to incubation The last one was just added by harry in here Noka host is looking for sandbox and they will also be presenting so noka host being a cloud native um development uh in environment More or less On the working groups, um that we have the operator working group The work is heavily underway for the operator white paper And by the next in the next two weeks we expect to see the first version So the first um bits and pieces are starting to appear right now. It's all obviously on github already. What's there? The github's working group no update uh from them so far And then on another activities that are not in here there's some organizational updates uh here so, um We have to do also some organizational work in the in the working group Obviously, we had harry move into that uc, which means that he's then obviously stepping down as The co-chair for sick app delivery Brian is stepping down as well And as we have some then also to see the assault changes coming up There is some organizational work in uh app delivery that needs to be taken care of going forward and Obviously, we will reach out to the proper people on how we can get new Especially the co-chairs in there. I think that he is he is ours um are pretty Obvious who we want to keep so all the harry offered himself over already, which is quite obvious Another one would obviously be cornelia But for co-chairs, we would have some internal candidates, but obviously need to follow the official voting and uh proposed process there to um Get new people supporting us on on network front So that's it from sick app delivery Uh, there was one question with this skinnet and one chart our one project. Um, yeah, they're one project it's um Yeah, I can that be more or less the ui to it pretty much Oh, okay. Thank you Yes, with the co-chairs Do you have like candidates? Uh, or potential candidates or are you gonna need some help? Putting out the word that co-chairs are And we should do a mixture of both. Um, obviously see the people who are kind of working especially in the operator working group being pretty active So I want to add active There is also a good chance maybe to bring some new people into the mix for those that are interested Why would especially be interested in to get people from the end user community into app delivery? At least have one end user Related seats because right now or up to now it was even mostly focused on on on vendors and especially in this group We should at least have one end user representation there Right. I also agree that um, we may want to look at Whether they are folks from end user companies want to join the sick as chairs of tls I think at least it will be great if we can help a little bit here so Um, I I'm hoping to see um, maybe At least one co-chair here to co-work with um, alloys in the future. Uh, I'm still working in Only sick after delivery things, but uh, I need to spend some time on the tlc side. So I think it's good to have a new candidate here Another thing I want to bring up is flux incubation. It's right now under voting, but it has been Taken for a while. So maybe tlc want to take a look at this project and Vote if you haven't done that before Good reminder. Thank you Anyone else got any questions for sick app delivery? Okay, thank you Let's move on to what's next Sick network. Okay Who do we have? Liz you say that Sick network your favorite sick. I heard I heard You're all my favorites all of you Very good. Well, uh, so the sick network we have Uh, I've been having a fair bit of participation over the last three or four times that we've met So it's been um, it's been pretty nice There's a lot of the activity and the participation has been On initiatives within one of the working groups the service mesh working group So we we have generally take care of some some sick network Business relatively quickly in part because we've really just had one outstanding project For a while under review and that project is well the project formally known as ambassador It's you know now known as emissary ingress And so it is proposed for incubation and it is out for public review. I think as of A day or two ago or here very recently. So That's a call for all of you on the phone And not on the phone to go Show your support or or lack thereof for Emissary ingress please go out and Please go out and vote for ambassador. I guess is what I'm saying get out and vote All right, so that that's um sick network. I apologize. I didn't mean to make confusion there Of a lot of the activities that have been going on in sick network have been in the service mesh working group There are four or five initiatives within that group So just as a quick recap about I think it was Three weeks or so ago the group went through a review of service mesh patterns There's about 60 of them that have been described about the functionality of service meshes and um, how How people can take what what the patterns are for using those those Functions there was a demonstration of the open application model and meshery Demonstrating some of a couple of those patterns the The following week we ended up doing a review of get nighthawk Nighthawk the low generator for that's under the envoy project Some exciting new features coming to that project And get nighthawk is an attempt to Well get nighthawk into people's hands to more easily this last time that we Yeah, I may be getting confused on the which which the sequence was here, but um this upcoming time that we'll meet will be on um service mesh performance s and p and really probably um a push to Propose it for sandbox. I think that's been an outstanding item for a while. There's a couple of um Fine folks from from intel who've been I'm helping advance the discussion on s and p and are showing support there And and I think we'll be encouraged to Do even more do even more with that specification as it heads toward sandbox Other items that we discussed inside the service mesh working group are Well from the smi team or smi maintainers there's been an ask for Uh, there's been an ask for some assistance on Feedback, I think both on service the use of service meshes So a little bit of a call and ask of the sig to either collaborate on if there's an upcoming rate and use a radar on service mesh to either collaborate there or to Have tried to facilitate a different another survey a more in-depth survey focused on on service mesh things That smi the the maintainers group is Looking for feedback on where to where to focus There's been a recent proposal for them to focus on multi cluster On today if you're familiar with smi it covers four different has four different specifications covering Different functionality that you can use a service mesh for Um, and that is yet to cover multi cluster things. So But that's uh, that's about it. I think we're lining up a A deep dive for um, cube connie you That is going to be one interesting end user radar Excellent uh SMI should fill in this is from josh in the chat SMI should fill in all of the required single cluster functionality before moving on to multi cluster, but i'm not working on it So that's really up to them Do you want to comment on the parallelism or serialization of that? I think that um generically that's an agreeable statement like or that makes you know a lot intuitive sense to me that you would I the the group or knowing a little bit of the background here the group is I think responding to um Asks from people who are showing up to the meeting saying Um, hey this I think there was one user in particular. It showed up and said Istio is refactoring how it's approaching some of the way that it does multi cluster And that approach doesn't necessarily work for that that particular user the way that they've deployed kubernetes The way that they manage namespaces that had to do with the fact that they're reusing the same namespace across multiple clusters And Istio's multi cluster was expecting that namespaces are globally unique. And so anyway, I think that the group to respond to A well-placed comment from josh is I think the group is more or less responding to People that are showing up and asking questions about multi cluster support But it's a good it's a good point like There's a there's a number of other Specs to enhance specs around, you know, I won't I won't go through the specs There's a lot of specs to enhance that new ones to create as well For single cluster All right, any other questions before we move on? Thank you, Lee All right SIG observability Here do we have Give some big status on the SIG observability. So I will try to be quick. Um, the main focus right now is The collaboration with open telemetry on the incubation proposal that was proposed a couple weeks ago We have huge amount of good discussions on on technical levels adoptions and so on And the project is such such large that Yeah, it takes some time But I would like to invite everyone as well to Join us comment on the on the document we are Creating and and kind of give your opinion and also some suggestions for You know, how to make open telemetry better. So Kind of this is our main focus right now We also work on some white paper for observability. I forgot to add that to the slides, sorry And kind of related to this incubation I would have an open question to to the tuc and maybe you know to community here Is that um open telemetry is very unique project, right? Um, we usually had You know all our project that moves from sandbox moves to sandbox first and then to incubation and graduation being somewhat ready and ready in terms of all the core Components all the core You know goals of the project well were the where the find adopted fulfilled So we could it was easy to assess this right Right now open telemetry is very unique on this field because tracing is very well adopted very well You know constructed the api solid and you know very much used in cloud native Solutions, but other other signals like metrics and logics logging are kind of starting up and you know getting this motion but Not getting there yet. It's not like stable and adopted and very well aware So I wonder, you know, if it's a requirement for incubation or maybe only for graduation So this is like an open question. We we kind of the main question right now have I guess So we would love feedback on that, but maybe before this let me give Yeah, the upcoming agenda items or something in the future. We want to focus on There is white paper on tracing site for the very beginners level Kind of guide how to start with with an open telemetry and other tracing projects And we are talking about streaming apis and how to observe those So, um, yeah, that's the status from the observability side I feel like we um Sorry, I feel like we should probably try to um At least touch a bit more on this um on this question of hard requirements for um incubation, I mean Yeah, incubation is supposed to be a high bar. It's supposed to be you know The the the point where we do the majority of due diligence Sorry for bringing that up to now. I think Richie asked me also to say that He was supposed to send some email about this, but he forgot Um, so yeah, let's let's discuss this. I feel it's very It's very fuzzy. Um at this point And there might be some suggestions for you know, there might be some recommendation we can make I know open telemetry really want to be consistent across multiple signals So they don't want to incubate like one project one part of the project and others Maybe later. So, uh, yeah, there was this question around incubation here I guess my I mean, this is just me and my sort of gut feel, you know To get to incubation. We have to feel that the project is pretty You know pretty strongly de-risk them pretty, you know on its On its path to graduation and I wonder whether If if there are some parts here that are really still experimental Yeah, I'm I'm not sure what service we're We're providing to end users to move it to incubation Yeah, I'm having to provide a little bit of context So there there's two different aspects open telemetry. One is like the core components So think like instrumentation libraries that you add to your application And the second is a collector component. So think like an agent you deploy that collects and processes data So those core concepts exist in open telemetry today and are leveraged pretty extensively The the the part is on top of that are the data signals. So think like traces metrics and logs So tracing actually reach stability in open telemetry and is being rolled out across the instrumentation libraries right now Metrics are in beta and will reach stability later on this year and logs are alpha They're experimental at this point with the goal being to provide those probably by by next year There there's a lot of adoption on the tracing side already from the instrumentation library perspective and on the collector side There's adoption for both traces and metrics But the the project is actually quite large like it's not a single focused or single component or single repository project It's it's pretty disperse Thus kind of the question around the different signals and to be fair These are not the only three signals more are going to be added to open telemetry over time So the project will kind of expand and scope, but this is kind of the the initial focus for for the project So maybe one way to think about this is a little bit like how new features get added to You know existing very mature projects, you know, we take kubernetes as an example and You know, there are alpha features. There are beta features. That's totally acceptable in a graduated project I suppose there might be questions about how those are signal to users whether the you know, if um I mean, I'm a very hypothetical example suppose that the logging part actually never stabilized and and you know Turned out to be an experiment that failed. I'm not saying it. Well, I'm just posing that as a hypothesis That doesn't necessarily mean that the whole, you know Open telemetry can still be successful regardless In much the same way that kubernetes is successful despite the fact that some alpha features end up getting deprecated, you know, that's That's okay. So I guess maybe some of this is around the The signaling and the pathways that the project takes for these different Maturity I'm kind of thinking out loud that the different sub projects could have different Maturity And we're thinking about it similarly, right? So some ver is followed for the different signals themselves So kind of a similar model to kubernetes. And yes, additional things will be added So you have to be able to mark like what you can depend on versus what will have breaking changes, for example So that's the approach that the project's taking currently okay, so for biotech and the SIG observability people does that kind of And and does anybody think this is wildly off the mark to say that it's, you know, not every single thing in a project has to be You know wildly adopted and widely adopted For the project to potentially be ready for incubation And does anybody think that's a terrible idea and a terrible analogy Yeah, I think makes sense Just just from my side, I think, you know, product doesn't need to be perfect. That's for sure. There are experimental things However, my perception was and and you know, maybe I'm wrong is that, you know, that the signals Observability signals are kind of, you know, have equal importance. Let's say so if logging and metrics are not yet well Not yet defined This is like two-thirds of the project being not defined And maybe it's just my perception that has to be changed So that's why this analogy to communities might not work Yeah, that's that's my only problem that Yeah, I I believe our requirement for a project moving from sandbox to Incubation one of our major requirements is that they have to have three users With it being implied that those are production users So And and I think I think this is a good example of why that's still a good benchmark um Because You know is too much undefined is enough to find or whatever Honestly, the users can decide that right if people if there is enough there For people to be using this in their own enterprises, then it's not too much that's undefined If there isn't then it is Yeah, and I just shared an adopters link. There are definitely end users that are adopting it in production today Just the thought of this because we've come across similar sort of circumstances in in sick storage I think we probably need to differentiate between um subcomponents or standalone bits of a project versus Integral bits of a project right because you know if we use Kubernetes as the analogy um having Some function or some feature which is Alpha or beta is one thing having an entire sub project That may or may not be usable or production worthy is probably another also because Some of those things if they're not actually defined may also have Dependencies on other things or IP policy issues or all sorts of other things because they just haven't been ironed out yet um So I would probably caution about about you know if a project has a dozen repos You probably want to actually specify which repos or which components are specifically joining as a cncf project uh Everything in the organization is a cncf project and the IP policy applies to everything that's moved that's inside the repo regardless of what status is in there's no There's no bits of this auger in or out of the project Right, okay Yeah, I think this is something like we we ran across this problem also in sick app delivery When we for example the our gross admission, which was a pretty massive suite of different sub projects that were in a different state And just just recently with the current flux of mission with which area brought up right now Where they're currently in between a full version one two two version two while I'm wanting to move in this case to incubation I think we will see this high velocity in projects more and more um And maybe the criteria need to be Adjusted here or how we communicate about projects Exactly for open telemetry from from somebody actively working with the tracing part Even if the rest never materializing the project in itself has value and has has adoption. Well, actually the the metrics part I know it's also adopted by um very big or end user organizations already Just the logging part is not there So I think we have some that that's also why we have like tech leads and the do you see this as technically risk of things not actually turning out The other risk is that we won't find people and the other is organizational risk. Nobody actually working on it Well Logs do not exist. I think how to write a logging signal library Excuse me. I repeat because not like really rocket science. Yeah, this has been done before It's not just standardized there and it might take longer from an organizational point To find people to actually work on it and to have like Did the overall agreement? I think that a lot of this is really in the assessment. It's a bit of a gray zone And we will just see this higher velocity like for our goals Like the key parts of the projects are already mature enough for flux. They have a very good Plan to move from version one to version two. There's a lot of industry momentum in there People are already already moving there. I think there is no hard criteria And I think the standard project criteria do not really help that much here And like technically vision and technically stability of the ideas behind it is not really even a criteria for the project Maybe that's something to add in the at least have a statement of assessment by whoever's reviewing it I think we should probably um move on because we'll we'll run out of time for the other six But um, I hope I think that was a useful discussion and I hope that's sort of set some thinking in place for SIG observability folks. Yeah, definitely. Thank you. Great SIG runtime Hey, hello everyone well Okay, so We've been having presentations We had a couple of presentations last month um So some updates on some of the projects that I had mentioned on the previous meeting So we had On the containers and runtime space sysbox is a project that allows you to run uh containers Uh in bm or or they containers that look like bm's so It allows you to run full workloads that Would run in the ends with system d and you can even run the Kubernetes clusters inside the container So pretty interesting project. They had a presentation early last month So another project that presented is trout and that's container image registry In the difference with some of the other registries That are around is that this one is written in rust so they're targeting use cases that are looking for kind of faster lighter weight image registry maybe people running container registries in Kubernetes clusters So Yeah, they presented at our last meeting and It's still on the works and this is from the folks in from container solutions So Another project. So there's a few projects on the web assembly runtime space We are going to have another presentation for ssdm This is from back by a company from the name is second state So Yes, we have some of the virtual machines. So pretty excited to have them presenting our second meeting on thursday Another project that we reached out to is wavm They reply to our invitation and they're also looking at presenting another Runtime or web assembly runtime in and I think the focus is on having high performance workloads Other web assembly runtimes we have wasmer swam Was in time some of them we reached out Wasn't time hasn't replied yet. So hopefully, you know, we get that to present at some point In the operating system space in The Meeting next this month or the not the one Thursday, but the one after that we have a rast CTL It's a project from the folks at facebook and this is a project that allows you to Um Manage the resources on a system based on metrics So things like number of requests or latency on some of the Requests that are servers actually receiving and and adjusting that dynamically and this project is also written in rust So another just in project presenting And then finally on the iot and edge space. We're still talking to k3s. They're already a cscf project So we'll have them present at some point in the future And as far as other sick runtime activities our container orchestrated device work group They've had some meetings and they they are working on container device implementation in and in beta and They're going to have that with pot man And and they're also working on the same but integrating that that implementation with kubernetes So some progress there on the work group and and And I had a meeting we had a meeting with our new toc liaison. So So alina Is one of them and then so our new toc liaison is ricardo rosa. So the other ricardo and Yeah, so we had a conversation about, you know, some of the projects that we're working on and We're reaching out to and and and some ideas of how to Help get more engagement With the sig and with the cncf And some related events. So we're going to have a qcon eu session and There's three events that are Not per se directly related to sig runtime, but you know, there's some relation With some of the projects for example kubernetes On the edge date there's cloud data wasm date and and there's also cloud data rusty Uh Yeah, that's that's all the updates that I have for sig runtime and happy to take any questions. See if you have any Oh sick ricardo. Yeah Yeah It's like double ricardo, right? I think there's something very interesting about the fact that there are all these You know, uh, co-located events these side events for cube con going on in the runtime area. It seems like a really Rich seamen activity All right, cool it's pretty exciting and yeah, hopefully that that actually helps the sig and The ecosystem grow and and taking forward Any other questions for ricardo? Okay, let's move on Sig security Um, some quick updates for you all today We have the secure supply chain working group issue number 510 They are rapidly moving forward with a supply chain security white paper. It's been scoped We have a documented schedule and we're looking for a final release of that paper before cube con So keep an eye out for a call for community review We'll be sending that out to our sig uh list as well as probably the cncf list We were successfully able to merge the translation of the cloud need of security white paper into chinese This is a really awesome thing for the community We also now have apac region bi-weekly meetings. It's been going extremely well We're seeing a significant amount of growth from that community as well as an increase in the amount of contributions as a result of those meetings We're also going to be starting a serverless security Um, research white paper. So see a call to action coming out about that soon We're going to start work on the cloud native security map. So this is a interactive edition of the cloud native security white paper Um, we're going to also be sending out a call to action for that requesting both content and development opportunities from the community to contribute to this really awesome effort But the biggest update of all is that we have updated our process based off of the past five security assessments that have been performed and the feedback from the projects that underwent those Assessments, we're now calling them security reviews to avoid a lot of the community confusion that community experienced going through this But we've also made some changes to the overall process to better align with the maturity level of projects moving through the cncf ecosystem So we've got some big updates there lots of changes Please check out the changes in our repo under the assessments read me and we also have a current proposal To more formally align these new changes with the cncf phases and that's under pr 5 34 That's everything Thank you. Emily any questions from anyone? All right six storage Good morning. Um, so We had the discussion last time That we were that we needed to kind of spec out the the sake We had been looking for some new tech leads For the for the sake for a while We'd like to nominate two tech leads one is raffaele spazoli Who works with red hats and has a lot of Has a lot of background in kubernetes, of course and storage and has Recently being authoring a cloud native dr document in the sig and also We'd like to nominate sheng yang who's An engineering manager with with susie formerly rancher And he's also the the maintainer one of the maintainers for the For the longhorn project Again has a lot of background in in storage Is a really strong technical lead and has been involved in the sig for Probably a couple of years on a season since we first started So so we'd like to nominate these these two people for tech leads. I'm Going to follow up with an email to the to see mailiness or perhaps um, I don't know if this should be another one of those that goes into A github issue for voting, but I'll I'll take your lead on that and um, is the co-chair of the Storage sig I second the nomination. I think they're both great candidates and contribute a lot To the community. So I fully support it Thanks, Erin wonderful Hopefully get that closed off for you. Yeah, and about very quickly That would be brilliant. Thank you so much Um, we have another slide with a few more updates So the the longhorn project, um, we really need to kick off the dd process. Um, I Need to follow up with um, with sad on that Chabo fs are currently in sandbox. They are proposing to um to move to incubation They presented to the sig Just last week where we're getting together to to review a few of the items And we should be able to make a recommendation shortly an open ebs is Still another discussion. Um, but we haven't we haven't moved forward that One of the main topics that we're working on is a Is a disaster recovery a cloud native disaster recovery document which as I mentioned rafael I was working on Is he's also produced an overview presentation which kind of helps with the with the documents we're covering Lots of lots of Areas including, you know some really sort of technically Hard stuff like, you know, different consensus algorithms, but also, you know, different ways of deploying databases across forward for disaster recovery and Covering some of the cloud database as well as some of the legacy ways of doing them To to to provide that overview. So so hopefully this will be something that will be really useful for for Sort of end users going forward The project vineyards Presented to the SIG they plan to submit to the sandbox. I imagine it will be on the march 23rd session So that should be coming up for for a vote And finally the performance and benchmarking white paper has has stalled for the last few weeks because we've been busy on a bunch of other stuff But but hopefully we'll get that finalized before And published before keep going That's me great Any questions for Alex and SIG storage? Okay I have one other little thing from a couple of weeks ago. I said I would draft a proposed wording for adding the requirement for having some sort of documented security process At incubation level and I'm just going to stick the link to that into the chat in case anyone has any comments This is the right one so Take that at your leisure Any other questions or any other business? Oh, did we have anybody from a contributor experience? We did but I don't believe they've got anything Do you want to say hello or no no need? I think the only other thing to bring up is the uh michelle seed is coming up for Availability so the tsc is going to select a new person to replace her I think we've we've got some nominations and the qualification process is underway, right? Yep. Yep should be a couple weeks. So just give people heads up Terrific. All right, unless anyone has any late breaking thoughts or comments We'll call it a day Thank you very much everyone Thank you You