 Hello. Hello, Oliver. Tom. Hi, gosh. Hi, Tom. Good morning. Good afternoon. Good evening. I think we have all time zones. Right now. Hello. Hello, Taylor. Good morning. Give it another minute, Tom. Yeah, sure. All right, I guess you can go ahead and get started, Tom. Okay, thank you. I've put the link in the chat for people to put their name on the list. So, looking down the event. So, to Wednesday. I'm going to go to the cloud security, Tom. Do we know where I'm going? Is there any toco? Useful toco. Events to look out for, do we know? The. Coordinated top of the CFPs are up and so definitely. What folks to. Get those in. While it's still open. When do they close? When did it. To the 12th. I noticed that. Right. Maybe. Yes. The next time. Yeah. Yes. There's so many events. Hard to keep up with them. It. We did hear that. There are going to be, there will be some toco presence there. From someone this past week, but. I'm not going to make it up to. That event at this late notice. Maybe we'll, maybe there'll be some good talks and stuff that we can see out of it though. Okay. Anyone got any topic ideas for the. DTF. These tend to be about. Topic, you know, the. Projects. So this is a relevant to talk to you. If there's any that we want to. Consider. It's a bit late notice I know. I wasn't checked it before, but I noticed now that. There's a national topics, which are. Great, like these. And even more are going to present something. So. Pretty nice to see. Some topical nephew. I mean, besides the other. I mean, so what. There's one of these ones. Cool. I can't think of anything off top of my head. We'd want to add. From a CNF working group point of view. I guess we could do a general interest. Topic thing, but. I mean, the, I think the bigger thing for me is that. It's so soon. And the deadline was the 27th. So. We'd have to really have something ready and ask, you know, ask someone, can you get it down at this point? Yeah. Yeah. I think it would be. I mean, there's a few things that we could look at, but I think. It's probably. Something for a future one. Any type of collaboration, which there's some ongoing. Talks that have increased recently. And then. The stuff that we were talking about going up to the end of the year. As far as, and then started this year for. Publishing. That the dev best practices. And, you know, if we can get. Maybe. Have that as a stronger goal with the timeline and then the. Energy. The energy. Focus stuff environment, environmental. Things that we're seeing more of. And there's post into Slack from. The Kubernetes. Some of the Kubernetes projects around this. And. Some of them. Possibilities for a future one. Okay. Make sense. Maybe over. A few weeks, we can. Have some focused talks about how. Direct specific goals and how we can get there. And those would be high and any future. Conferences. Okay. We'll mention the time it's telco day. Anything else anyone wants to call out or something we should. Submit a talk for. This is CFP closes soon. Open source summit in North America. If anyone's planning on attending. Yeah, good point. I'd like to know how. Tom, you and Victor think about the open source side. We talk about the cloud native a lot. The open sources, you know, underlying a lot of the pieces. When I'm in conversations. With different orgs and. Trying to get collaboration. A lot of times. One of the initial things is we. Our products are not open source. Or we're having to work with non open source products. If it's a consumer of those products. So for open source summit. It seems like we should have a slant where it would be more. Have highlighting more about open source and. At least in my brain when I'm thinking of it, but. I don't know what he all. So I agree. I think. I think there's plenty that could be said about the benefits of open source to telcos. I think if you were going to do it, if someone was going to do a talk on that. You'd have to address. The elephant in the room. Which seems to me to be the elephant in the room, but I think it's. The, the, the patent. Problem that telcos are reliant on. Telcos and telco vendors rely on patent revenue. And that kind of goes against the grain of open source licensing. And open source project. That it that's true to an extent. But I don't know what you're thinking about that. One is. A little bit easier, I think, for, to talk with folks about. Not. Not focusing on what you are doing with your product or how your business works specifically. And then more focusing on. What your business is built on and what your products are built on. I'm not throwing something out my own opinion, but I would. I would bet that. Most products out there are using some open source. If not a large amount of open source libraries and everything else, besides. If you're running on Kubernetes, then. Especially if you're doing like something where it also provides a platform type thing. But if you're providing like operators, you may be using some. Operator framework, but you're using specific pieces. And that's without looking at. Containers running on something and. Dbdk, you know, for instance, well, lots of. CNS that are dealing with the. And user plan are using dbdk and. You just keep going down that path. So you talk about. How open source has provided a lot of benefits. And I don't know, you can talk about that. And I think it. For some companies are more engaged with. The whole open source community. So it's not just a technology. And there may be feedback, you know, and user stories and stuff like that. But in my mind, that's kind of an easier path because you're getting more people to talk about. Open source and how they're involved, even if their product is an open source. And then the other side would be talking about. Different models for what does it mean if you have an open source product? How do you deal with that? And there's a lot of examples of those, including. The one that's looked at CNCF. Then a. A lot of the projects. I'm not going to say all of them, but a lot of them. There is a commercial version of that project where. They may call it enterprise or whatever else they call. It could be a hosted type of service. Or a version that has more plugins. That they have, but the core. It's not going to be open source. So, and that's just one path. There's a lot of paths for that. So I think there's an opportunity there. That. Similar to cloud native. A lot of other domains have learned what, what does it mean and how to work within, you know, how, how do you work within the whole. How do you actually adopt open source. Ideals and that are beneficial. Because this goes back to like. BSD and stuff, which would be. Research and science and sharing. Does it benefit us more? I think the telecom world is still can. Benefit from that similar to cloud native. And it's not sure how to approach it. Into for telecom. Because it's a little bit different. Like how do you translate and show like the benefits of the adoption. Yes, tricky. Because there's two. There's more than two sides to it. And then there's the, there's the use of open source. Kind of within your infrastructure. That is being used to deliver products. But there's also the use of open source in the products that you sell directly to consumer or business customers. So what are the degrees of separation between. The thing you're selling on the open source project. And I think the more degrees there are. Certainly I found the more likelihood you're going to end up with the. Patent discussion. Being had. I think, I think it's a good idea. I think there's plenty of discussion to be had plenty of talk material. On the topic of open source and talk. So I'm interested in the topic. I'm wondering how that ties back to. If there's a, we're talking about open source summit and a CFP. So is it something that we want to do as CNF working group. And that's separate from. You and I, Tom go, Hey, this is interesting. Let's go do a talk. Just completely separate. That's, you know, it could be upstairs telecom. Does that, is that good enough. To say that's related to the CNF working group. We're also interested. I'm just seeing how to tie it all together because we all have limited time. So long term, I think it benefits what we're doing. I mean, we're, you know, the CNF working group is definitely engaged in open source projects. So that's like, there's something there. I'm just not thinking of. More direct. I'm not. Making a more direct connection right now in my head. So. Let's see. February 5th. So that's this Sunday. Yes. Yeah. Does anyone else have any thoughts like how would we, because it, you know, if, if we're going to put time into submitting on CFP. If we have an idea and we just want to submit something fine, but. And then we can always decline later, but I don't have something just ready. But otherwise we need to decide on something. And we think, yeah, this has been official and maybe it ties back to what we're doing. Well, in my case, my only experience attending this. Open source event is in Austin. And one of the things that I noticed is. It's mainly to think that most of the sessions are where technical they were trying to explain some complexities of the technology. And the other thing is like. I feel like most of the tendons were looking for places to innovate but some looking for some fresh ideas or things like that. So maybe I don't know if that was my impression. But I don't know if we can provide something like who could meet those criteria like. I don't know, probably explain a little more like a sweet tool like how it works internally or like some of the benefits are. I don't know. That could be a suggestion, but I don't know if that could be also what we were saying before. So a kind of. A slightly less technical talk about the benefits of open source in telcos less likely to go down. Well, a more technical deep dive into an open source project that's relevant to telco might be more successful. So I've understood. Yeah. I just would maybe on that same topic. I know this wasn't necessarily the ass, but it feels like the, there are a couple of different angles. I mean, you can take the angle of sort of the benefits of using open source and the test suite being an example of that. Right. In with the purpose of helping to drive cloud date of adoption. You can make me. So depending on which form right, which, you know, I was thinking you asked earlier. And I think there was a comment. Yeah. Yeah. I mean, you know, you know, you know, you know, I think you put it on cloud. The DNTF, you know, for example, if you scroll up just a little bit, I think that was. I'm trying to let's see this on the, on the screen there. Yeah. That we had, you know, topics submission. You know, it's too, it's too late. That's why I didn't make a mention of it. But otherwise I would have thought that would have been a possible area. Certainly since there are. There's a lot of things that we've focused on doing collaboration around again, open source tool, using it across, you know, open source organizations. That, that would be another angle as well. So. I guess we were mainly focused on the open source part though, which was, which. That one's maybe we have time for that. That we won't have a time for the LFN. The DNTF this time around, but maybe one of the future ones. I don't know. I'm, I'm, I'm taking that into consideration with. What Victor had said. And. I think it's maybe similar to the higher level. Thing that Tom was talking about. And. If, if we can't find. If we don't think there's going to be a. A good audience for. What we're presenting. Then we can spend our time elsewhere. That's it. We don't have, I'd love to visit Vancouver again. I think that we should. Respect our time. And, and you know, know that we're only going to have so much time. So if. I'm willing to. Have a follow up. I don't want to take the whole call thinking about open source summit. If we don't have anything, but if, if we. Think that there might be something to focus on. Then we could do that. As far as the tests we open source. Maybe. It does. Give the opportunity to talk about. Collaboration with other orgs. So that could be like just one. Part of it. Using certification. And built on open source. And using a lot of open source projects. Different tools. And so there's potential for that sort of thing to be part of it. And I think that's an okay fit for open source summit. Potentially like pitching it. And why are you going to pitch it there? Maybe as a. A testing tool that could be, you know, used by other. Developers and. Ops folks and whatever else. And then just the benefit of collaboration groups. So I see something there. I'm. I'm not tying it back to why we would do it. I'm not tying it back to why we would do it. I'm not tying it back to why we would do it. Because as seen off, you know, working group folks and. And how that relates back to telco. So maybe let's table it. Unless you all have some ideas like more. If you want to continue, that's fine, but give the opportunity to move on. And if we table it, but we're having some ideas in the back of our head. Either on that. What you put forward vector or. You put forward vector. And then we'll get some time for this. I mean, I, I do think that we need to. Set some specific goals and try to push for more involvement with the working group and push more of. Like, how do we get people. Engaged in. Cloud native and open source. Telecom and the benefits of those things. And I think that we need to be driven by the efforts in open source. So a lot of it's just like, what are you missing in methodology? And thank you. Problem solving. Anyways. What do y'all think? Table it and come back. I think so. I don't think it's feasible. Do something by Sunday. Yeah. Well, I will. I'm going to just set some time on my calendar. And if anyone. I think so something. Just message me and I'll make some time this week. And if we're like, nope, we have an idea. Let's go forward and let's do that. Okay. Yeah. All right. Does anyone know about that big five event in Austin? Any. If y'all attending or know anyone attending. I won't be attending. I've not come across it before. Looks like it's specific to North America. Maybe. Focus. Which isn't a positive or negative. It's just a thought. What about the open ran summit? I think that might be telecom TV. Oh, you were there. Go a little bit down. Right there. Open ran summit telecom TV. I think that's what that is. Let's see if the dates match. Yeah. Possibly. Focus is on. Total cost of ownership. As I was. Stable. Preco system. So maybe if there's something we've got. That's relevant to the Rick developer ecosystem. I don't know if that fits into the. The agenda they've got. Certainly my, my experience of watching those things before is that they are not technical. I don't know if anyone else agrees. They get a lot of folks. Joining. I've seen that. Even the in person too. Filling up a room. But it seems like the. Conversations or. Conversations are pretty set. By the time you're seeing anything. Yeah. And it's often, it's often. Either this kind of interview. It's this interview format. Rather than. Someone given a. Decent chat. We can sort of summit Europe. We can. Just poking about. We've got more time to have something for that. Yeah, that would be maybe. More possibilities for as time one goes. For that one. Okay. We move on to the. Review and the PRs and the issues. Yeah. And if we have any topics that come up, we can start looking for a conference. Yeah. That'd be safe. That's a good way of doing it is, you know, people have a. Kind of a blueprint for a talk they want to give them. That's a good way of doing it. Yeah. Yeah. That sounds good. I'm sure. If we start working on the options, then we'll be able to find. Some, somewhere to talk. There's a lot of places. PR review. No. At the moment. There was one closed in the week. It's a nice way of doing it because then it's. It's ready for when a suitable conference comes around. Maybe we should do that anyway. Yeah. Couple of talk options. Yeah. That sounds good. I'm sure if. If we start working on the options, there was one closed in the week, which was. The issue template. Okay. That's cool. So now that means if you are to new issue. You kind of report vulnerability. I didn't know about. You can open a blank issue or you can create the best practice proposal. And so when we put these text boxes to be able to put in the different sections of the best practice proposal. And. Do one of those. One more. So that might help. We'll see. The issues. Let's go from the bottom up. The privilege flag. So it's included in the CNF certification as an essential test. Currently assigned to Taylor and Victor. With a milestone of this quarter. So by the end of March. Yeah. I'm going to work on that proposal. I mean. So. It's just a matter of putting all the. All the things that we have in. A PR. I'm going to. Send you a calendar invite Victor. Okay. I've been. A little unavailable for. At least half of January. So I'm just trying to catch up. I will, I'm going to send out a few and you just let me know which one works. Okay. Any reasons to bring that off hold. No, well, probably relate with the same PR. Well, any issues like. The. Effort that the committee is doing. Some of the latest things that they were discussing about. Naming. So I think that they are going to send out Torby. Based on the number of proposals. So they have narrowed down to two of them. So if you are able to vote, maybe you can choose. Your option. And they try to summarize the intent of like the goal for, for that new. Human resource. So this is 20 just maybe I object. And you're representing the. Connection on the pot. So the naming are. Yeah. Canate. K, K this net. What network. Connectivity provider. The. Service and network instance. And this is a name for an API. net is, is it representing a network to which pod can attach to this object can be referenced by other API objects, e.g. service. The idea being that a pod can have multiple attachments to different networks or different API objects of this type. If I could, but they tried to just get all the idea in one single sentence. One of the criteria to choose this name could be like in the semantics of the, for example, if you use cube cattle, like cube cattle get what network sounds like something is to understand. So yeah, I don't know. I don't know if the pool are going to be open to anyone or they're just going to tend to mainly lead. For what? The name? Yeah, for the name. Yeah. I'm not as worried about the name as if it actually has the functionality that we've been hearing and talking and complaining about for years now. Is it covering, is it covering some of the main stuff? Is network service mesh folks? Are they saying this? Good question. I think so. Yeah, I mean, I haven't been attending those calls for a while, so I'm not, I don't know if it's been a current topic. I haven't seen it when I'm just looking at the network service mesh meeting that. I find that I mentioned this to Ed. He mentioned like, what was during the last chip gun? And he was saying like, he didn't see any point to this effort. Yeah, because I think that this is one, this is not the first intent that they're trying to do. It's like offering multi network. So I'm giving that they have another way to mitigate this problem like that. He didn't see any particular bandits to keep doing all these things. But that was the opinion of that. Interesting. Okay, need to have a read through this. So one of the calls for this, Wednesday, 8am PST. I think that they are recording the meetings. They switch from Google needs to Linux measures on some meeting platform. So I don't know if probably, I don't know if that was recorded, but usually tried to record the session. Okay. Well, thank you. So that's relating to this issue, which will remain on hold for now, quite a link to non route and non route. I just need to get on with that. Some time refactor introduction final paragraph in the first section. And no one assigned to that yet. Anyone wants to work on that? Please go ahead and assign yourself and create PR. Same for these next two. Yeah. Right. So this one, one process type. So there was a bit of dispute from go okay. He hasn't followed up to the follow up. No. And now Watson is going to be talking with or plans to talk with your guy, I think this week. And yeah, I don't know if I'd put it in there, but he's going to be talking with him some, but they've been working on more write up about related items that would tie into this. And I think there's a microservice white paper that is being edited right now. So that'll have a lot more content about this. And we'd probably point to that as a reference and have further discussion. Ideally, though, if, you know, this is going to be something proposed and there's Gurgi actually even open a pull request to just remove it from the test suite as a main essential test or something. I can't remember that's outside of the working but ideally, you know, we can get gargoyle on here to go in and provide you know, here's alternatives and other stuff. I do want to like bring it on the call and this is recorded. So have it like that that we're trying to create guidelines for what we think is the best path to follow for most cases, not all cases. So the idea with any of these like the privilege flag and all these other stuff are most of the time you should try to do these things. But when there's times where you shouldn't, then that's okay. And the way that we've been writing up the best practices communicate that, including caveats that you're going to run into if you don't do this, alternatives, anything like that. So if there's a dissenting view that we think is important to highlight, then that can go right into a best practice. If we think that it's, you know, a best practice that should be followed in most cases. And this particular one is related to how you would be utilizing macro services normally, which would tie it into, I think, a lot of the best practices and cloud native practices that you would be following. That's why it's being put forward. It's tied into a lot of things. So I think we need to have more context given from any other views and then make decisions on does it go into the caveats area, options area? Does it mean that we don't want to put it forward as a best practice? There's a lot of things there. Yeah, okay. Yeah, the other thing Taylor, I don't know if you remember last time we were talking about this. And that also brought the the topic about having using what was the name container, no, process handler in the because the container requires to manage the signalling properly. That brought the concern of like doing in the right way, which was related with the topic, but not directly tied to the one process per container. So we were also talking about like, okay, let's somehow simplify the things. Let's make the best practice quite simple, but also cover a lot of similar ideas around this side of this problem. Do you remember like that particular topic about managing signouts properly? Taylor? Managing the signoffs. Yeah, yeah. Do you remember like when I was answering to the gallery? So one of the topics that I found was related to the most of the cases like, I mean, you can definitely you can manage multiple processes per container. One of the major problems is like if you are not propagating those signals to the container manager, you get a problem. So and they were suggesting some articles were suggesting to use other tools in the Docker entry point to propagate those things. I mean, it was related with the one process per container probably, but also it was another kind of best practice for that Docker container creation. So eventually we follow the similar pattern like digging more things and eventually we will proliferate in a lot of best practices with similar topics. Yeah. Well, I mean, if we probably should just start coming up with a list of those either as they can go in as issues or into the discussion forum for those ideas. One of the things that we're talking to, I think we talked about a little bit was you can have zombie processes and other stuff. And so you can start looking into process managers and there's software out there that does pretty good management. I think I may have already mentioned the like email system. So QML, I think was one of the big examples of separation of concerns implemented in processes that are running and actually isolating them under different users and stuff. So if anything was if any one of them had a problem, including like external security issues and PostFix, which was a rewrite of that by someone from IBM, those are two large mail. I think if you're into email at all as far as the systems, then most people think Sunmail. But QML and PostFix would be the ones that they actually handle a larger quantities. Like if we look at growth and they were both PostFix was designed like QML to run in different processes. And those are internal versus saying using a in it. What is your in it? Process manager and there are those as well. But you can actually build a system that does process handling. And if you look at languages like Erlang, well, it's all about having its building applications that have lots and tens of thousands of processes. It's designed for that and separation of those using some type of process manager where someone actually already knows what they're doing. And you're taking advantage of that is a good path. If you haven't already been building systems like PostFix or software, the ideal with a best practice of one process type, not multiple processes, but one process type in a container is a method of separation similar to what PostFix is doing with multiple concerns broken into processes. They're not containers, they're just processes. Or if you're running something like Erlang and you're having a lot of processes, but each little component may be split off versus saying I'm going to have one container and running using a process monitor and manager that can run everything, but you end up with lots of process types, which moves you towards it's an anti-pattern for following a microservice model. And there would be a lot of different things that you could start pointing out. But this again is more of is this the path that works for you? Like do you want to take all the benefits and do you have caveats or not? And you could definitely have a container, I don't want to say a CNF, I'm going to be more specific. You have a single container that has multiple process types and you have a very strong and valid reason for that. But is that the best practice for everybody? That's all we're saying. Like should most people follow the practice of trying to separate concerns? And that's what each process type is. I would say probably it's a different concern. It's handling something different. You may have one, I don't even want to say process type because I'm reusing that word. You may have one application running in a container that has multiple processes. That's not what this best practice is about. That's fine. It could be a single process or it could be many, many processes. It's when you have a different process type. So they're doing multiple things. And the best practice is saying when you have multiple things being handled, multiple services, multiple functionality, you're doing processing different types of things, then the recommendation is to split those and not have them in the same container. Yeah, the last thing that I was thinking is one thing is a process and that thing is the threat. I mean, definitely having multiple threats on a single application is hopefully fine. Having different process types or like different processes in general would be a kind of a bad practice. I mean, you mentioned a couple exceptions like Erlang, which is totally fine because it's part of the way that Erlang works. Erlang is hard for me to think about in Kubernetes because it's in a lot of ways and people do write Erlang and Erlang derivative applications running on Kubernetes. But what's weird for me is Erlang in a lot of ways is designed to work like Kubernetes. It is essentially Kubernetes. It has its own system for handling restarts and monitoring and a lot of the stuff that Kubernetes does as a framework and core applications in Kubernetes to help other applications that you write to work well and you don't have to think about those things. Erlang plus the standard library in Erlang is how they look at it. That core is designed the same way. But it's also designed to run tens of thousands of processes when you're building an application. And it's designed to split them all up. But Kubernetes is designed to where you would build lots of containers and they work together. I'm running a Kubernetes cluster and I have three big applications that are five gigs apiece with massive datasets. That's an unusual case for Kubernetes. Most of the time you're talking about thousands or tens of thousands of containers running on a cluster. And with Erlang it feels a little weirder to split it out. I mainly brought it up as an example of that particular programming language. If you're building a container it feels a little weird to split an Erlang container out. So if you had an Erlang telecom application and you're trying to run it on Kubernetes, I can see how splitting different process types into different containers doesn't make as much sense because you're actually not taking advantage of Erlang. Like the actual system was designed to have really high-speed connectivity between essentially its own little mini containers, what would be running on the Erlang VM. But I would count Erlang as a very small subset of applications that are targeting Kubernetes. As far as I know I'm not hearing about a lot of telecoms that are going, hey, we're trying or having trouble. I like the language but I think for most languages that's not the case. Including Java, C++, besides messaging language that I can think of right now. That's not an issue. I'm just conscious of time. I've got to jump to my next call I'm afraid. I think that's been quite interesting news for discussion. I know it's hard if we can summarize some of that in the issue. I think it will help whoever comes to write that. I know we're running over time but I just want to, it's a comment I think we can address next time around on that specific. I think we're talking about, Taylor, you're talking about it being in some cases, there may be reasons for not doing this. In other words, you're saying this doesn't necessarily apply to everyone. There are caveats, et cetera. The only thing I think that we need to address somewhere and all that is I think people think about the certifications and things like that. If it's an essential test and you don't do this, then you lower your chances perhaps of being able to certify. I think that needs to just be addressed some way. Ultimately, we don't want to turn people away. If you have a good reason for doing it, go ahead and do that. You may not be awarded a certification if that's something you're trying to do. Anyway, I just put that out there for us to get to. Right now that's not an issue because it's not a you must pass 100%. I know. I know. I know. One that someone doesn't pass, that doesn't mean they don't get certified. If it turns out that we have a large set of things that we're all recommending, these are essential and then we have the majority of people not being able to get certified. We can think about what does that mean? Ideally, folks are getting helped and they're becoming more cloud native. That's the point and the long run. I'm wanting people to do these things because I literally think that it's going to be beneficial. Add any comments or notes. We can continue next time. Yeah. Thank you. Ideas for talks. Just reach out. Thanks, everyone. Thank you. Bye bye.