 Greetings. We'll give it until five after to see. Who shows up. All right. Hello. Greetings. Hi, Rich. Meeting notes are in the zoom chat. Does anyone have any topics. For today. And add your name and any items to the gender. So to allow to add it to zoom. Have you attended this call, Rich. In the past. Yes, I have. Occasionally when I don't have overlapping meetings. Understood. Victor. Hi. Good morning. Let's see. So. October 10th, we've got a couple of weeks until. We'll talk about the member. And. Club native telco day. Rich, are you going to be making it to it? Either of those. The. Collocated to van or. I'm not sure I'm going to be able to make it there in person. You know, I know. Phil. Our group is going and speaking, but I don't know if I'm going to be there in person. Of course, if you're, if you see it, we'll be at Claudette of Tokyo day for the whole half day event. Reach out if you're going to make it and let Bill know. So, like to meet up with you all. Yep. What about one summit in the fall in Seattle? Are you all going to have any presence there? I need to check and I might come up for that. But I don't know if we're going to have who else is going to be there one summit. Okay. We're planning on attending one summit and the elephant developer forum. We're going to have a workshop during the elephant developer testing forum. For using the test suite and focused on certification. We're trying to make it an interactive session where we can try to help work through any issues and maybe make improvements right there. And cubes con EU. As long as there's no big events that stop it when planning on being there in Amsterdam. We're looking for sponsors for the cloud native telco day in Amsterdam. We had a lot of feedback that would like to have a live stream so we need to get some sponsors to be able to do that if there's interest. See here. Does anyone have anything specific to go over otherwise I'll jump into PRs and issues. No PRs. All right. Had a lot open for a long time I guess it's okay to have no PRs. Okay, so this. Do not run containers with privilege from a flag. That's one that I'm working on and we have a lot of content. So if there's anybody that's interested in the security best practices. This is probably one of the areas where you can look. I mean there's a lot of other content out there. Kubernetes security at this point, it's picked up a lot, but we've done a lot of research around the least privileged ones. I'm going to just link to this. Yes. So there's a lot of content in here. I'm going over least privilege related best practices and deviating for CNF development. And it links back to content that we have been also upstream into other areas, but it covers a lot of stuff down to low level things and the packet filtering and the higher level. Another issue is, I would call it a higher level, but a pretty straightforward containers running with the privilege flag is what this one's about. We've had it open for a while so I want to try to get this through. There's tests already on it. I think we have duplicate test, even across different upstream tools. We're just running one at this point, but I think that one is a pretty well covered. Do this as the default. Taylor, I remember that one of them. Yeah, but one of the points of, especially with privilege was related with the attaching with special devices like this or you'll be or things like that. Are you covering that part in the document. I haven't read it, but I don't know if you have mentioned something like that or this document is covering a lot of different things. I think for the, the actual best practice right up for this one, which this one was assigned to me at least in Google Doc. I want to try to get it out we, we should mention that. I think that's a general thing as far as like the SRV this, you know, we have some content around here for that. The, this whole section about why it can be a problem that starts going into the higher level and then talking about specific things like SRV why you would maybe want to do it. Are you are you referring to it as like an exception or what are you thinking, Victor? No, no, at least like I haven't read it so probably I need to take a look at probably what you have is enough for clarifying most those or how of developers can use it as an exception maybe or, or another work on if they need to, if they are facing with these particular requirements, how can they use it or, I don't know, like, but more likely I need to, I read it, I need to read it. Yeah, I mean I'd be happy to chat with you about it. And work on this. I know you're working on the, the networking best practice with multiple interfaces, maybe we could have some working sessions to go through both of those. But the, we've started covering some of this as far as exceptions in different ways. The document that Ian put forward for listing any exceptions to following best practices and the guidelines. So that you're communicating from someone creating CNS and where they don't follow exceptions. And it could be obscenes and aggressions anytime you're not following and communicating that so that the people that are using those and managing them will understand where the exceptions are. So that's one side. On the testing side we've been thinking about it from how to validate best practices and we have the concept of exception less specifically around this. So if you're running privilege containers and other things. And you know that you need them. So, you know, one example is there's privilege containers privilege pods that may be running already as far as that is core pods or you may have some other one that you're running that everyone knows and it's okay. So that, I think is something that's going to keep coming up. So we need to make sure that we're differentiating between an exception and what do we believe is the default. So keep, I'm just saying that so that we keep putting it forward and don't say, because we have an edge case or because sometimes there's reasons to go around doesn't invalidate having the best practice, which I know you're But if you have some time maybe we can go over that together. Yep. All right. Requirements for multi interface. Working on this. Do you want to, is there anything new to speak to I haven't received any comments or feedback about these documents so please take a look at if you can see or something that is missing or like it would be nice to expand it. Rich, did you see this one. No, I've not looked at that one in depth yet. All right. So, Daniel Bernier from bell Canada created this issue several months back to talk about the different aspects. So this is multiple interface but you could also. I think it's important to think multiple interface or multiple connection network connections that are segmented. So, there's different ways of, of solving the underlying problem and multiple interfaces would be one so if you're going down the path of multiple interfaces and how are you going to do this in a different way and what are the different aspects here and Victor broke out one part of this. Multiple interfaces. This is talking about being more declarative as far as how you're implementing this. Using annotations so he has a document here which you can check out it's linked into the issue to start the conversations about using annotations to communicate the networks made the devices. The need for different devices and a bunch of different aspects. Okay. I'm going to look into it and I'm going to loop in a couple of people internally. Yeah. I think this is maybe the core thing to keep in mind with this particular part of that so they the issue itself. You know if you're looking at this. And again this was something that a CSP. They're bringing forward to talk about. This aspect is about trying to be neutral toward the CNI specific parts to make sure that you're more portable. So if you may be on a cloud, if you're wanting to be able to work with any of the different CNIs and especially move between cloud providers I think is probably going to be the bigger thing which is what's being asked. Or I should at least say the a Kubernetes distribution where they may have multiple CNIs depending on where they're running. One of the things similar to least privilege is trying to make sure an application can degrade gracefully. And this would go along with that Victor so if you have a, if you can support specific CNIs in your application great but if they don't have the CNI that you were expecting then being able to communicate like with annotations here's what I'd like and then ideally the platform can say okay well here's what we can provide. And so you can degrade from best possible case where you have very specific things for the CNI to a less specific. Anyways we want feedback and I think from the standpoint of creating it's important, along with, you know, working with what's being requested from CSPs and the integrators. Okay, okay. All right, I think some of these others are more documentation specific. I think there's been any updates on this. Oh, Tom, what do you got here life cycle management problems best practices. Yeah. Sorry for being late. This is something that's been rumbling around internally for a while. So, I think everyone kind of agrees on the target state for life cycle management terms of making it more cloud native and rolling updates and so I think the CNF test suite deals with that as well. I just, I don't know whether this is the right forum or not and it's more of an open question of whether it's something we should discuss here or take to somewhere else of where we have converted commerce cloud native platform vendors, supporting, let's say, the last or the latest three versions of Kubernetes for which gives us a year of support. We then have the matrix of what versions of Kubernetes do the software vendors support. We then have the matrix of how capable and quickly can we upgrade one or other of those things and how automatable is that process and, you know, so on so I think there's part part of the problem we have anyway is about internal kind of acceptance and onboarding process, but part of the problem is, you know, if it's taking six months to upgrade a platform, then basically we're going to be continuously upgrading a platform, because of the cadence of when things are supported. And I just wonder whether there needs to be something a bit more explicit written down as a best practice as well as the things that are tested like, you know, can your CNF do your rolling update in Kubernetes, something writing down the kind of rationale, the, you know, how we should approach it so that, you know, when we get a new version of a CNF, or a new version of a bunch of CNS, maybe from different vendors, the upgrading them in, you know, in a coordinated way isn't a huge operational headache. It's a series of changes and get tested and then deployed to a production network. So yeah, I don't know if this is the right forum or not, but I thought I'd raise it and see what people thought. I would think so. If it gets down to implementing the platform and like suggestions or whatever. I don't, while we're not focusing on on that specifically, I don't think we should stop from writing up information that's, you know, related to what we're currently doing. Yeah, and it's not just, you know, as an example, I won't name any vendors, but you know, we've got some applications where if you want to upgrade them, it's a redeployment activity instead of a kind of rolling update approach. And I know, I know we've got a test in the CNF test suite that tests, can you do a rolling update, but I don't think we've got anything. Well, I've not seen anything that's been written down as a best practice yet to explain. This is why that's the best way of dealing with updates as opposed to a, you know, redeploy the new version of the software and then tear down the old version, all in one monolithic kind of approach. Yeah, both. I mean, the, the concept, I think you're referring to like the concept of a Kubernetes rolling update, or the, or the very generic term rolling update. Yeah, both really. Yeah. So, I think one of the underlying pieces that people aren't that are not as far along is the importance of, of breaking the larger application or product or solution, whatever you want to say, the larger set of services in a, like a large workload. Into the smaller micro services so that each of those can be redeployed and reconnect. You know, one of the, the 5g core, a lot of the components that I've seen are dependent on a lot of pieces being up before they before you can bring up other pieces like they have to be fully running connected and talking. And if they're not, then other pieces will fail. And you would have to redeploy everything. And that type of, I think that's, it's the design and architecture that they're not running as smaller autonomous services. It doesn't mean that a maybe a, and a consumer of outside of the CSP services may not be able to get their service that's not the point. Each one of them comes to some type of ready state and says, hey, I'm, I'm waiting for something to connect and then I can move to the next state. And each one of them are autonomous and that's their, the design is more procedural. And even if you, you know, your language is object oriented or you talk about modularity. When you look at how it's run, it's a procedural set of services. It's going to move forward. And I think that's a lot of what's happening. So when you look at the rolling updates in Kubernetes, you actually will have new services, a pod come up. A new version and it's going to take over the services will now point and I'm talking Kubernetes services. So connections will be redirected to the new pod running the new version. And talking about rollback and all the versioning, it has to do with redirecting your connections between different pods running different versions, and that capability. So a lot of it has to do with architecture and design. And I think that's going to be an important part if we're going to bring people forward to support those sort of things, it's going to be understanding, you know, the principles of some of the architecture changes that are needed. Yeah, I agree. I do think Tom this should all be documented and written up. We don't worry about if it's a perfect fit for, is this an application practice, we just start writing it up and then breaking things out. So I'll quit an issue then for the first, first bit, which is the kind of focus of it and then I kind of agree it's linked into so many other parts of the best practices that I needed. Yeah, I'm pretty sure we have stuff that would be similar. And we're in the discussion area. Yeah, I'll have a look for you. What you're doing specifically Tom, I'm saying it's, it's areas that are people may think is this relevant, but it's, it's relevant and that if you have some area that overlaps, we don't want to stop it just because it doesn't. It's not fully in one side. Instead. All right. Okay, I'll have a look and I'll quit an issue. Sounds good. I'm working on some text there for the some of those tests that you were talking about that are related to the life cycle management and releases and stuff. Any documentation in the test suite for those that could go along with whatever you write up. I think one of the areas would be. Let's see. rationale. So these would be shorter statements on things. See really great rolling down grade. Yeah. So these are some. And then there's it in the test suite specifically it's broken out across different documents. But I think some of this will be related to what Shane and we could pull some of that into a document. And I feel like there may be something linked out of the discussions like a Google doc or something. I've heard the request for some of what you're wanting to write up. Many times. Over the last, you know, couple of years. So, I think it would be good to have have this written up. Yeah, I'll put some words down and see what we can see. I'd like to come back to yours. Set of questions also that's driving from the ops sides. I still think that one's a good set of questions that could help drive some of this. So at least. Link to that. You know what I'm talking about. Spreadsheet spreadsheet. Yeah. Yeah, I think that's related. Maybe directly like an ops question in general, but it can at least drive some thoughts around these things. Yeah, I'll try and dig that out. All right. Maybe we get to see if it needs some touch ups. Yeah, yeah. Okay. Anything else shall. Thank you. Bye everyone. Thank you Taylor. Bye.