 All right, we'll get started I guess at three minutes after. Good morning. Good afternoon. Good day. Good morning. Started in a couple minutes here. If you have anything to add, let's put them in the meeting notes agenda item. Hello everyone. Petitor also joining from Intel. All right. Does anyone have anything I'd like to go over? I have something around the best practice categories that I put in there. Nobody has anything else. Jump into that. If you're talking, I'm not hearing anything. Just to confirm, I can hear you Taylor. I just have nothing. I just have nothing to add. Let me see here. I can try and get on the different pages for these. I'll list it. And I don't see any new discussions or I mean like a pull request. There's no open pull request. I'm going to share my screen maybe that'll be easier for Oliver and Peter if she'll have something you want to go over and speak up or type it in. So no pull request and open issue wise. One of them is about having a category that we haven't had in the CNF working group but it's existed for six months or more in the test suite. But I won't delve into that because we're about to talk about categories. Define cube native. I don't know. I feel like this one, I feel like this may have been added. So just doing a little cleanup here. Let's not go into edit mode. Glossary kubernetes. Did we never add this? TBD. Committers. This is probably something that we need to circle back to and get in place. How do we get people commit access on the repo? I'll put that on the agenda for talking with catchers. Do not run containers. So this one's probably still a good one. The end put forward and we have discussions about it. We have a bunch of docs from the last three months about lease privilege, principle of lease privilege. So that one's still a good one to put forward as a best practice. Leave that one up. All right. Close the other one. Yeah. Okay. So we might close that top one out. Ian's not here. Let's check. So best practices. I'm going to have to go over this when there's more people as well, but for those that are on it. So we have this. I'm going to. Here's the categories other than resilience that we have. Configuration life cycle, installable, all these things. So observability, it doesn't have resilience. That's the one that's not there. There's been questions about updating some of these for a while and comments on the CNF test suite. So related for the documentation and publicizing on practices that we do in the working group. Testing those things. Been talking about updating these. The first two are kind of areas of concern. Hardware support, an area of concern. And then we get into stuff like we expect observability, security area of concern. We expect compatibility and how to make it where there's area. These categories are sections that we're going to have practices in them and that we can test those practices. They make sense. They're valuable when someone comes in and understands what they're about. We've been talking about updating these and getting comments for a while. And the test suite side we've been looking at it a little bit. Potentially updating. So I didn't get a slide ready for this. I'm going to give kind of a draft of what we were thinking about right now. Some ideas. Potentially update draft or maybe I call it working progress. So right now there's 10 in the test suite. Nine on the working group. But I think we would add resilience because we've had a lot of what would be good practices. There's a lot of things that you want to cover on resilience and availability and stuff. So I just hadn't, there's a ticket up and just hadn't been added. We're looking at here is some merging and updates around naming. The configuration lifecycle is so large that you end up with so many different things all covered in one. It becomes a massive category. So what we've done here in the suggestion is to split it up and lifecycle kind of gets merged and the parts in lifecycle get merged into other areas that cover what it's doing. And the configuration would be potentially we could rename it. But what we're really talking about is declarative configuration, both for what you think of as like the config files, what you need to do to get something ready, deployment, and all the way through upgrades, but also stuff around like declarative APIs. Everything declarative. So this is what that's about. So maybe it should be declarative configuration or something. But that's that category. This one, if we look back, merges several. So you got the compatibility there. There's some stuff from my cycle, installable and upgradable. Compatibility, installability, upgradability. So that ties in with a lot of the practices in that area for managing applications, how they work together, how they work with platform, how you can deploy new versions, downgrade, all of those sort of things. There's a whole lot of security ones. So this one's becoming a large category. Potentially security can be part of everything. But right now, seems like people are going to look for it. So we're not suggesting to merge that. State also would be something where there's going to be faithfulness in a lot of areas. But right now it seems like pointing those things out is important for keeping that separate. Microsurface observability, some sort of things. That resilience category, merging, scalability would merge in with these. So there's a scaling where it's called. It is called scaling here that merges in. So talking about how available it is, reliability is an indicator. So we don't have reliability right now as a category, but that's what we're talking about with regard to services. We want the services to be available and reliable. Adding resilience and different practices on making things available and stuff. That's what this is about. So yeah, thoughts and feedback. And let's see who else joined us. Oh, hey, Daniel. Going over a, this is kind of a work in progress proposal, but to get feedback from folks as well. Category updates to have them make more sense. We also want alignment with the test suite. We're missing a category, but trying to merge them and make it work a little bit better. I have a question, Taylor. I think to me the categories makes sense. I'm just curious as you're referring to the test suite. Since there are tests already in the test suite, do you see any way we could actually bring those best practices that are in the test suite into these categories in some way? Like you're just referencing them or pointing to them? I don't know. I'm not saying it's a good idea. I'm just curious since there are categories and there are tests today. What are your thoughts there? Are you saying the tests that are in the test suite create best practices for them in the working group within those categories? Yeah, I think is that what you're I'm just trying to make sure I'm understanding your question. Yeah, I think that's what I'm saying. I was just reacting to the fact, I mean, you're mentioning these categories and the fact that you have the categories in the test suite as well. And I'm just thinking to myself, the test suite is obviously not empty. There are tests that are fulfilling some purpose around some of these different categories. So my question was really what would prevent us, good idea, bad idea, I don't know, but I'm saying what would prevent us from actually populating some of those best practices, you know, from the that are already part of that test suite. Was that just a bad idea? Oh, I definitely think it would be a good idea to move those or I'll say create practices around that. It's more of just the effort to do so that needs to occur. But that's, you know, if it's an area, I'm trying to work on some my place pretty full, but I'm trying to do that for sure. And anyone else who would like to do that would be happy to work with work with you on it. And that can make it, you know, potentially easier to add new categories since we're working from something that already has content, especially newer tests, we're trying to add the why, why it's valuable, what it's testing, and wherever possible remediation type of results, which may point to say upstream documentation. Here's where Kubernetes talks about this thing or whatever. And that can help with writing up the best practice content in the working group. And of course, expand on or add new user stores or use cases. I'm going to show this like this is just kind of a working little draft here of content when we're looking at the test suite. But the security has these, it actually has a lot more, but here's a chunk of them from the snapshot back when it was created. So microservices, configuration, lifecycle, installability. So what we'd want to do is go look at the newest, what the newest set are and can go in like, here's all those resilience things that we're talking about. So yeah, for sure, we could go in and do that for all of these categories. Okay. Yeah, and it may not be the right that we do them right now. I mean, it may make sense. I was just thinking there, as we have these categories and start populating some of the tests or best practices we already have, you know, unless they unless we don't agree with them to your point, you can change them, you can add them, delete them, that kind of allows us to move from an empty categories to starting to populate some of those. Yeah. All right, thanks. Anything else? Try to make a version of this. It's easier to say four, seven. That looks like we're looking at. So here's what we have. And there's a potential suggested change. We keep security, observability, microservices, state, these, we have this compatibility and solubility, upgradeability, which takes some of the configuration lifecycle, takes this installation upgrade and merges that. This reliability, resilience, and availability is merging some of the things from lifecycle, scaling into that one. Hardware support, which could get a little bit of configuration or compatibility as well. Any feedback on that? All over, Peter. You find it easier to understand what would fit into seven versus 10? It's almost like when you're going to the optometrist and say, better or worse? Right. Switching out the lens there. I think it's clear to me. It's clear this way. Yeah. Less is better as long as everything is kept at the right places. Yeah. I would agree. Is there any categories that you all are just thinking we should have this? Why is it missing? Or do you think here's a better name for that category? Is large-scale result of doing those here correctly or? I'm sorry, is what? Proper scalability is result of doing those here correctly and not a separate something. The scalability? Yeah. The scaling was one that we thought would merge just to reduce the number of categories. Yeah. And it can. It can. Okay. Be part of some of it's trying to communicate. We're trying to communicate what are you getting out of this or what is a very important area with the way these are set. Security would be one that can go either way, but it's something everyone is recommending. So highlight it right now. The reason why you want scalability is not just to scale, because you could always put extra servers that are just sitting there. But that ties into either resource efficiency, scaling up or down, but you want to make sure. I think from the standpoint of especially the telecom industry, it's tying into service reliability and are your services always there and available? And then you get back to resource efficiency. So I guess it's decreasing the resource efficiency. That's kind of the thinking there. Thanks. But if we need to highlight it, we can always bring it out. All right. Well, I guess that's it for now. If there's nothing else, we can just stop there. But again, it's a half hour. Anything else? If you do see a test that you really want to have a best practice for, you think it's important. There's an area. You can look at the test. This one's I think related to maybe one of that current open issues. It's probably be related to like this one. This is a privileged flag. Here's one about privileged containers and talks about it's important. There's an NSA Kubernetes hardening guideline. There's a bunch of others in here. And you can see those were adding more and more content on the details on why these are important. The resilience category has a lot of these too. I'd be happy to work with folks if you want to add these as best practice, just reach out. Thanks, everyone. Thanks. Thank you. See you next week.