 Howdy folks, we'll get started at five after about four minutes. Please add your name and any top agenda topic to the meeting notes, which is posted in the zoom chat, as well as in the CNCF Slack. Hey folks, and I've joined just joined world get started in about two minutes at five after. All right. It's five after posted the meeting notes again and the zoom chat. Please add your name and any agenda topic that you'd like to discuss. Right now it's kind of blank unless we get into the poor quest which is fine. We've been trying to leave it open to have some more discussions on use cases or anything. There's another topic that someone had. So is there any walk in topics before we jump into any pull request or anything else. Can I ask a question maybe about the agenda. It looks like we've really covered all the, all the bureaucratic issues with voting and everything. I kind of wanted wanted to leave the agenda open to finish all that stuff so we can dig deeper. What does everybody think. Yeah, good. I guess question comment out so we put most of those administrative governance items towards the end. A lot of them are the recurring so that we could have more time to dive in immediately to talk about use cases and other things. And then we can cover those if the governance items that are currently open towards the end. That's how we put it in here, because they were taking up so much time ever every time. And some of them needed a lot more discussion so rather than rush them we were allowing them to be at the end, but those are there. And if we don't have anything else discussed then we can get into this. Okay, I think I'm not quite ready today but I will try for next week maybe to create an agenda item that can move us forward a bit on the networking orchestration front. Sounds good. Yeah, and if there's any specific part of that that can be talked about. If you're not ready with a whole lot of the pieces then we can focus on one particular area I know when we had our call breaking it down there was a lot of different topics that could be discussed. So I was actually kind of hoping we, I mean we don't have to specifically get into the nuts and bolts of orchestration itself but like, I'd like to. I think after this call to not be about bureaucracy if possible. I'd like to discuss books use case. He's not on yet though so maybe we do that one second. Personally I think he's got multiple use cases wrapped up into his first PR. I think he's just as a group on like maybe we spawn other use cases out of it. There's the concept of like, you know, immutable infrastructure in life cycle management of infrastructure which I think is the core of his use case, and then like what we think that means from the CNF standpoint. But then he's got things around testing in there, he's got some DevOps stuff in there about like what does it mean between the different actors we identified at the beginning. There's a lot of connection to that. I see a loax on here. We've got towel, Nikolai some other like network savvy people I'd like to talk about that discussion, and maybe this kind of would lead into what your follow up agenda item is next week towel around external network orchestration. Like just reading through the comments, some of my comments and stuff like there is a lot of assumptions that I think all of us make, and I don't think we tend to make the same assumptions all the time. Unlike what an existing network is, you know, do I require an L2 domain for something like, there's just all these things where I feel like it'd be loud talk to some of the points in there. And that way we can kind of in our minds collectively kind of engage and I know people agree with that or not like that course of action but I think it would be useful. So I added a link in the chat to that, do that discussion, because I imagine not everybody was following it so there's a lot there. Yeah, I'm kind of off the cuff here but yeah if Jeff if you want to present it in some way that we can discuss it I think that could be good. Yeah, and I think it's going to be a multiple discussion topic. So first, Bill Taylor before I hijack things is there anything you guys want to, you know, touch first before we dive down this rabbit hole. I'm happy to go on to whatever everyone's wanting to discuss. I agree with you on on having a smaller focus on the governance items. So we have those at the end if we get to them great and if we don't today then that's okay. Okay, so yeah for general context, a look put up in this kind of you know this potential use case for Kubernetes extent external network orchestration goes into some specifics on like some of the things that he's looking for there's talks about how we attach network interfaces. And Gear Gay goes into some of the encapsulation techniques we start talking about dynamic network management. Just to start though, I want to just pose a question is, should Kate be orchestrating networks external to itself. And I'm not like putting an opinion here I just want us to think about this right because we start talking about network attachments. In fact, I think you're the one who covers that somewhere down here in the comments. So if there's the overlay networking case that we all know we all know that we have to deal with a single interface with pods, we know that we have to deal with, you know, natting out of now taking on the source IP of the host that's you know hosting the pods, there's like all these quirks right. And then there's this concept of like the network that sits outside of that overlay that we're attaching to, can I attach to multiple networks. And the first question I'd like to like propose and maybe there's multiple answers is like, what is the thought on like, should Kate's be continuing to take on more and more and more, we think, you know, this is kind of in my mind similar to like cube Burt, where I want to reiterate like life cycle management of VMs. What are people's thoughts on my case itself, you know, building networks external to the overlay network or potentially doing something where like you peer with the underlay, like some type of like bird implementation or something, and blur the lines of what that overlay network and the underlying network look like to begin with. Book is picking short. I came with a little bit delay. That's actually very interesting topic and I feel it's something we need to explore but on the other side it reminds me actually on on the two attempts in the similar direction that are attempted to be done on the CNI level so we have a tungsten fabric or this Juniper's CNI and we have a Cisco ACI CNI which actually take a role of something that speaks to an SDN layer and then in a way orchestrating the network. But here I think, Jeffrey, you are talking about capability outside of the CNI or did I get it right or wrong? No, I mean, you're definitely on the right track. Like, same thing with like, you know, the neutron plugins and stuff, right? Like I can get like this really, you know, nifty coupling between whatever my SDN abstraction is. But my question, you know, then like you said, I'm just playing devil's advocate posing questions to kind of what the group thinks is like, if I want to run bare metal, you know, what does that look like? And so I start looking for southbound adapters into like my top of rec switches to dynamically provision these networks. I mean, I'm just kind of curious like where people think the line is for what Kate shouldn't shouldn't be doing when it comes to network orchestration. So maybe that I'll try maybe to break down the three aspects. Well, I'll limit it to two not to take too much time but try and understand what is external really I think that's one of those assumptions Jeffrey that you mentioned that people make. What is external and what is internal to the CNF right where where is that line drawn exactly. A lot of times you know to deploy something you do need to configure for example a data center switch like a top of the rack switch that's sitting there. So is that really external or you can think of it as a shared resource. The other thing you know, Jeffrey are talking about should Kubernetes orchestrate it well. What is Kubernetes here right because if we're talking about the workload running on Kubernetes right if you're running say in a Kubernetes operator, or some kind of controller or something else that will say talk to the switch or talk to an SDN controller, or, you know, talk to a network and talk to a network orchestration switch sitting inside the hardware right. Are those really external. And, you know which parts of Kubernetes will really do that so. I think rather than talking about should a Kubernetes do that we should say should the network function do that what is the scope of the network function where do we draw the line and say, This is something external to it. I think Kubernetes role in this is very is very clear and specific it farms it out to CNI and doesn't as long as you give it an IP address it doesn't really care what you do. And there are mechanisms in place that we can, that we can control or modify the pod, but in general it Kubernetes is very unopinionated about this particular space. Okay, but here's here's where it gets complicated because the CNI plug in you can say okay that's out of my domain it just runs. But what if your workload needs to interact with that plug in right if that plug in is is what we sometimes call a thick plug in. That is it's a service that's actually running and doing things. You, your workload might have to have something to do with that configuration and I extended that in the discussion to talk about infrastructure in general right because sometimes you might even need to configure the host machine the bare metal itself. But yeah, I think something to say about the configuration and doing the configuration or two very different things. Right, having something to say and you know that in so much is that the CNF exposes some requirement northbound is very different than the CNF doing the work itself. Yeah, and that's what I was saying from an orchestrator it's clear that the or that something has to orchestrate this is in this scenario. Should that be Kubernetes I don't think it should be but it should interact with Kubernetes and in a clear way is what I'm trying to say. But saying Kubernetes itself as the as the orchestrator, should it be the thing. There, there needs to be something that does orchestrated but it probably should not be Kubernetes itself because Kubernetes is very unopened about about this kind of work. It's probably not Kubernetes itself but you have a workload running in Kubernetes right. I don't think you want the CNF itself doing it either because the goal should be to only have one thing actually making configuration changes on those on those switches for example. Right. And if you allow the CNF to make changes in the switch and you have a northbound orchestrator making changes in the switch because of physical changes in the topology of the network. You don't have too many actors making changes to the same resource. Right the goal should be to have one actor making changes to a resource, not multiples. Absolutely right. Yeah, that's, that's very similar to to what I had posted before in the X, in the X Factor CNF stuff which is that the CNF is not the one making those decisions but instead is orchestrated. And what it has to do in that framework is, it has to provide metadata, such as what is my payload like payload to be Ethernet IP VXLan or something else. And what is my mechanism to actually communicate with the outside world where the mechanism could be kernel interface VFIO Memif something else. And so what do you do is you provide enough information to the orchestrator so you so it understands it says oh I need to wire you up. It helps it helps with like you don't want to pair up an IP with an Ethernet as an example because then there's a mismatch. You don't want to pair up VFIO user plane with a Memif or sorry VFIO client with a Memif server or receiver, because then you know it's not going to work so it gives you that the orchestrator the thing that's actually doing the orchestration whether it's an STN or something else, the capability to, to check across all of these particular paths. So they're clear there it's clear that there's a need for a straighter here. The CNF probably should not be that thing itself, but it certainly needs to interact with it. Unless it's a purpose built CNF that's job is orchestration. Yeah, I can buy that. Yeah, and that we call it. I'd like to. So, so to say, so, well, it depends though a look right like, yeah, that's one of the things I think we're like I don't so a couple of things for one operators that's an implementation to get functionality right. So, I'd like, I'd like us to first continue to like identify our challenges here right like I would propose, and I'm actually going to stitch in Vokes use case here right books use case is the concept of operational life cycle management of the infrastructure right when we, we always get right into like the low level plumbing of like, how am I, you know, getting these two pods to talk to each other isn't MF is you know there's some kind of kernel interface involved this and that but you know I would just pose that if you're dealing with like cloud native infrastructure in addition to cloud native workloads then the assumption is, is, and actually let me bring that up real quick to is this concept of, you know, the infrastructure itself has a say in this. So, from my perspective, am I, am I. Yeah, right. No, I just say this was so like the final point on this right is if I have some type of, you know, pipeline that's involved for like, building out these this infrastructure right like, I'm using things like node labels I'm using, you know, specialty compute for where it makes sense. Because, do I put an FPGA and every single like computer node, I don't know maybe the cost eventually gets to that point, or do I use, you know, concepts like availability zones, labels tags, etc. So I mean, I said, we always come in with these assumptions and I would, you know, propose like I like tells, you know, comment that it's a shared network potentially or whatever because like, a lot of times this infrastructure already exists and like, I can tell you from personal experience that some of the challenges I have is okay we're going to bring Kate's in and now Kate wants to control the world versus, you know, Kate's providing an interface for managing containers pods, etc. You know what would the CNF interface look like, like with the assumption that I'm not just handing over all of my infrastructure because I would say that if we just like hand control to the CNF or case itself and at that point I'm building an appliance, which then we could argue and debate and maybe write a best, you know, practice that saying an appliance based approach is the right approach. I don't know, but like the moment you just start handing everything over and pulling control as Jane was talking about from like, these other domain controllers that are specific to infrastructure that are in doing it, we start either having a multiple master scenario where things get lost we have state drift, or we start building purpose built appliances and, you know, those are the types of things I think we should be considering when we start like talking about how we would tackle this use case that you put into discussions. And for some use cases that purpose built appliance may be the right solution but that doesn't necessarily mean it's the right solution for every use case. Yeah, and I think the framework that we should aim for from best practices is something that should be flexible in that respect. And it acknowledges, ideally would acknowledge a Kubernetes is very good at a very specific thing which is it's good at orchestrating where pods should should run. It's good at monitoring them restarting them canary upgrades and so on which provide a tremendous amount of functionality. But it's, it has some some gaps that need to be covered and the reality of the situation is that if you look at the size, like, when we look at telecom. We're a big group, we're big organizations with with some money behind us. But when you compare it to the long tail of Kubernetes, where we're a small fish in the pond, and they're not going to want to complicate Kubernetes to cover our use cases when the common Kubernetes is a small to medium size cluster with very simple patterns. And so we need to be able to be careful there, we have room to play. But we need to have we need to make sure that we are not over complicating the enterprise side while we do this because otherwise we'll get a tremendous quantity of pushback and not get through the things that we that we need when when there is a gap that we just need to to resolve so we want to be careful on what type of things that we we bubble up as as as that process which the mindset that we take into this will will matter a lot. Another way to add on to that Frederick is if we can break down use cases and find areas that are most aligned with the path that Kubernetes is already on the next more likely those will be adopted. And if we can get momentum with that then you're going to have more people from the different communities, looking and understanding what's going on and then I think we can get more adoption across on other things. I mean, there is, as you know, Frederick there's, there's a lot of activity on the networking side itself, but it's not a easy fix to try to solve for all of the community. And here's a here's a question. If, if I were to implement some form of controller or orchestrator that interacts with a CNF and or rather interacts with that with some data plane, something that sits on the data plane. So this thing, let's say it's a database. So very often we have OBS TV or similar but at the end of the day I would argue that those are applications which are applications in in Kubernetes so there's, there's not a huge difference between something like OBS TV versus something like Postgres went from the concept of Kubernetes itself, and that there's no special types of network links you need to put in that that you cannot handle today as part of its as part of its path. And so there's, I think we also need to, to highlight some of the best practices around that space is like, when is something just an application. It may be part of a CNF, or it may be part of a, it may be composed with with things attached to data plane, but at the same time, is there is or anything missing is there anything special that these type of things need and I suspect that there's not anything special that we have what we need today. And then that allows us to scope down the changes to say hey, we're here's best practice on how like if you're deploying OBS TV. Here's best practices to make sure that it's high availability within Kubernetes, like that's valuable. But then when you start looking at things like how do we actually touch the data plane and do bump in the wire firewall or set up a G packet core or similar, then what are the best practices when you start to get patterns that look like that for things that actually have to touch the data plane to ensure that you're extracting the benefits of installing on Kubernetes. If if you're if you're going to head down that particular path. So I think that there's a, I think there's a line that we need to look at. And sometimes it's okay to say hey look best practices within Kubernetes work just fine we're not doing extra we have to really push here but here's a here's a gap, or, or here's the analysis of the application on how an application could better make use of it. That is consumable by this particular industry and could be tailored to them. So there's a, there may be something in that respect that we can, that we can focus on. To add to the discussion. I think this discussion has more value when we're talking about the fabric orchestration not so much for inside the cluster I mean for inside the cluster right now we have multus, and we have dam and we have like the primary And all those stuff are working fine but or an SM, but when everything goes down to the fabric then we don't have something that we can actually link the application that actually run inside the Kubernetes with the fabric orchestration with the fabric needs that the application has. So, I think the external network orchestration here is more about how we can be sure that we can actually deploy our applications and the applications are going to be a, are going to be served correctly from a networking perspective on fabric so that means that if an application needs to have like access to a range of Or to a range of VXLan networks on the fabric, they, they should, they should be able to do this on the fly so we should have an orchestration mechanism that actually configures those VXLan or VLANs on the fabric and then everything is ready from networking perspective and then the application comes up and it can work normally. I think this is where this external network orchestration phrase comes from. And just as an extension to, to the materials or comment. And I think we mentioned about the wounds use case that is related to the infrastructure layer and lifecycle of that infrastructure object. So I think, I mean, I would classify networks here into like host network and the tenant networks and host networks we can say like a day zero configuration in the networking domain so when the cluster has to be spun up and all the interface that working that has to be done on the day zero configuration during the life cycle of the cluster. Let's say that could be classified into into that domain and then comes the tenant networking that will be required by the given network function that will be configured on demand dynamically. And that's what we are kind of targeting with this external network operator and I agree that it could be a bit hard to like understand the external networks here in what context which we are referring. So I tried to simplify and try to explain it one of my comments also that we, we are basically take considering the L2 networks that connects the default Kubernetes networks or are, and a special secondary, like he called the secondary pod interfaces to the DC, DC edge for the DC gateway. And for the external connectivity and that's how we come up with that external network as a term here. So, are you suggesting that the operator you're this external network operator doesn't actually do the work itself. It just consumes the requirements of the CNF and pass it on to an upstream. So it has two facades like I showed once in the, I can maybe share as well. So it has the pluggable architecture for one second. I hope I'm sharing now. So I put it this as a comment as well in the discussion. So, you can consider this dotted line as the above APIs and the agnostic operator as one facade and the second, the bottom part as a second facade architecture. The top layer is basically which feed takes the inputs from, let's say the orchestration layer through the CSR packages and does the, and that layer basically responsible for the model to model translation because that that's basically has a different architecture and it follows. Basically it has to make the translation that Kubernetes can understand so those CRDs will be then in a YAML format, right so and that goes into the this called fabric agnostic operator. And that supports the pluggable architecture for corresponding fabric that we wanted to orchestrate through you know, the problem is I don't, if I'm a network operator, I don't want that fabric agnostic operator ever making changes to my network network directly. Right, so if you think about a top of rack switch that has to be configured before Kubernetes was ever installed right. That's completely fine. Yeah, that has to be done on day zero and that somebody else responsibility to do the control switch configurations and all right. I totally agree there. Yeah, what if what if what if the the CNF requires a different VLAN. And for the network separation or for VPN connectivity we require and we have requirements on CNFs that are CNF have the requirement from from the networking point of view to have multiple VLANs and different so that they can segregate their networks on different VPNs and different networks right and that has to be configured. Somehow, on days, day two day three activities when you have to deploy your network function and we are trying to orchestrate that through. Yeah, I would never, I would never want my network function to make those changes to my network. So. Right, but in his drawing he hasn't talking directly to the fabric. I'm saying that there should be that plug in is not to the fabric that plug in is to some northbound operator that owns the physical infrastructure. Well, I assume it could be some sort of manager right if it's an SDM controller or or something else somebody has to own some component has to manage it right because we're not talking just about day zero or day one but also day two. Let's say you need a network function, and it doesn't need that VLAN anymore so that VLAN should either be deprovisioned or be available for because these resources are limited to right so. But it shouldn't be the fabric of Gnostic operator talking directly to the fabric is all I'm saying. Yeah, so it will be through the plugins right so that plug in. I'm talking about there's already an external manager that owns those assets, right. So if I'm talking about, you know, contrail. Right. Yeah, there's already a Juno space, which is their EMS instance that owns the state of contrail. Right, and I don't want anything making changes to my overlay or my physical network, unless it's going through my contrail controller. So that plug in wouldn't talk directly to the fabric it would talk to the controller. Yeah, that is completely fine that is completely fine I mean if you you can when we're saying fabric here, if you can see we also have neutron fabric I mean neutral fabric it's a virtual fabric. You don't talk directly to your. You talk to neutrons that needs but yeah right so that's my point. Here you just say fabric a it needs to be very clear that you're not directly. Sometimes somebody needs they want to have like a bare metalization of Kubernetes and they they want to give like access to fabric directly. So, so you want to have access to shoot through your control controller and not talking directly to the fabric but to your control. I don't think you'd ever want to talk. I don't think you'd ever want I can't think of one scenario where you'd ever want Kubernetes to be owning the configuration of your fabric. I mean it's an option if nobody wants to create a plugin for to talk directly to the fabric that's fine I mean they have possibilities. I think this is exactly why the word external came in here right that that's exactly that separation of concerns right so it's called external because it's managed externally. That's that's where that's not what I agree that's not what's shown in the drawing. Okay, we can. I think I think we first need to identify the use cases before we talk about like the best way to solve something personally but like, I don't think we all agree on like external network versus internal network you keep talking about host level networking which is like, we're throwing around a lot of terms, I think that you know one of the things we need to think about the next week between now and next Monday's call is some potential terms that we put in discussions and start to add to our glossary because I mean, I'm going to be completely honest, I don't really know the difference when you talk about you know these network provisions of when you're actually provisioning a network in the sense that you're creating like an L2 domain or an L3 domain that is going to expand multiple devices this and that versus just creating an interface into an existing one right like shared versus shared versus external, like, are we just creating an attachment point, you know, and then to change concerns like is something like pre establishing this. Once again to do we a talk about like, there's this concept of like kubernetes which is an orchestrator versus the CNF, and we keep using those two things like they're interchangeable and to me they're not like, like, are we going to allow in workloads to make requests to the infrastructure like, and not just like at a low level, like, you know, I want like a kernel interface into a pod type thing but also like, are we going to see enough to talk to neutron or NSX or you know your VPC directly and request new submits new VLANs this and that. Or, you know, do we have something like on the outside like do we shove it all into case or do we allow like the get ups process to do what it does in case it's just one endpoint with one interface. I'm just changing something that it's good at like, I really think that we need to clear up some of the terminology, start defining the difference between just attaching to a network versus creating a network and then explicitly state what use cases, we're going to tackle because I'm just listening I feel like we're talking past each other on a bunch of different topics. I think some people are talking about kernel interfaces, some people are talking about spinning up virtual networks in their VIM. They're talking about then what happens when we touch the physical fabric, do we allow kates or do we allow a scene up to do that. And then, once again, there's a difference between Kubernetes making requests versus the end application running in Kubernetes making requests and I think we need to be succinct about how we delineate that. Maybe it as well in the internal and then external approach. So what if I spin up a pod that has either OBS or VP that is exposing a some form of a interface or network, which it then terminates and then loads into IP sec to connect to some extra to some external organization. In that scenario is that is that pod that is hosting OBS or VP P and internal or an external network in this respect. And so I think that the the terminal terminology that we have here is is not well defined and confusing and if we could get started on some form of a glossary that that would be to harmonize the terms that would be very helpful. Yeah, that's a great idea. I agree that it's a great idea. I think Jeffrey, I think for it's a little bit ironic that as as networking people or self proclaimed networking people, we keep throwing around the word network where, which is obviously so so overloaded here. I think we really need a very clearly defined glossary that we can all agree with the adjectives that we associate with network. I personally think the first comment I meant I thought external is not a very useful adjective. But we can find more precise words we need a lexicon basically for for networks so so when we say it at least within this group we know what what we mean exactly. I propose we call it a network momek on a monad. Just a last comment, I think there was one comment made by somebody about like, okay, we can revisit this figure and yeah, can can explain more precisely and comprehensively where we actually interface and what are the different interfaces but yeah, there could be it's it's not that it the plugin has to talk directly to the corresponding fabric and if there is any controller, which is wrapping around that particular fabric A or B. And then that plugin can basically talk to that control and then eventually does the orchestration or configuring the V lens in the in the fabric. And I would like also I look sorry for it that I would like to add here that when we're talking about fabric a fabric B and stuff we can. We are talking like in a production environment, probably is a controller that actually controls the fabric. So the fabric plugin actually talks to the controller that actually controls the fabric. But for instance, you can have like a two VMs that actually run Kubernetes and you have an obvious fabric outside of those VMs that those VMs are connected to and this is just dummy fabric is just for demo purposes. So the obvious plugin that you have there is just a dummy obvious plugin that actually talks to the obvious dummy fabric that actually those VMs are connected. So in that case you talk directly to the fabric. So maybe the terminology is a bit confusing but yeah. Well, even the word fabric has to be unpacked a bit. I, there are a few products that are called fabric in the world of SDN but we might be talking about the fact of fabrics that are encapsulated from existing physical functions with some sort of management. That's just saying that's another word that I hope we really all are talking about the same thing. Yeah, is, is there a use case here as well, where the plugin may want to talk directly to a top of racks which to request a specific configuration on on a port, or to configure it in a specific way for maybe some some cost requirements or similar. Yeah, maybe maybe you have like a legacy switch that doesn't have any API and you need just to directly go inside the switch and configure it. So for that reason, you need an app plugin to actually go directly to the switch SSI to the switch and do the whole configuration for instance. We're talking about these kinds of use cases, maybe this is a use case for somebody maybe not for us not for not for big companies but for somebody maybe it is a use case. Yeah, so that seems to be an implementation detail right that that's not too important. Yeah, yeah. The only reason I bring it up is primarily if I gray box on the bottom so that we're not precluding those type of systems. I've added a discussion, a GitHub discussion for the, the lexicon or glossary. So we can start putting stuff in there and then do a PR into the repo glossary as as we have enough information. And please try to provide some mapping to get hub, sorry, to Kubernetes terms. So when we're saying host networking that has a specific use, well known use across Kubernetes so if we're saying it's common somewhere else that's fine, but we need to, we need to match those up what we're talking about. So that the two communities can collaborate. And then we'll once we have that we can get it into the global, global glossary and then it can be used in the different use cases. So that's a that's a good idea we can, we can go through and prepare some grocery. The terms which we are using in this in this discussion and could help us to harmonize going forward. I think maybe one other thing we do to is draw like a generic diagram. We've said in the past we're not doing reference architectures. It's not what I'm stating but like, I think we should just have kind of like a visual representation or a picture that we associate and we sticking get that just shows like a visual representation of the terms that we come up with if we think makes sense, you know, network attachment point external network host network, all these things that we need to like unpack. I think that that might help to it should also be 100% like implementation agnostic, like, it's not an architecture it's not anything like that it's little just a picture that shows, you know, here's a tenant network. Here's a network attachment, you know, here's inside the host whatever I think that that might be useful to people to especially if they're not in these earlier discussions to play like catch up later I don't know if people are I think that's a good idea but I think it would be useful to have some type of visual representation of what these images mean and how they tie together to go along with the glossary. Yes, and starting, we should try to always start with or end up with a neutral point of view and then going neutral slash general. The diagram and the glossary usage and the same thing for use cases and best practices. Here's the ones. Someone earlier said, I think it might have been you Frederick, a lot of the app networking applications are are going to work fine as any other Kubernetes application so that's the general best practices. And the diagrams should be similar where we say, here's the glossary and general applicability. And now here's a separate diagram that shows some of these terms that are more specific would be good. Otherwise, we're going to end up with a one diagram that's a monster. So there's a discussion board and if you want to add terms or start working on diagrams and please do that you can paste the diagrams right in draw IO is suggested for diagrams. You can create the svgs export to Pings or whatever and share the link and collaborate like you would do in Google Docs versus something external that you have to upload the like a source file for some other drawing program, but whatever you can contribute is appreciated. So is there let's, I guess we can look at some of the other topics Jeffrey on the Yeah, I was about to just yield the floor. I put a comment in a loax discussion tagged a bunch of people. So, just kind of take this into next week, kind of think about some things think about glossary terms you think we're lacking we can continue the discussions here, but I think we were probably good for this week and now it's just time to kind of like what steps do in our minds for a bit. All right, let's see if we can run through that the remaining items and you want to pull that up or would you like me to do that open if you wouldn't mind getting some some messages I'm trying to respond to at the moment if you wouldn't mind sharing. Yeah, sure. Let's see if I can. I'm not sure if that's working. I'm looking at the pull request. Let's try again. Can you all see the window. Yes, we can. Okay, so we're going to defer talking about the said book is not on the call today so we'll talk about the life cycle. Next time and folks can look at the comments there's been several iterations on this. I opened this a while ago but it was a draft. This renaming anywhere where it's talking about conformance over to best practice. Proposals but also just the wording across the board has been done, updated the use cases the directories names and the links and stuff like that. I don't think. Oh, let's see. Thanks in reality check. Bill, are you here. Yeah, I'm on the call on this. Okay. Is there any change here. Yeah. There's writing context and reality check for. CNF best practice proposals. So this is about the relationship between a best practice and use cases and we keep saying that any best practice propose needs to relate back to a use case. What we're trying to move to is best practices that are small, small enough that each one can be combined with others and build up, but they all should relate back to use cases one or more. I'm good with that wording reality versus sanity I think it's either way it's I'll just take that. Okay. So let's look here. So most of this is word changes like this so CNF test suite. This focus here I didn't change everything because there could be something for conformance going forward. So most of it's just right in here the wording. It's not going to we can just if we decide later this too long fine but sticking with this name so CNF best practice proposal, and it's just been updated across all the different places. The templates. The read me refers to it. Some typos. And that's it. I think we have an approval right now. I think we had to and then ask for an update. We get some plus ones here to merge this or the questions comments objections. Plus one from you bill. Yep. Anyone else. I got a few here. To merge. Moving towards best practice. Okay. Anyone else like to get at least one more. Anyone plus one. Merge it today. Happy to it. Okay. I'm going to merge it. I've already merged. I think that was with and also had hers in here. I think we did the changes you wanted. Okay, cool. Let's move on. So add values to the charter this ended up getting split between this and this expanded. The first it was a very minimal. There we go. This very minimal. Well, I just got a four or four. This very minimal update. This is based on some seen a CNCF projects. Kubernetes projects that a list of values. This would go in with the mission and everything else in the charter. And then there was a request to do a lot of expansions. These have been resolved and moved over into. These are some of the builds on that original set. The first is, can we, is there a. Agreement to merge this as a first iteration. Oh, and it looks like we got them. So we got a bunch of. So we're going to do that now. I didn't know. Got those. Okay. So now here's the expanded version. And then we're going to move on. Closet is better than exclusive. Go into this evolution is better than stagnation. These are actually in the last commit versus improve later. Commit first improve later. So trying to. Do quick iterations and not. Have to get it perfect the first time, which could take a long time. Pragmatism over politics is somewhat related to this. Going more into. A lot of different ideas, but when we bring a best practice for it, we're not putting a best practice that is not implementable. It's just an idea if we had an amazing system. Of course, it can be put forward, but we're talking about as adoption of best practices that can be used in the real world applications and use cases. Focus on community over specific products or companies. So putting the common focus or value as the whole community and how we can benefit and then adherence to the code of conduct. Let's see what we already have. And it looks like we already have. Approval so. Enough to merge. I'm going to do that. And let's see what do we have. Super Lenter. Did this one get covered? Victor, are you here? You're here, Victor. We have zero approvals. But just request like a new. Because I did. Rebase the latest changes. So I just request more. More reviews. Okay. Every time that you merge something, I have to raise it because. I need to. Make sure that everything. We got rid of the line link. There's some other issues. Okay. So we need a new review from folks and then hopefully get this in. And I guess you can resolve the conflicts. And then. With these updates. And then do a review on this one. It will be good. All right. Let's see what else do we have. Okay. So I think the other two are. We had two different. Approval processes. Well, one was. Specific to the PR process that bill was putting together. And there's been some. Discussion around this one. And. And. This ties into. Having a set of chairs or tech leads. To. Approve things before they get merged. And this is related to, I think I get hub discussion that I'd put forward when we were talking months ago ideas on. How we would do this. And we had. Simple. A little bit more approval and so forth. And then I put. Kind of iterating on, on those ideas and what we were trying to do. This acceptance process and then delegation. So this includes. Both the PR process and. The charter or governance. Items. So on the contributing. I've expanded on it. Based on feedback for what are the different ways to do things. So we're more extensive on. Here's what you're going to do to create a pull request. So this is specific on changes with pull request. There could be changes via voting somewhere else, but this is pull request stuff. And then. Having some number of reviewers. And then acceptance of the PR. And then there was questions about. Who are the reviewers? So we put this in here based on. Feedback from Ian and. A few other people. That anyone in the community. Can be a reviewer and then we want to encourage everyone to do reviews and be able to do that. Any minor change. Is one reviewer. Majority of other changes right now are saying five reviewers. This is on the contributing guide. So there's no, we can update this. We could decide. You know, in a month that we want more or less reviewers. And then the items and it says, except for the items. So except for the items that are in this governance, additional approved item list. And that's what is. Here. So this is under this content approval. Section and. This additional items. So this list. So the, the. The items needing approval, the list, adding or changing this. The actual charter itself. Governance. This should say the governance document is what this is pointing to. The link. The code of conduct. So any changes to that. And then the adoption of. Quote unquote approved best practices. So these would be the ones that we, they may go into this guide that. Robbie created. But these are the ones where we are saying we have now approved these as ones that we are promoting as best practices for the community and everyone. So once it gets to this point. And this may be a status. It may be. If it's in the document accounts, it may be that we say. Your status is now, you could think production is production ready. We agree. There could be an earlier list of best practices where we go. So these are not approved, but stuff that we're considering. But that's the list and the change and the way to do it. And then everything else is delegated to the community. At a, at a less. Allowing it to go through it. A process that. We can change as needed to make it faster. Is the idea. That's in the contributing guide. So we have a few reviewers and there's been a few. Well, there's been quite a few updates, but. We are at time. So I don't want to stay in here. But it. This, these are both. Very important as far as on the governance side. Of things. And especially when it comes down to. Promoting best practices and everything else. So. Please take a look at these two and. We'd like to know is which direction we want to go. This one's more defined. And if we want to do that, then it means. We need to get tech leads and everything else. And this one is. This one's more focused on allowing us to start working on use cases now. And blocking that. But please take a look. Provide some feedback in the, in this. One thing that we need to know is which direction with the community wants to go. We want to go down this path or do we want to adopt this one for now. And then any specific details. Thanks everyone. See you all next week. Thank you. Bye bye.