Add a meeting Rate this page

A

Okay, okay, I think we can probably get started there's quite a few people on the call and uh people are joining light can just catch up afterwards. um So thanks everyone for joining. This is the cnf working group. In case you got lost and stumbled into the wrong conference room. uh We meet weekly mondays at 1600 utc, and this is our first meeting for this year.

A

So before we jump into the uh agenda items, is there anything that anyone wants to add or likes to would like to see before we get started.

A

I do see that anonymous wombat is adding uh chaos experiments.

A

That's me.

B

This is taylor.

A

Okay,.

A

Sure, um and if nothing as I, if nobody has anything else to add, I guess we can uh jump right into the agenda, then um so first on the agenda um is voc. I think he's on the call right.

A

Yes, I'm there in prison, okay. uh So your discussion item was about this discussion that you started about uh cnf candidates for assessment. uh Would you like to like kick it off? Do you want me to open it for you? Would you like to share your screen.

C

um No, actually, I didn't didn't make much out of that. I wanted originally to initiate the discussion, as we are putting us in position to make some best practices and then some some rules for for evaluation of the cloud native network functions.

C

I thought some of the the developers of the network functions might candidate their own projects to actually also interact, or not only to define the best practices uh and uh the the requirements, but also to uh to do that by having, in inside a couple of I'm not saying like long list of the application, but a couple of very concrete ones uh that we can use as a basis for for sparring on on these best practices.

C

So really to do the concrete evaluations of the of the concrete functions as we develop best practices, and then it would serve us potentially to fine-tune to choose if some best practice is really relevant and meaningful, and some practices are not uh in that sense. So just to have a little bit uh concrete.

C

Basis for uh discussion, because I I felt um so far- we have been fairly on a high level uh and then I thought it might be good to if somebody of the developers would candidate their network functions with a which they consider maybe very much cloud native or even some that are having some issues with that, so that we can run them through the best practices.

C

I wanted to start this discussion in the in the forums, but obviously due to the holiday season. There was no much traction on it.

A

Yeah, absolutely thanks. um So is there uh any one who's either a scenic vendor developer that would like to volunteer one of their cnfs that we can actually have some kind of like world real world assessment about this or know some. It also doesn't have to be immediately. You can also say I want to take time and reach out to some people. I know see if they'd be interested.

C

In also open question in the round here, what do you think about that as an element of our work here you know: is there some opinion on that one? Maybe it's right avenue to to go. Maybe it's not so I just want to throw it in the round.

D

Hello, this is victor morales. um I just have a question regarding this, um so the idea that you have is basically um to list or to reference the the cnf from here to the projects or because uh what I have seen is like, at least in the cnf testbest project. There is a couple of examples where we can, you know, use it or yeah. I think taylor put some information there.

D

So anyway, probably I can put the same comments in the discussion to have it. There.

D

Or, but for now is, is that what you have in mind like uh these two reference, those cnf from the repository.

C

I don't know that uh repository, maybe I'm just looking now: okay.

D

Yeah.

C

That's it so I can. I can take a look uh we'll need a bit time, but yeah they. There could be these.

C

uh What I see on the layer, maybe I just take a review. If you can put the link, maybe that's what I meant.

C

I was more uh on not more, but I was in general, looking towards having a well-defined uh and let's say, packaged productized cnf that somebody of the developers, vendors, open source project, has and then use it as a as a real life check for the for the assessment, so essentially trying to do assessments uh according to the the best practices we generate like there is one uh that was sent about the operator view platform view the assessment sheet.

C

That's in the in the google drive using these these statements, these criteria using the the best practice criteria and then just checking.

C

But I'll look at this page and we'll review a couple of those and then provide the feedback if these are actually those that I meant would be useful.

D

Okay,.

C

Think, maybe maybe some of uh just uh to add to that- maybe some of uh say more challenging functions, for example, taking a 5g core data, plane, intensive function uh or or something like that to use uh to provide the the borderline case, because these are from the practice appearing as the most problematic or not problematic. But most challenging wants to fit into the let's say normal standard kubernetes model.

E

um I think that there's also, we would probably want to go over more than one uh in this like we want to start with one, but there's there's different, there's different models, there's different types of uh of common uh threads that we're gonna, see here that that we may want to investigate and check against that particular pattern. So, for example, you may have one that is very heavy around around uh how how how apache core may work and and that those have certain assumptions and certain uh control plane assumptions that are that are made.

E

Then you may have others that are that are uh completely separate, but uh don't don't have the same level of requirements on on the control plane uh that freezes up to to had.

E

How do we build and manage it without having to bring in all of the, uh and I don't want to use the word legacy, but all of the assumptions that you that you would tend to have in in a pack-a-core environment and that to see what the differences are like if you're bringing in a firewall as a cnf, then the control plane requirements are very different from something like like a packet core.

E

So uh we so we should make sure that we over time we go over more uh over more uh types of environments to to see not only uh not only how are the same but we're. Where do they differ as well, while still focusing on on that kubernetes on being that kubernetes native style.

B

Approach book are you: were you only interested in open source.

B

Projects open source uh products that are um also open source.

C

uh Not only necessarily um they could be also the the commercial ones, because I think it's uh probably prevailing model for those bigger functions, but for that we would need the developers who would be ready, who would know the details of those and then can answer the the questions can can check whether the patterns that we are defining are sustainable for that function or or not, and that could be a trigger for some discussions.

C

uh Why not, and and what holds us from uh or hold that particular developer vendor uh from uh adhering to these best practices. They were just really looking for how to get to the good discussions on on a concrete point, as we could start from the open source ones.

C

It's probably going to be easier.

B

So, on the open source side, um we can probably map a lot of the applications, but those may those are likely to end up being one part of a product.

B

Whenever the cnf is actually deployed and sold as far as a production, cnn cnf network function so.

B

The list that I put in there that's from either, if we're going to like the examples from cnf testbed, the ex the list of examples on the test, suite that first one that bill it open up. Where you go, look at nsm examples. Those are all the smaller components and stuff you may see for the most part.

B

Unless you look at a use case, I mean, if you look at a use case instead of a product, then we could probably take apart the different pieces and go. Oh here's. A single application, like the vsp use case, you're, going to have the aaa and dhcp and a lot of other pieces that you have to have so those are part of it. um And then you have like the different gateways and those could be.

B

If, if you thinking about a kubernetes based deployment, then ideally someone could you could have different vendors providing the different um if desired you could. You could get different pieces of that use case from different places, so you may actually have your um gateway at one end. That's from someone and you don't care that it's not from the same vendor because it all works together, but that would be going from like a use case and then breaking it down.

B

Otherwise it would be nice to get some cnf developers that are able to speak to it. Like you're, saying.

B

I mean if you look at everything we need to be able to have access to code more than having people available to answer questions and talk to us about. um Are we coming up with best practices that are going to help them as developers, whether that's a app developer or platform developers or ops team? Do we have the people that can give feedback on on the best practices that we're discussing.

C

Yeah correct and it's some later stage, hopefully then bring the artifacts in certain reference environment and also be able to to do the test to run the tests against that. If we let's say progressed over that compliance approach,.

C

On the other side, if you're looking what the results, what these best practices could be used for- and there was a discussion around the pr uh which was uh around the initial framework, yeah.

A

I think that.

C

Leads into our next discussion, yeah potentially, but potentially uh I just wanted to to reflect. Why is that uh interesting? uh So if we have a good job done here, then many operators will take this list uh like today for a security things around kubernetes. You go and take a cis list and say: okay. This is what I want uh every uh vendor supplier whatever to fulfill, and then you put it in your rfqs.

C

So ideally, if we did a good job uh after some time and have a set of best practices, many operators will take them and put them in rfqs when they're choosing the the rfps. When they're choosing the network functions um cloud native network functions uh and if we create something that is disqualifying uh or that is reducing uh feasibility for many network functions. Due to the reasons that we didn't evaluate on a practical uh and concrete examples, then we might uh cause some uh some some challenges or some problems to those.

C

So that would be really interesting to have a dialogue on that and then something we believe is is a best practice and should be done. A certain way is not supported. Broadly then, to understand why and then see you know is that them a best practice or not or or is there actually advice how the limitations of the cns could be uh overcome? So this is all a sense of of searching for a concrete examples and then concrete dialogue with the developers.

A

Yeah, absolutely, I think that kind of so if anybody has any um ideas of who wants to contribute to the discussion or candidate cnfs, please feel free to add it to uh the discussion item uh here in the repo and then uh that kind of leads into our next um uh item on the agenda is the kind of the initial framework. So thanks once again robbie for putting this together, I know um vlog.

A

Has uh you there's a couple open uh things here, but has everybody had a time to look through this, or does anybody feel like they need like more time um to look through this.

F

All right dan from bell I'd say a bit more time coming back from holidays, so uh maybe next time.

A

Okay, um so I think we can probably leave it open one more week and try to get it merged by next week. um Is there anything that anybody wants to discuss uh specifically specifically right now.

G

All right, a few comments need to be at this right. I'll, have a look at that and trying to make sure at this time we're going through.

A

This okay and robbie is there anything you'd like to bring up right now about this pr that you created.

A

um Please approve it.

G

um I I think I'm hoping this pr will create this initial framework, so, ideally speaking, this will be the the framework that we will base our contribution on. So I really encourage everybody to look at that and once approved, I'm hoping to follow the scheme that proposed by this pr so make sure we we do our work more efficiently. Afterwards,.

H

um I'm going to say what I've been saying before, which is this limits, our scope? If we put it the way, you know and literally first time, I've read it for apologies, but uh it limits our scope. If the first thing we say is um it's a question of making sure that cns are compliant against best practices, because the best practices have to have reasons behind them, so there is a bigger problem to solve. Before you can start saying. Cnf should be built this way. I think.

A

um So, actually, I think if we jump down to uh the actually it's not here, but the the descriptions um it actually each of the like templates actually does have a does. Ask you to list the reasons uh why each of them should be so so there's goals non-goals like the user stories, um and why so, if you think something else should be included in here well.

H

No, I mean that's fine, but normally when I'm writing a document like that, then I'm saying here is my motivation. Here is the goal that I'm looking for here is the thing I'm looking to accomplish and then I refer out to why that goal is a laudable one. Why it's the one that we should be aiming for. So where do I refer out to.

G

So, just just to clarify, so we actually decoupled the best practices from the actual uh documents. Would that really allow us to allow anybody to propose a business practice and as long as they can prove that there's enough data to back up why they think this is a business practice it it will go, and this is the template that bill is showing and if you feel, there's any more information you would like to see for any best practice before it can be validated and it's promoted to be approved as a best practice.

G

We're gonna paste the certification on. So this is something we can include in the template. If you.

H

Well, well, I I'm I'm not really. I think I mean if, if what we're doing here is best practices, that's perfectly acceptable. I'm saying what do we consider authoritative references for um for motivations, so, for instance, to give an example?

H

If I assume that all my cnfs are going to run on malta's, then I want someone to have made a an informed and reasoned choice in that is documented for with their reasoning somewhere else, so that when I say well, I test it's running on multis like this that and the other. Then I've got a reason to be testing for that and a reason for the best practice to be acceptable bad example, but I'm trying to get to that point.

I

I'd like to add one more thing to this is um one of my um you know. One thing that makes me nervous is: despite this whole everybody thinks they're agile. Now um the service provider world likes to play at it, but, like certain things, just don't conform well to being quote unquote, agile. So what happens? What is going to be our process if a best practice, six months from now turns out to not be a best practice or this, and that, like? How are we going to prevent like the road that etsy went downward?

I

They wrote a bunch of arbitrary things down at the beginning, and then it was like we were never ever ever changing these um especially kind of to ian's point of view saying that you should be building to these best practices, and one of them is debunked like how do we keep developer trust when we say we need to like go back on this or we need to modify like you might have to start changing. You know x, y or z, part of your development.

I

If you want to keep following quote, unquote best practices.

E

So if this is direction we're going to take, I think that we definitely need to make sure we establish a set of principles and say like these are things we tend to look for in general, regardless of technologies such as the system should be able to withstand a a container or a pod dying without losing service as a without losing the significant service or degradation, or we can. We can come up with other general high-level things, but when it comes down to low-level implementation details, we have to be a little bit careful here.

E

To give you a really good example, uh then, and not in the not as much in the container space. But let's say you're talking about like best practices for maintaining a car. You may say best practice in maintaining a car is to make sure that you fill it with the right set of gas and and fill it with the right set of oil. But then what does that mean if you're driving a tesla?

E

It's like you, you end up with a different set of best practices for for it, even though they are they're still fundamentally a uh a car, and so we need to be careful that we that we don't fall into the same trap and instead we we list. What is the principle we want to make sure this thing is well maintained, or we want to make sure this thing is well uh is able to scale or so on.

E

But then, when we list when we list the best practice, that is, is it based upon a high level principle or is it something that is covering an implementation detail like if your?

E

If your environment is, uh if your cnf is multis, and it has these conditions, then these best practices occur and that there's a set of appropriate conditions so that when someone comes along with uh something they want to install with with banam or they want to, or maybe something that bypasses all of that and adds it in with nsm, then you know in what context that best practice applies in order to in order to apply it you're getting with something.

E

That's a bit concrete and we can circle around and say in order to achieve this principle. These are these are requirements or not requirements. It's too strong of a word, but these are best. These are some best practices that may exemplify this particular property. It's not the only path, there's other paths that may be that may be appropriate that are not listed, but there are things you can use as a reference to to get there. So if, if we're gonna head towards that that practice, we we we may use something like that.

E

That could be something we could use for a framework.

I

I did put in a pr specifically for us adding a section for providing context um just because of what you were describing um frederick. My main concern, though, is if we change something- and we say you know turns out that this doesn't actually support a principal like we thought it would right.

I

um My big fear is, is um it'll, be kind of like what we had in vnfs, where, like the quote, unquote best practices, the requirements, the standards, etc, weren't really feasible in the real world, and so most developers rolled their eyes and just said, I'm going to build what I think works right um and if we yank the rug out from people a bunch they're, probably not going to take our group very serious, because it'll be impossible to adhere to um so I'm just kind of curious, like, as you know, let's say we adopt robbie's um framework, which is fine with me.

I

um I don't like daniel would like to read it one more time, but um let's say we go down that path. um I just want to make sure that we leave ourselves out that we have the ability to self-reflect and correct things as this space evolves. If it, you know, new technology comes out that maybe even makes us re-evaluate a principle.

I

um I would like us to like have a plan for that in advance versus you know. We get something that's broken later on and we don't have a way to self-correct.

E

Yeah, that's a good point and in terms of something like etsy, we have an advantage here, because the things that we're developing, as I don't believe this is a standards body, even though we are even though it may end up informing standards bodies.

E

And this is an important distinction, because when you start looking at what does it mean to be a standard that we're in you have entire countries that have explicitly stated that there will not be any change in in this book within in order in order to make it reasonable, and the end result was that you end up with a lot of stuff up front added to etsy on the off chance.

E

Something might be useful, as opposed to actively being useful and, as a result, a large portion of things that were listed within etsy were never implemented.

E

uh They were just added in on the off chance that uh that they may be useful, and so we we should be careful in in this- that we're not falling into the same into the same trap, because we want to list things that are common, and one of the things that we could do is put a priority towards things that we see in in development or practice where, if we see, if we're not seeing any active uh implementation or we're not seeing any active development but we're something that is aspirational, then we should explicitly state that.

E

But if we see something that is, that is gaining a lot of traction and we write something that is a best practice surrounding it. Then we should explicitly then, at that point we we can treat that differently than than something that has no actual implementation behind it.

E

So but yeah, that's that's going to be a challenge is trying to work out how to how to ensure that you, you get that that change and, I think, that's more of a process more of a process problem.

H

So one way you've got two things there. I think one is: where do we source our best practices from again? um You know what evidence we have that this would make a good best practice um and the other is given a best practice. How do we get feedback on it so that, if it turns out that it's counterproductive, we remove it from our preference list.

G

So it seems to me we need uh around the process of approving a best practice or change it and just put some criteria around them.

G

I'm happy to propose a draft as well.

A

Okay, robby, I'm going to put you in the notes for that then. Thank you.

G

It's one b: otherwise, sorry.

B

I don't, I don't think from the if you look at the perspective of like uh cap, the kubernetes enhancement proposals or python or ruby rails, where different projects that are have a healthy, organic way of adding new things and modifying new things. It's part of the process.

B

So if you are saying that something's problematic, you ideally see it before it fully gets to the point of implementation as as a enhancement. So for us that would mean before we endorse it as a best practice, but for those that you don't what happens? Is they have a history on a cap and they go we're refactoring this or they'll have similar rfcs you'll have a new one that comes out that addresses things that are missing, and then you can also deprecate likewise rfcs, where one is completely deprecated and no longer recommended.

B

I don't think from that perspective that we have a problem as long as we don't add additional rules and and process that blocks those things. Ideally, anyone could bring something up and and start talking about an existing best practice and problems. We can move that into a discussion, start working through it. If we see it as a problem, then we can move forward on potentially deprecating a best practice or maybe modifying it, and jeffrey you've talked about adding context saying where it may be a problem in some situations, but perfectly fine in others.

B

So that's something that we may do after the fact. You may have a best practice that everyone agreed to looks great and then, as we get going either because things change in the world or we just hadn't. Had someone speak up, you find it. It doesn't work in some situations and we can always add to the best practice content so that that's known.

I

Yeah, I don't disagree that certain groups do this better than others. Like I said. The big thing, though, is there could be like big horse corrections like anybody. Who's followed ipv6 for a really long time in kubernetes knows that, like we all know that the shoe is eventually going to drop and it's going to be awkward like there's disagreement on how ipv6 should be implemented just networking in general.

I

You know it was very web centric at the beginning and then other people wanted to use kubernetes for things and they're like oh now, we need things like egress gateways, all this stuff right and um you know I would say that, like cube, sig and others have done a good job of you know addressing these, but um that doesn't mean that, like the transitions have been as painless as we would like them um and like I said, even if we know that there's good models for us to follow, we should pick one of those models and call it out, because I've also seen other groups.

I

You know just assume that yeah we'll be fine and then it didn't work out the way they wanted to. Like technical debt, you know mounted up to the point where, like maybe we just need to completely start from scratch. Things like that. So, like I said I just maybe some of this is a little bit of um anxiety based on past experiences, but, like you know, I know at some point.

I

I have to look at how we're going to do ipv6 and kubernetes and then well specifically, dual stack and additionally, um you know I've seen other organizations where they didn't have a smooth process to you know something like ruby on rails or something where it was much much more painful or they just said it's not worth it. We're just not going to change and everybody's going to keep running off the cliff like a living.

E

Yeah the kubernetes example also has the added constraint that they had some a single major code base to to work around with an initial set of use cases. um I think the standard kubernetes workloads that you see and we we're gonna, run into a few problems with that and that we don't have such a such a thing like.

E

We can't there's no reference uh architecture that we will be able to point to and say this is the one. This is the one path uh like we're already seeing a uh a variety of different approaches that uh that are occurring each with different set of of uh different principles and constraints that uh that are being deployed and so like. We that that's part of the reason I mentioned about the the conditions before as well like if you're running in this style of environment, then what are? What are possible?

E

What are possible best practices, but you also need a way to back up as well. So as you learn more or the environment changes, then we're not stuck with those and there's also there's also issues around what what decisions have been made within a given organization.

E

So, even in a standard, kubernetes environment, when you start looking at things like best practices, you know you pick something as innocuous as a cni.

E

If I choose, if back in the day, if I chose flannel as my cni versus maybe uh openshift cni versus something like uh you know, some of the some of the other cni's that have come along, such as weave that they ended up with significantly different best set of practices, even just to maintain it much less how they approached the development of their of their environment, and all of them were rational ways to to approach it.

E

They just made different decisions based upon their requirements and technologies, and we, if you, if you look at the best practices that came around kubernetes, they ended up with three simple rules and those three simple rules where nodes can talk to other nodes. Pods can talk to pods and nodes can talk to pods, and as long as you met those three conditions, then your has a cni along with some of the basic contracts that were added.

E

Like you give your id back and a couple other minor things, then you were pretty much set and good to go and it was hands off uh primarily on how do you actually achieve it, and I think we're we're trying to be much more aggressive here in saying that. Well, we want to state these are the best practices and then we say: okay well best practices in relationship to to what and that's why we want to start with. What are the? What are the principles like we want?

E

We want to be horizontally scalable, we want to be robust, we want to be, uh and the question even comes down to why, like ian, had a really great point from uh previous conversations, we had that if you delivered a a box and that box had uh met all of your requirements for uptime and you could access it through a very common api, do you care whether or not it's uh if it's designed in a very specific way, and so so maybe we should even get down to the?

E

What are we trying to do like we're, trying to achieve certain types of slas we're trying to achieve certain types of of ways to consume it through a uh through a cloud-native api?

E

And then we can say if you are implementing it this with these constraints, then these are some of the best practices and go tap some of the communities to to go deal with that. So we can go tap the uh the multis and the data and the nsm communities and say well you're, going to give us some examples of things that exemplify best practices and go and talk about how those how those are approached and also other areas. We can also take a look at them from use.

E

Cases like the requirements of putting together a firewall or a vpn and managing of kubernetes based firewall or vpn, are going to be much different from best practices surrounding. How do you maintain a evolved packet car on on your system? The the requirements are are fundamentally different uh down to the point.

E

It's like what is the difference between managing an op, a database versus managing a a microservice website that they're both valid use cases within kubernetes, but they're substantially different in their approach that you have to make different decisions in order to, in order to ensure the health of the application that's running on it.

E

So some just some things to think about.

C

Speaking, one comment on the depreciation of the best practices: uh that's a very valid aspect that we have to take with uh very carefully and very seriously, especially due to that past experiences, not only with uh with etsy and vnf, but many other approaches like that.

C

This was one of the reasons that motivates me uh to bring that first point in as long as we have a concrete functions and concrete pieces of code in the discussion and having it bidirectional dialogue or being ready to depreciate deprecate certain best practices. If, in the dialogue we found out okay, it's really blocking meaningful things and it doesn't contribute to you know better sla or better uptime and so on.

C

Then it's up to community to really focus on deprecating that, but we will only find or mostly find, that by confronting the rules with the concrete examples, the problem with etsy was that there was a lot of writing in a point in time, as uh was rightfully said, and that there was no willingness on consideration, but we were just pushing or not just pushing, but there was a lot of like okay. This is the framework please fit to that, and then the the feedback from the developers that was set here were rolling their eyes.

C

This rolling of ice didn't end up in the process of reviewing. Does that what we do or what they do there makes sense and how it has to be reevaluated. That's very important to to factor in uh here and another piece that that was mentioned is like black box uh thing, and I I'm reiterating- and I was reiterating in a chat.

C

There could be two purposes of that. One is completely developer centric and that should go like how to use cloud native patterns and how to use kubernetes to the maximum and possible extent to make a best function package it in the box and deliver it from the operator side from the side of the of the actors that are consuming that that's still called a black box. You can put whatever asic's proprietary hardware in it. That would be all all same.

C

The other approach or other way to do that is really saying. Okay, do we as operators, I'm talking from the operator angle, wanna, establish a generic cloud layer for those functions and onboard the network, functions on that cloud layer and give the functionalities and the possibilities to those functions uh to be able to to run as they were supposed to run, and I think the the the value of doing a cloud native principles is at least for for that perspective of operator, that I have a generic or more or less.

C

Generic infrastructure that runs in x y set locations and the c and f's are onboarding on that. One and the set of best practices is a contract, is a kind of sort of contract between these kind of infrastructures and cnfs.

C

Just wanna wanted to reflect on that because for a black box um I think black posts, whatever it is inside. Nobody wants to care except developers who are making that black box to be the best possible.

H

Sp speaking as the supplier to a bunch of very inquisitive customers, I'm not sure that's true, but um perhaps what we're saying here is rather than the what the document currently says. You know we will define best practices in light of other people. Other definitions of cloud native, we should say we will define best practices, that's one avenue of attack, but we've got other things to deal with as well. I think we're ruling things out that we should have within our remit.

A

What exactly do you mean by that ian? Can you rephrase it well.

B

What, specifically, are you concerned about that we're leaving out or that you're thinking or leaving out.

H

So I mean we've the the points keep coming up um there right, that we don't have a platform definition, because we don't know what good cnf is. um You know a well-behaved cnf following a standardized and singular platform definition as an example. um We talk about cloud native as if it has meaning without context. You know the words mean we know exactly what a cnf cloud native cnf looks like and those principles exist elsewhere, and I don't think they do so.

H

um Rather than saying we will do the lowest layer of this we'll do the the implementation. The thing that describes here is to see here is the cloud native best practice here is how you demonstrate that it exists in a given cnf. We also say here is not just the test for the thing we're looking for, but here is why that thing is a best practice in the first place. Here is our thoughts on why it should be a best practice. Not necessarily um you know, hoping that turns up in another group.

B

Those the why why something should be a best practice is explicitly part of the proposal process, so starting with the discussion board, so you're discussing something- and the discussion board of course, can be other things, so we have like the actors and stuff, but the when you're someone is bringing up a potential best practice or maybe within a discussion. It is ideally part of the conversation would say here is why we think this is a best practice. Yeah.

H

But if, if I were writing software in an old-fashioned way- and you know even if we're doing agile, this still exists right, we have requirements, design, implementation, the implementation meets the design and the design meets the requirements.

H

But what we have here is implementation with a bunch of, hopefully some requirements thrown in for good measure, but that means that you know individual best practices are considered individually, not necessarily sourced from the same set of you know a consistent set of requirements or a consistent idea of design.

H

um You have to build down to the level. What we want to be at here are testable things. We can examine.

B

So we're not doing this in a vacuum which it sounds like you're implying that well.

H

That's true, but I've asked before what are our where's, our design where's our requirements coming from.

B

If, if we were building all of this from scratch, if you just came in and said we're going to build software and operators just start using it, and just you want things to run, okay, that's all we we're not doing that. We're not we're not starting completely from scratch, we're we're building off of existing applications.

B

So that's related to putting the discussion forward on cnf candidates. So that's working from that level backwards. You've already listed in the actor and hold on a moment, and if you go look at the actor discussion, one of the items that was brought forward was platform developers or vendors. Whatever you want to call those wherever they are, so those people would be involved. Architects designing from maybe within the a a at an actual um service provider that may be designing the overall.

J

Architecture.

B

So you're going to have all of those people engaged, but it doesn't mean that we have to have all of that done before we even start, because we already know that part of it's going to be based off of what's out there. So the the bgp speaker are we going to say those are no longer useful immediately.

B

You you'd probably argue that those are going to exist for a while all right.

H

I I'm fine, but yes, if you want to design this stuff and you're a little bit short on the on the, why of what you're doing bgp speaker as an example right, then, where would I put down the y? Where do I put that down- and I don't mean, as as in the same way, that I try not to write code and hope everybody understands what the requirements were, that drove me to write it, I'm saying where would the abstract requirements go when we get those actors together.

J

Or where does a user story fall short on your? Why, if you were to capture what you're saying and use a story, the user's pain or whatever, it is sorry.

H

To exp, to be explained for the first time in a what is looking to me like a test or a test description is my.

J

We're talking about the requirement the driver for a requirement. So, if you're out there developing any system at all and.

H

You go out.

J

And you get user stories right, you say this is a user. This is what they're doing. This is a problem whatever it is, and now you're going to build your requirements based on that user story. What where you got the requirements which could come after the user story? You can look at the user story as a requirement either way. But what, where are you not capturing? What you you are talking about.

H

I'm really saying that the user story stands independent of the conclusions you draw from it.

J

Yes, that's correct, so you have the why in the user story, are you saying the conclusion is the? Why, or what do you say.

H

I'm saying I'm saying the conclusion stands: independent of the user story. So if we have a user story, would it not make more sense to keep it separate from the conclusions we draw from it rather than embed it in every single conclusion, because the proposals we seem to have here, um the the things we will be filling out as templates are conclusions, recommendations the final and the final element of the implementation.

J

So fair enough, if you were so if the user stories were separate right, but you referred to the user stories and that's what we say: okay, here's our! Why you need to have a real world description of something you want and point back to that and then you have the and then you point to it instead of having it in directly embedded in there that would kind of satisfy what you're talking about.

H

Yeah effectively uh um having a home for those things, um independent of the the things that we, the the recommended, you know tests or things to do, and tests that satisfy that user story having the user stories stand independent because I think that means that the user story will be more yeah. Fine, it won't have conclusions of its own, but it will be hopefully something that people who don't necessarily care so much about exactly what we're testing about cnf we'll actually be able to read it and make sense of it.

J

Yeah, that makes sense and user stories and then maybe even surveys that go with the user story, like someone can write up a user story and we can kind of figure out how how many people you know relay or that user story resonates with them in their business and stuff like that, and we can kind of have the drive behind the user story, how much agreement we have with it and then the these other principles we can kind of you know work at it from both angles.

J

You have certain principles of cloud-native principles, so on so forth, and we say: okay well, if you're wanting to have this type of architecture and these types of trade-offs that go with this architecture, are they compatible with this user story? No drop them off. You can't implement it or you can. Whatever I mean, it seems like that. You know this is a you know, a cat in you know chicken and egg situation, which is fine, um but yeah user stories seem to me capture everything you're talking about.

H

Which is fine, I mean if we're coming back to you know our repository. My point would be that they deserve a directory of their own, I think, and a process of their own as well.

B

I like the idea ian of having um a whole set of user stories, that people can contribute to and and maybe more than people just being able to find it separately would be people that want to contribute user stories, but don't really know it. They they're, maybe they're, have more experience on the user story. Writing those and less experience on helping with build a best practice or discussing the implementations.

B

So it helps with that. I don't. I wouldn't want to stop people from getting started. That was the whole point with uh doing this, which ties in with um having the user story embedded, but I would say whether, if someone, if someone well, if someone starts a proposal for a best practice, they should it's it's required actually before it's going to make it that they need to tie that to the user story yeah and that can always be copied out. If someone starts with the user story, then great just go to.

J

The.

B

User story- I'm just saying: let's do both and and we can get started.

H

Yeah, that's fine! If you consider what we have here, we have a git repo and every git repair. I've ever worked in. You can commit two changes in two files at the same time. So, if you've got um a best practice, you wish to recommend against a user story that no one's ever thought of before you can commit the best practice and the user story in a single change. It just isn't in a single file anymore right.

H

You commit the best practice and the reference to it in the user story, but it gives you three options now, rather than one. I can commit a best practice based on user story that somebody else documented. I can commit a user story even if I don't know what best practices that implies and I'm leaving other people to tell me or I can commit the whole thing as a as a chunk and people can review it in that light, whereas what we have at the moment doesn't seem to leave us with quite those options.

A

Yeah, um you know, I think I say what you're saying I see what you're saying. um Would you want to come up with like a proposal similar to like robbie's for the usual user stories.

H

um Yeah, I think we can build on robbie's patch, and we can say you know we we take two streams of information. This part is our responsibility is x. This part of our responsibility is y, and here is the process for both of those things. um So if we start there and then we want a template for what user story is including audience and so on, um which would be the next part of that.

B

Okay, perfect, is there a would it be all right if we um get this merge from robbie in place and then do a new pr on top.

H

I'm not sure.

H

I want to read what ravi's written a bit more closely before I say yes to that, to be honest,.

B

Okay, well I'd say um everybody, that's interested in helping, please go through the pr and let's try to get it merged, we're we're not trying to get something perfect today or this week, and and it's sitting there. This goes back to the comments earlier about. What do we do if there's a best practice that needs to be updated?

B

None of this should be thought of as final. It should all be thought of as we're doing we're doing what we understand to be best today and we're going to keep updating it every day going on, but if there's something in what's currently there and that you think needs updated okay, but ideally we can keep having smaller prs that get merged sooner um so they're available yeah.

H

I mean it certainly in the future. That's obviously the case we're trying to make this so that everybody knows what self-contained change looks like, so that makes more sense right now we're busy defining our outlook on the world. So um while I think I'm all right with what robbie's saying I want to read it more properly because I don't want it to be, you know I want to make sure we're getting somewhere in the right direction.

H

uh Plus it's got a few spelling mistakes in that one fixing, which is also making me, is making my ocd go off.

A

So sure yeah, so I think it'd be great if we can all take the next week um to review robbie's pr and then we can continue the discussion, then um so thanks everybody for joining today. I really appreciate the discussion. I think you know. I really appreciate your idea on splitting the user story um and the best practice from each other.

A

So thanks everyone.

C

Thanks bill thanks again cheers bye.

B

Thanks.

D

Bye.

D

You.
youtube image
From YouTube: CNCF CNF WG Meeting - 2021-01-11

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).