Add a meeting Rate this page

A

Hello, everyone. I just dropped the meeting notes in the chat. If you want to add your name there we'll get started in a couple minutes to give people a little bit more time to.

A

Join.

A

I will get started at five after.

A

Meeting, oh, I see bill, you just dropped the meeting at the same time, hi bill um meeting notes are in zoom chat. You can add your name and any topic that you'd.

A

Like.

B

Thanks for anyone, that's joining right now, um there's a link to the meeting minutes uh in the chat. Please feel free to add your name there and then we'll get started in about two minutes.

B

Here.

C

Okay, uh thanks everybody for joining today.

C

This is the cnf working group uh weekly meeting uh thanks for joining um things that we'll be going over today um is the the process and the structure for ideas to become adopted, best practices and kind of jump into some of the issues that we have, and so the re I guess before we jump in, is there anything anyone else wants to add to the.

C

Agenda.

C

Okay- and maybe this is sorry- this is ruben speaking um quick question, so the goal is really to discuss how to turn lots of the discussions we had into something more actionable right, yeah, that's correct and then that feeds for me.

C

Yeah, so I guess um reuben to jump right off of your comment is, I think, uh what a lot of people have been seeing is that there's been a lot of conversations flying around both in this meeting uh on the slack channel in various different ways, but um it's been a little bit hard to make them actionable um in terms of how we want to move forwards with them um into kind of like proposals for best practices.

C

um So we do have the uh like. The best practices like like temp or like proposal template, but uh as so far um no one has really like opened that uh open that up, and so what we're thinking of the actual process is kind of like providing like a smoother onboarding, um with first kicking off um discussions here in the cnf working group discussions board, and we can actually see a couple different.

D

Like topics on here and so best practice like cnf, should not rely on local persistent.

B

Storage for data retention best practice keep application configuration outside of the image.

B

We've also had a couple different discussions around like defining the telecom actors, and so the idea here would be that, first to start the discussion in a more informal way around a best practice is, we would start start a discussion thread, and what this would allow us to do is to basically.

C

Have a.

B

Written.

C

Way of.

B

To.

C

Look at the different best practices that we have, rather than someone to have, having a complete idea formed, and what this allows us to do is to kind of iterate on the idea before we need to come up with a more formal proposal, and so uh in this way, uh all the ideas around a certain best practice can be kind of contained in one place, and once kind of the group thinks that there's enough information and discussion around uh a certain best practice, then a more formal proposal um can be made.

C

So if you think about it, uh kind of like the the proposed process right now would be first um like either. Would.

E

Be starting something on this discussion board, creating discussion discussing it in this meeting, um generating enough ideas and interests, and then the next step would be actually defining a actual proposal and in this way, instead of having a whole bunch of conversations in slack that you'd have to search through each best practice kind of has something behind it.

E

So and then, obviously the final part would be reviewing and adopting the best practices so kind of. With that in mind, what do people think of this newer kind of like less formal process.

E

Or taylor, do you want to jump in? Oh um they just to add a little bit to it.

E

So the I don't know that every every topic in here is going to become best practice, especially um ones that are meant to be um like defining the telecom actors, so any anything that we're discussing where it's going back and forth, and we keep asking let's try to get it in, so that everyone is getting those um seeing the conversations whether those are on the meetings or in slack it's fine to keep having them, of course, any any area, but try to capture something so that we can have that shared understanding and that one of the main reasons to get it in here, besides making sure that everyone can see it is to make the hurdle for.

E

I guess, sharing the ideas. um Broader is the formal adding of proposal may feel like you, don't want to do it yet because you don't have all the information so to lower that hurdle. For that, and, of course, if anyone sees something that they feel like there's enough content, I think that we can put something forward. We have all the references, we have the use cases we have all the stuff that we feel is necessary to communicate that this is a best practice that we want to put forward then open a pr.

E

um You could do. A pr initiate put it forward. We'll still have discussions just because it comes out of here doesn't mean it'll, stop it's just lowering the bar so that we have a shared area.

E

Hey taylor bill, hey joe hey, so one thing I would like and it's going to be contentious and rough, but I think it's necessary before we start defining best practices. Is we put in our charter that one of the things that this group would do would put forth our definition of what a cnf is? um I think that's really important.

E

I know I've talked to you a little bit about this taylor, but I'd like to you know, put it in front of the group is if we don't have a definition for what we're you know, proposing best practices for there's a lot of ambiguity that can get us into trouble. um For instance, like you know, there's best practices around the amount of privilege that a container gets and we could get into specific. You know nuanced discussions.

A

Around least privilege and the container having exactly how much for a budget needs, but we talk about like these kind of, like you know, least privileged. You know blanket statements um if we don't know like whether or not the.

E

Orchestration for say, um the infrastructure comes along with the cnf itself. If we don't say that you know those are two separate things and some cnf developers put their orchestration pieces in with the cnf and bundle it all together. Some don't.

F

We get into this weird thing where we say it's a best practice to not have um you know privileged containers and then all of a sudden we're in a scenario where we have a container. That's you know an orchestration platform. That's been quote unquote, labeled as cnf, because it was you know just bundled that way, and it's now you know breaking a best practice, because it's provisioning block storage for me or something right like so I I think we need to make sure that we a define.

E

You know what we're saying this is a best practice, for you know. Is it a single container? Is it a collection of micro services like everybody has a different opinion, but it would be nice if the cnn cncf gave us like a this is what we think it is and then from there we can provide context in these best practices to the type of workload that the best practice applies to, because I mean obviously there's going to be times where you want a container to do certain things or you can just make it.

E

You know black and white by saying this is for the cnc. This is for a cnf and we've excluded these types of containers from a cnf and then therefore you're not breaking something with the best practice like you know, we're calling this an orchestration container or.

E

Something that sounds good um jeff. I think that there was something that you talked about last week um in chat about exceptions to so that.

B

Contest so this would be tynan with what context do we need to know about a best practice so that you know how it applies and it seems like that would be related yeah well, so yeah context how it applies, and then I mention exception and then I'll. Let ian speak to it, because ian was actually talking about like a formal process he's used in the past. But the big thing is right: ism we don't want something to instantly be disqualified. If it's a really good idea, because it breaks the current best practice and maybe.

G

That best practice wasn't exactly supposed to fit to what that specific container was trying to do so, um but yeah exceptions in context. I think, are super important, um because if not, we end up with these really broad brush strokes that either limit what we can do, or it leaves things so open to interpretation that you know we could both be quote-unquote following a best practice and have completely you know, polar opposite results.

G

So I mean, when I did this in well, it wasn't say it was safety, mitigating which is a little bit of a um a get out clause for the the companies I was working for, but safety, mitigating software, then.

C

What you would tend to do is you would have, if I put it in the words we're using here, you'd have a set of best practices and then you'd have a baseline of these are the best practices I'm applying in this particular circumstance, for whatever reason, not necessarily all of them, and it meant also that you could potentially have conflicting best practices.

C

Something was a best practice in the circumstance, but not generally, which meant that you, you complied to a baseline, which would be some subset of your best practices or maybe a bit of context about how they were applied, um which meant that you didn't have to get it right.

C

Well, among other things, for us, it would mean we could evolve over the course of time. The best practice list would not be a list that we couldn't change because it was already in use. We could come up with a v2 or a context-specific list for certain types of application or certain circumstances, and I'm thinking about this, um because you know it's nice to think here- we're in a relatively academic environment where we're talking about stuff that doesn't change the world um or, alternatively, the world will just naturally comply to it.

C

Whichever way you want to look at this.

G

But we know that.

C

What's going to happen.

G

Here is that whatever we write down ultimately somebody's going to throw at me or another vendor as an rfp and I'd like to ensure that effectively it doesn't stop us doing the best job. We can do because there's an awkward bit in it that just.

C

Turns out to have been not a good choice in in practice, um this seems like the way to make sure we could potentially evolve.

G

So that the bits that become you know that turn out to be practically difficult.

C

Or not as valuable as they look like, we can throw away over the.

E

Course of time, so the idea that we have best practices and also we make a baseline that says these are the best practices that get you to. You know um a 2020 gold standard cnf.

E

If we keep those two things independent of each other, we'll get, I think a little bit.

E

Further.

E

Which can also be read as saying you know if you've got a best practice that you think is um you know the best we can do today as opposed to the best we might ever do or, alternatively, a best practices that doesn't apply in every circumstance all the time.

E

That's still not an excuse not to write it down. You should write it down and put it in and we will find the moment to apply it and if it turns out it gets outdated. We will have a means of of saying. Actually it turns out. We won't be doing that long term. After all, so get more ideas in there and we can choose our baseline. It's not. We haven't written something in stone in such that it can never. It can never be altered.

E

So you know I'm just trying to capture what you said.

G

Either that's a horrified silence for everybody else, or you all think, I'm absolutely genius and you're speechless. I don't know which of the two anyone care to comment.

E

I was wondering whether you could recommend, because I think we just have to start and do it so my question would be or whether it is whether there's any any recommendation to start codifying this. This basically coming, on the one hand, from the definition of the cnf and, on the other end from codifying how to come with best practice and probably we'll end up.

G

Meeting in the middle, without chopping off our respective ads too much yeah, I I think um I mean uh taylor put something up which I I did like um the definition of audiences, which is context, and we definitely want to get that context written down, because best practices relate to context. You can't have a best practice if you don't know what it's a best practice for, so we we have to approach this from both directions.

E

At the same time, and then that baseline will be saying.

G

You know for our understanding.

E

Of context.

G

For this list of.

E

Best practices, we recommend these ones right now, um so so effectively, three tracks, one is the the context behind the.

G

Cnf, how it's going to be used who's using it, what matters to them and what audiences we have one is.

D

A.

G

Set of best practices that are probably more related to the software engineering practices of working with cloud native applications and using containers to implement them and then the baseline that we'll eventually put together, which is going to be the standard we release and and out to everybody and say you should be compliant to this.

G

As far as where to start or where to focus, um my view is wherever you have um wherever you're reading something and it seems to affect you is probably or whatever interesting, so we don't have to stop start with any specific ones. um I some of these, like this uh actors, is gonna affect everybody, but so please at least review it, but talking about uh what a cnf is, but maybe we should start with what a cnf does before we talk about how it looks like how it's supposed to behave.

G

What are the best practices around it? What does the cnf do?

G

What qualifies as a cnf in the end, without putting in a definition for for the world, but what qualifies as a cnf in our view- and maybe we can- we can start from that because, once you know what it's supposed to do, you can start working towards how I think that was christian bill and I agree like I think that ties into the um the uh the requirements thing right like what do we need is like not just what does a cnf do, but what.

D

Do we.

G

Want it to do right like why am I sticking this in my network? Why am I move because.

E

What I don't want to hear is that a cnf is a vnf that follows cloud native principles like, and I've heard that you know spoken as canon more times than I can count, but, like you know, christian hit the nail on the head, like you know, we keep coming like. Why are we doing this, and I mean we all know what we have to make this cloud native transformation. So, like we get into the whole motivation discussions, I mean it's coming. Vendors are making it this way. Service providers are deploying it.

E

This way like it's just whether it's a chicken or any scenario what's happening so like we need to start identifying like our um our requirements on like how and why we're doing stuff right like what is this cnf supposed to provide us? You know from a developer standpoint from an operator standpoint, all those people that are in the actors page like we all collectively are saying this is the path we're going.

G

And like he, he said what does the cnf do and then from there we can start describing you know what it is.

D

Network.

G

Here, can we summarize it as cnf moves packets around from a to b? Would that qualify? As a very I don't know, 10 000 foot view of cnf.

E

What, if.

G

It's not in the data.

E

Plane, though, what, if.

G

It's like a control plane or a management plane portion of it and it doesn't move packets.

B

So how do we qualify that I don't know, but I'm just playing devil's advocate? Well, that's why I asked the question- and I was just reading through the monster discussion that that and shane were having on the subject of you know the fantasy that I I think we all subscribe to. We all wish we were there is I get my cnf from whoever's supplying it, whether it's a vendor or it's another team in my organization it really doesn't matter. The point is it's an independent unit?

B

That's not me, um and I want to get it on my network in 24 hours. How am I going to do that? um The practical problem that you've got there is that you're integrating it in a wider system, and you would like to make sure effectively all of its interfaces work. The way they're supposed to do all of those touch points actually meet with the expectations of the thing, that's consuming them and then you'd like to put it through its paces as much as you possibly can.

B

So it's got to effectively be easy to test, which means it's got to be in turn easy to deploy easy to upgrade this sort of thing. um It seems to me that the the way to determine what requirements exist is to actually put this in the context of problems like that. This is the thing that I would very much like to do, and I'm assuming that, even if I don't get to you, know a 24-hour deployment cycle or a two-minute deployment.

E

Cycle, whatever it happens to be then at least traveling. That journey will give me something that continually gets better. um So what is going to help me on that journey, and then you get to a definition of what I'm looking for from a cnf and then you get to best practices in the cnn, but doesn't that differ from one type of application to another I mean in the end. Why would you want to put a minor change in your network or a new application? Your network in 24 hours, maybe yeah fine, but 24 hours, one.

E

Second, the point is fast right. I have a critical security update. I want it on my network and I don't want my network to be less stable as a result.

H

um That is effectively your aim. Isn't it I mean? Is there any case where that's not true? Well, you do that in basically, when you say 24 hours for an application that I want to batch that's lifetime.

H

If I want a new application that I have no idea what it is- and I want to put it in my network in 24 hours, then I do have a problem. But if I want to patch something there's two different workflows here, one is patching so rolling out an upgrade in 24 hours, which is fine. I think we're beyond that and we should target for a lot less, but fine with the 20.. They don't get tied up with the number. The number was just yeah yeah, I'm just the important.

H

The important thing about the number is it's less than three months, which is not an unusual length of time for a physical device, so I'm just picking an umbrella in it here. That's all, of course, the what I'm the point I'm making is the there's two different workflows. One is patching, which is driven by some considerations like security, like compliance like bug, fixes and the other is new deployments.

H

So when you do have a patcher you're kind of assuming that you have that application in production already and you're figuring out qualification mechanisms and upgrade mechanisms. That should pretty much be allowing you to do this in line in place without any sort of service interruption or minor service interruptions, and the questions are around. How do I qualify this against my previous baseline? What do I need to test and what ensures that I?

H

I can move forward in the steps and what are the checks uh between various canaries that I'm going to do until I reach a full full out rollout and then, if.

D

For.

H

Some reason that fails somewhere in the intermediate steps: how do I roll back and how do I ensure that everything rolls back cleanly now when you're talking about a new application? That's a completely different workflow, because you have to understand how that application integrates into the wider ecosystem and that study and the definition of those I was just looking over one of the discussions and one of those is around dependencies dependencies.

H

You don't have to worry about them or you have to worry about them in a different way when you handle an upgrade, whereas you have to worry about them in a completely different way. You, when you have to instantiate something new in one place, you want to ensure that you act on the components in accordance with that dependency, so that you don't break the dependency chain, and you end up at some point causing a service outage in the other. You want to identify what are the dependencies who's going to?

H

What am I going to consume with this cnf and what am I going to provide with that cnf?

H

So the two workflows are, in my mind at least, are radically different. I don't know whether they're radically different, because you've got to be at the end of the first, with the workflow you're talking about when you've eventually worked out how to deploy it. For the first time, you've got to be certain that you're ready for that. Second workflow, that the the the short duration upgrade. Of course you you've got to you know it's not just about getting the application running in your network.

H

It's about understanding that there's going to be another copy of this application turns up. You know next wednesday, and I'm going to want that in my network as well. So at the end of the first process, you're going to have to be prepared to start from the second, so it's not perhaps I'm we're not comparing light with like they will absolutely be different, but the first one has to end at a point where you're prepared to start the second one at any moment. So, okay yeah.

H

We want to tackle both uh at this stage or should we pick one like? Let's pick the sip into it? Let's pick the one that we start with, so if we model that and understand it, and then we move on to the second one, which obviously has slightly different behaviors and maybe we'll understand something else after we modeled the first one. That was the original point yeah.

H

No, I see where he is airflow, or should we look at the instantiation workflow first, um my rather than saying here is a specific workflow and you must follow it. um I think what you're talking about the needs behind those workflows is more important because we're not saying we're going to copy over. What's there and add to it, what we're looking at is, if you have something like we need to get a security patch out, then what are the best practices so on the life cycle, management or.

B

You already have something out a application running. You need to get a security patch out. So what are best practices that help with that that one goal. So that's one thing that you want. You have something else where you say a misbehaving app is running and we don't know what the problem is. So what are best practices that help you observe and get information about that application, best practices on kubernetes, so yeah? Those are the underlying concerns, so whatever level you're at a new deployment, a running deployment, a rollback all of these things.

B

What are those underlying needs? And now we can start looking at what are best practices that already exist in kubernetes that are applicable or ones that we should invent because we need them. But all I would say is there isn't necessarily anything stopping us from writing both of those together, but but what you're saying is that what I write in one is necessarily going to have some effect on the other. I don't think that stops us making the attempt simultaneously.

B

We just have to understand that the the first try at this you know there's going to be a revision process. It's going to take some time to get to a place that we like, um but we could write both of those up um and it's what I was saying earlier. This is these things individually. These are not best practice. These are context effectively. These are the things we would like to do. This is the context that will determine what best practices matter to us so so looks like we seem to be going all over.

B

I thought jeff started the discussion with the c and f. What is the cnf, and now we are. We are going into all kind of workflows and and the best practices for for workflows and whatnot and and we completely drifted away from what a cnf is and and the the point which I wanted to make for a while ago. As soon as jeff started discussing that was taylor during the tug time, then do you define uh or did didn't?

B

We define uh those cnfs where we call them bronze, silver and gold and whatnot, and there was an attempt made that where what were these cnfs are, what do they look like? What do they have? At least at least an attempt was made there. So where are we not picking up from there? Why we're trying to reinvent uh all over again?

B

uh There was I mean so people still will I mean I. I sit into a lot of meetings and I hear people argue about it all the times that guys vnfs are not going away. They are here they're, going to stay here, they're going to stay here for a very long time and and the vendors need to see an incentive to throw away their vnf implementations and and start getting into cnf implementation with not even knowing what a cnf implementation looks like.

B

If I, if I get into a room, I bet you right now we have a.

G

40 people or 30 people, whoever we have on the call. If I asked you know that what is the cloud native and and we're not going to get one answer, we're going to get at least 20 answers so and I do that all the times. So why are we? Why are we not starting with there, and I thought tug was doing that drugs started to do that, especially when they got into gold cnfs, you know. So there were bronze, there were silvers, but the gold cnf gold cnf is pretty darn close.

E

To what we are trying to look here, for what is cnf should be so so why why don't.

G

We start with that and then and then at the top of the hour, when.

B

Jeff started he started with with cnf, and now I I think, we've gone to security patch installing and we've gone into upgrades of workflow. So what? What is the goal of this group? What what are we? What best practices?

B

Are we at the end of the day we can meet every week and we can talk all kinds of different things and we can even do whatever we want to talk, but at the end of the day we have to set up some kind of a goal that what we want to achieve so that we can set up some time frame like by by q1 end of q1.

B

We want to be able to achieve this and by end of q2 like robbie, is on this call who was leading cnpt and the only reason we made tremendous progress. There was that he will step up and he will start setting up the goals. He will say: okay, guys, let's define this release, let's define this content, let's go with this and and work with that.

B

So so here my suggestion is: we should take some kind of a similar approach right and- and let's start writing it down- let's start defining it, but then then we take it as as it comes, rather than because everybody seems to be wishy-washy, everybody seems to be going all over depending upon what our personal preferences are. Whatever backgrounds are, where we come from right, so so there's a lot of bias based upon what what we have been exposed to what we've been using to.

B

But but there are certain things which are in front of us, so whether we pick what is available and then start to work from there and my suggestion is, uh there are write-ups on on what what gold cnfs are. Let's.

C

Take a look.

B

At it, let's review.

C

It do we agree. Do we not agree? You know if we don't agree, why we don't agree, let's fix it, let's call it as a cnf and then then yeah um we've communicated on the goals. Just to I, I agree on the tag side. We've done a lot of discussions about all of this. There's a lot of information.

C

Jeffrey's posted something there. That's now um that's what's used in the text, so that's kind of the starting point for all of this: the principles to go with what you were saying as before.

C

Yes, there's a lot of people, that'll say a lot of different things, but if you go and look at the I'll say the experts in the field, whether you're saying specifically cloud native, whether you're going into kubernetes usage, whether you're going to stuff that builds into cloud native, a devops and wherever you want to look, there's a lot of content that go right into what the principles are about. It happens that cncf doesn't have those expanded out directly in their definition, but it doesn't mean that the experts that put forward these haven't said a lot.

C

So this is a good place to start. If we want to look at some of these things, but I don't think jeffrey was specifically looking to say: do we have any idea, it was more of. Are the best practices that we're putting forward going to be applicable? Are we going to cause problems? So it's it's a more specific thing and then, as far.

B

As the goal of the group we've we've kind of communicated this again and again, it's in the scope for the charter, we're looking to determine what are these best practices that are going to allow.

C

The telco applications to most efficiently.

A

Use kubernetes and they they have. Why are we doing this? We want to lower um at opex, primarily, I would say, but it probably affects capex. We were talking about life cycle management, so.

C

How are we going to lower the opex cost, whether that's reducing risk, whether that's making it easy to manage changes on the network, because you push more stuff out to the infrastructure that already is handling some of those things. So, if you're building a an application that you're selling to sp, you know that you're focused on the part that matters the most, that you have the expertise on and you're not having to do additional work outside.

C

So it's it's all around those same things as far as the reasons, but the goal that shared goal of how to best utilize kubernetes the framework, the community. So outside of you know just our group. How do we bring more and more in that already have the knowledge on running these applications? Financial.

E

They do lots of security, they care about it, high-speed transactions. So what can we get that they're already using.

E

So, in effect, the goal is identify best practices. You just summed it up: it's not defining what the cnf is, but we kind of settled the cnf is what was defined in the thug, and the goal of this group is just to identify best practices.

E

I think this is something that we kind of went all around the place before, but that's fine. If that is a goal, then yeah we can focus on that. Where is very clear stated, that is: where is the tug's definition of what a cnf is and how extensive is it.

E

I think it's uh right there in uh what jeff put.

C

um So yeah, I think, to both uh christian and anne um the what the reason why we're bringing up cnf's uh a what is a cnf or what are the goals of cnf for all of these things or because we need context the same same as everything else we're talking about during this call for why a best practice would be put forward it at all.

C

How does this affect me? Is it going to cost me problems? Is it going to benefit me? So it's all context, so we do need the definition and probably it's pointing at it. So in I can't right now.

D

Drop.

C

A link in that says here is the tug definition, which is a problem. We should.

G

Make sure that that's very easy to find on the tug and any type of context and content around it?

G

We have all of that so that'll be something that I'd like to put on at least my plate, and if anyone wants help to look at and then we can do the same thing from the cnf working group where we go here is what we're referencing, um along with what jeff is saying, but what we probably don't have anywhere else is some of the context that jeff was worried about where we put a best practice forward and it doesn't apply to a cnf, that's very common, so we have something out there we put the best practice.

G

It only causes problems if you use that best practice on the cnf. So how do we communicate that that it's not either not applicable to this one? You shouldn't use it wherever. However, we deal with that, that's I believe jeff. The main thing that you're wanting to put forward on this is it's you. You got it spot on so.

E

I just confirmed my own fears. um I did not speak with enough specificity with my initial discussion thing and so then um lots of room for interpretation which muck things up um you're dead on taylor is like would a cnf, that's specifically targeting layer, 2 and potentially, you know interacting.

G

At like the nick layer, gonna have the same best practices as maybe one operating at layer. Three, and is you know, looking at route tables, etc. um I don't know the answer to that right now, just hypothetical right!

G

So like it's exactly what you said is um you know, do we expand upon it and um ensure that we we just give like the proper context for when we say a best practice of like this applies to this type of workload, because it's going to give you the optimal results based on what this specific you know, container function whatever it is trying to accomplish, and then, if we need to expand definition, um we can you know if we need to contract it whatever, but like the big thing is, if I just say no, no root, you know privilege in any containers.

G

Well, is that always the best practice it might be that the case is it is? It might be the case that it isn't, and I just want to make sure that I'm hoping that this is a little bit more lower layer than like the more abstract stuff. Where.

B

It's like here's, a reference architecture, you know, here's a white paper like my hope is, is when I come from this group. I have things in my toolkit that I can actually go, and you know pun fully intended put into practice versus you know just abstract concepts that I'm like. Okay, you know these are great guidelines that I'm going to follow like follow at like a broad.

G

Level.

G

Actionable.

B

Versus.

G

um Just thought something to think about: do you have something concrete or is it abstract, yeah exactly.

G

So, if we're looking at an example.

I

Like.

G

Specifically, is this: is this like the type of content.

E

That you're, looking for, like cnf's container, should run on privileged absolutely right and once again, though, it has to have the context, because ian's concerns are valid. I'm going to put this in an rfp, you know: are these containers unprivileged or are they going to try to mess with my um my infrastructure?

E

Are they going to try to talk to the kernel and do things that I might not want to do? If we have the context, then I would try to tailor that rfp to make sure that once again we're following a lease privilege model versus a no privilege model, but um you know this is something I can test too like I can go in and then I can try to like go into one of these containers and try to execute system commands that I shouldn't be able to do. I can test this.

E

I can put it in an rfp and then I come away with. You know a slightly more warm and fuzzy that if I deploy this container, I don't have to worry about it going in and doing things that, maybe I don't want it doing in my infrastructure. So I do think that you know discussion. Number 25 here is a.

G

Great example of the type of thing I personally and maybe not everybody feels this way is trying to get out of um this endeavor.

G

Another thing again that you can, we may be able to steal from my past life is um when we were doing compliance in those days, then um there were a set of rules largely around right software that you know doesn't break in horrendous ways and kill people, and there were a set of exceptions. You could because no.

E

One's assuming that a rule applies.

G

Blanket.

E

Across the board perfectly, you could absolutely write a set of exceptions.

D

But there was a.

E

Formal process for writing the exception down explaining the exception and supplying it along with the application. You were shipping and yeah. It's a get out clause. It basically says I can be compliant without being compliant, but on the other hand, if we had a best practice along the lines of this is how you document why you're not following a rule, in certain circumstances, how to identify that how to demonstrate it's constrained and so on and so forth, and that also might work for us.

E

Because christian right there on the screen, put in an example of a perfect idea where, like, if I'm you know- and this gets into the whole other best practices on the dev side might come out of like do I compartmentalize so there's not one giant homunculus container. That has all these things, because it's doing like layers, one and two stuff, it's doing layer three stuff, but you know he puts like thing like. If we decide we're gonna go down an srov path, I spin up a new container.

E

It's going to have, to you, know, be able to interface with the system and pull that vfid into it, etc. Right so um that's christian, put like a great example, the types of stuff I'm just curious and like 99 of the time it's going to be applicable, but here's an example of where it's not so. We document it as an exception and we provide the context of what it is a best practice.

E

Another thing that, for me personally is a pain point is the dependencies I think just started.

D

This discussion.

E

Of more, um it was uh started from a thread in slack, but one of the biggest issues I have when looking at the cnf or vnf is what are his dependencies. Who does? Who needs to talk to this cnf.

G

Who needs to consume it? What happens if it doesn't? How do I ensure that its dependencies are before I started today? We use a very wacky.

D

Workaround.

G

Using stack on it is from openstack, and that kind of I mean most of the time that works.

D

But.

G

When you're starting to look at layer, two vnf's that falls apart because it's not able to probe layer2 so can we think of some sort of a generic interface? Is anyone else facing this dependency problem, and is it a real problem, or is it just something that I have.

G

Can I pull up out that word dependency for a second? Are we talking about system interfaces that yours that all cnfs must consume, as in that there's a common dependency? Are we just talking about a relationship.

D

Between.

G

Two cnfs or something like that. My idea here is more around relationships, not interfaces to the system, but when you have two three five cnfs on the same kubernetes cluster: how do they uh do they know about each other? How can we do maintenance on one while not impacting the other? How can we suspend one's operations or how can we, uh let's take an example.

D

From the.

G

Real-Life world, um if my upstream link is down, I want to ensure that I put the ports on the switch down so that I immediately take the entire data.

E

Path offline, so that my applications can fail over to the active one. Can we do something similar for cnfs? Can we inform one that its dependency went away so that shuts down and commits uh shifts over to its standby christian? Are you talking about a I'm gonna call it a product. um A vendor sends a specific type.

G

Of application to handle things, it may have many different components and parts, and they all need to work together. It's more about multi-vendor. Let's say I have one component from one vendor another component from another vendor and the upstream component needs to inform the downstream one all right do that in a generic way, so that, yes, I want to swap vendors from both upstream and downstream, and not have to worry about the fact that I'm going to need this interdependency to work and those vendors need to be certified. This comes down to. Can I.

I

Do my qualification in 24 hours or not? If I know vendors respect that interface, then it's easier. So if you yeah and you've hit the nail on the head here, it's not about the two pieces of code. It's about. Do they respect the interface. So you would you know I'll use bgp as a fairly traditional example. Here in theory, if not in practice, every bgp speaker, you can pull off the shelf will talk to any other bgp speaker. You can pull off the shelf.

A

And you're already 95 confident, that's true, because they both talk bgp and you can check that they're compliant with the standard before you even get them to talk to each other, and what you're talking about here is kind of the same thing.

A

You want certain link up down behavior um from a cnf, and it doesn't matter. What's on the other side of that link, whether it's another cnf or your switch or anything else, the behavior is something you can.

I

Document it's the way. It must respect that interface, so we have something a bit more generic. So not, let's forget the network world but say my control plane goes down and I can no longer manage my data plane.

I

I want the whole thing to to go down so that if the control plane has a bgp session with an upstream data center gateway, it can fail over somewhere else or if the downstream has basically, let's think about this in a more abstract way than just bgp for sure bgp can solve as 95 percent.

I

I I was using it as an example. I I wasn't absolutely I I mean I know what you're thinking that you could play with roots. That's not my point. That's not the point I was making. I was saying that bgp is a defined protocol so, rather than defining um anything else, what I'm actually defining is the place where these two potentially huge pieces of code touch and because they touch in a very small area. You know the the protocol that is bgp.

I

Then you can document the protocol and you can be almost certain before you've ever brought them together on the same system that they're going to work together because they both respect bgp, and you can demonstrate that um I can do this with apis the same way. Theoretically, I'm struggling to think of a fine example of an api, but the idea would be. There is an api definition for a.

B

All right, let me take a weird example, but it will do for now right, um kron. um There are many implementations of cron out there, but I don't have to know the details of each implementation because ultimately they respect the same cli. I use them in exactly the same way so, regardless of which quantum crown implementation I happen to be running on my box. It will do the same job if I tell it to do the same thing.

B

So all I have to document is how I use it: no, not what it's doing behind the scenes, and so theoretically, if I write script, that programs, chrome and I implement, and I install whichever version of cron, I personally favor on my box. I know these things are 95 likely to work together because the api definition, the interface, is what I've written down.

B

um So in your case, you're saying, are there some generic interfaces? uh I know interface is a loaded term in networking, but you know what I'm saying here: are there generic interfaces? I could write down where specific kinds of touch point could be documented. I had in mind something a bit more uh id side, um namely juju from canonical, which has uh providers and the consumer's kind of interface.

B

So it's a declarative way of saying: myvnf provides load, balancing services and my web server is a consumer of load balancing services. If I type those two together, I know that the load balancer will load balance traffic coming into my web server. A perfect example of this of a proper implementation is the ingress controller. I know it's crappy, everyone hates it and I'm streaming and wants to rewrite the ingress interface, but it actually does what uh what it's supposed to it says.

B

The ingress controller provides this kind of service and I'm the consumer of the ingress. For sure. One of the issues of the ingress controller today is. I cannot tell, from the ingress controller, to the back end that the ingress controller is down, so the back end has no way of knowing it's no longer a signaling traffic, except for observing the fact that it's no longer receiving traffic.

B

But it's a it's going along those lines of declarative dependencies where I have one component offering a service and another component saying I'm going to consume that service yeah, it's a contract between the two, exactly it's a contract, that's where I was trying to get. We need to define this kind, or at least in my mind. I think we need those uh kind of contracts and as a community, we need to agree on those kind of contracts, so they can be honored by um different vendors yeah.

B

I think there are a few other really boring contracts that we need to remember as we're doing this. The one that keeps coming up with me with my lot is logging right. I I know I absolutely am 100 certain that, whatever application, I wrote, whether it's a cnf or anything else, it's going to spew logs at something and something's going to want to pick them up. There needs to be a contract between the two. So that way I send logs and the way it receives logs.

B

We both agree on how that's going to work, but it's still a contract yeah. That's that's a perfect clever example of logging is really painful. Today, we in my case I have two types of logs: basically bond structures, logs and json, structured logs and figuring out, which goes where and telling a log collector. This is json structure. This is not easily painful. Today. My log collector really needs to parse line by line figure out if it's proper json try to interpret the json.

B

Otherwise it falls back to just sending the message unparsed, and this takes enormous cpu cycles. When you're dealing with text.

A

So um just a question: would it make sense to start thinking about the table of contents that need to be created for the artifacts, regenerating.

I

I mean this discussion are, are great, I think if we try to convert.

A

Them into per request, instead of just discussions, I might be better focusing on the attention effort into making something more tangible. So is there any type of content being created to define how the structure of the release will look like.

A

So the thing that we have right now is these proposal like definitions, and so this is similar to like a kubernetes cup where, like each one, would define like a best practice, and so we were just thinking of serially numbering them. But if you think there's like groupings or something else that we could have um feel free to open a pull request, robbie was there a specific idea that you had?

A

I mean I was thinking like to work backward from the delivery that I would like to make now, if we say we're, gonna release something as part of the outcome of this working group. What does that look like? Is there a document with a certain structure, different sections, and if we say okay, if this is the overall.

E

Definition of what we're going to deliver, I think going back to this question. We had in the slack channel and last time call we decided to look at the guidelines and best practices for the cnf developer himself. I think if we just focus on that and think about what would the content be? Look like and start to put some real content in. We will be able to identify the relationship with other parts of the platform or trying to think about what other areas we need to work on next.

E

My worry is these discussions are great, but I want to be very clear and blunt here I mean those discussions does not really lead into tangible outcome of something. That's. You can actually refer to and point that I think it all starts in my mind.

E

If we create that structure and document structure with the different chapters sections whatever it is, then people can work in particular section particular area, even if they can have an off call or something that for those who want to sit to work more into the technicality of that part, it would be more like tangible uh outcome that we can lead to robbie. That's great. uh We didn't um go into all of that earlier.

E

I guess when we're talking about structure, what's next beyond the process to get to a list of best practices, but what you're saying is is needed, so if we determine a set of best practices that are helping to most efficiently use kubernetes like what, where is that? What does that mean? So one part is what bill is saying is similar to keps, so this enhancement proposal, but the other part may be more similar to the kubernetes conformance program.

E

So if you go and look at any new release where they say here is the version of kubernetes and what tests are required for conformance, it's not only tests, but you actually have the test and why they were there. So why is that feature part of kubernetes? That's not immediately apparent. If you just look at the test, you'll have to dig in, but that's a similar thing here.

E

So if we end up with a set of best practices that you can go and look at in this folder, we'll probably have something similar to what the kubernetes conformance, which is a large document which lists all of the tests that are required. And then you can click through and go look at what those features are for us. It's probably going to be here's a list of best practices in a document and some maybe a subset of information.

E

So you can quickly see here are the ones that we're recommending that people use and the audience and and just a small blurb about why it's good click here to go read in details about this best practice. That would be similar in my mind, also to 12 factor apps. So now we're just helping people do better. But beyond that, how are we trying to beyond a document like that which I do think is good 12 factor?

E

If you go look at whether you're looking at 12 factor, you have a list, you can go dive in deeper and so on beyond. That is the test suite, so the test suite is currently developing and working on based on feedback. It's already getting so talking to vendors talking to kubernetes folks, looking at stuff. That seems like good things to test, but one of the things it'll do um similar to kubernetes. So kubernetes is writing tests all the time and then eventually they come out with the best practice or and not a best practice.

E

They'll say this is a conformance, so this is a required feature. This is something we really think everybody should have for interoperability.

E

So if we come up with a best practice, it may be a one to one to a test or it could be something like the idea of least privileges for cns and then a subset where we go here is something to do that. So now we can say what are some things that we can actually test.

E

So the test suite is primarily to allow uh cnf developers or we'd, say vendors to go and run the test suite and see how well they're doing on these best practices that they think are also good, hopefully so that they can improve. Maybe it's about storage data or how you store data in a cloud-native way, but those will be working hand in hand as a result of the best.

E

Practices so robbie, are you interested in helping create a table of contents.

E

Yeah, I'm happy to uh have a look at that yeah sure okay, that'd be great uh and I'd love to um have that discussion uh when you're ready to have it. um I think other people would, I think, welcome the structure in it too. um In the meantime, it'd be great to move forwards. Our discussions in the discussion board around the different best practices that have been pro so far on the definition of a cncf of a cnf.

E

um I know we're at time and just so people know we are having one meeting and then we're skipping the next two weeks and starting again uh not on the fourth, because I'm assuming everybody's just going to be back into the office, but our next meeting after that will be on the 11th. um So thanks everyone for your time today. I really appreciate it.

E

So there's a meeting next week and then meetings for two weeks: okay, yeah. Exactly so thanks cheers. Thank you.

E

You.
youtube image
From YouTube: CNCF CNF WG Meeting - 2020-12-14

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).