Istio Networking Working Group, 11 Apr 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Istio networking WG meeting - 2019-04-11

Description

- Produce an epic of the roadmap for 1.2 in github
- Produce a decision log for 1.2
- Enforce all PRs to be associated with an issue.
- Proposed names for multicluster service mesh implementations: Primary-Secondary vs. Peer-to-Peer.
- IPv6 status update (testing)

A

Everybody welcome to this your networking work group meeting. We have this new format where everybody joins from their desk. Let's hope that will lead to you, know better communication and better decisions as well.

A

We have quite a bit of governance in the agenda today, so it's actually mostly governance, except maybe for the last item, which is a follow up on the multi cluster naming convention, so I hope that image online because he wrote a document about this with some proposals, Oh excellent, but in thanks. So first of all produce an epic of the roadmap for 1.2 in github, so Steve proposed this, and this is very much in line with what we were planning to do with some minor changes.

A

So what we've been doing in the past was to have one epic bird per feature and that epic would include those several issues depending on you know how many people work on it and how granular it is Steve, do you would you okay histories joining it wasn't in okay, stiffly? We were just talking about you so.

B

Shouldn't this be something that the code, mother or or a TOC decides, because each project doing its own, each working group did so doing its own stuff. Since it's kind of weird right.

A

Right but on the other hand, we can also propose things. It's not is.

B

It something that we need part of the code move or is it some things? I mean it's it's, it seems like we have enough things that are changing at the same time. Maybe we can see how how I mean focus on code.

A

Motive cost in here, so this is what we've been doing in the past, and sisters join I'm, not sure whether he wants to have like one one, epic for the entire roadmap or something that's.

B

That's a big work before I mean since we had used epic in the past, have seen they've been useful. I'd say we need to expand them or what's stopped with the experiments we had so far. All.

A

Right, so let me tell you a bit about my experience on that, since I was the one opening their pics and trying to track things. So what I noticed in the past was that we were not disciplined, so we had PRS that were committed without being linked to a an issue or an epic or anything else. So we had all kinds of like untracked features coming in right.

A

I would definitely like to see us moving towards a model where every PR is linked to some issue or epic and distracting context of the roadmap for a of a feature at least okay.

B

But shouldn't that you RC decides the process for the entire organization. If it's a requirement, it should be a requirement from POC or the pod move. Otherwise, I don't know my sitting gets. We have enough change with with the stuff that we encode more than all the requirements, I'm a bit worried about adding more processes and more and does it is it networking related or is it something that should be so.

C

Quick, if I can jump in Causton last week during the environments meeting I had suggested, we have an epic for the environments, workgroup meaning without a lot of overhead. Just a list up here are the features we're going to do for one not two, and there was like five things on the list. So it's not a huge list. I didn't specify any additional requirements.

C

I do agree with the Unruh that it would be great if people linked that stuff to issue trackers I would just like to know what our one not too bored map is for the.

D

C

Remaining and get our the environments workers focus on that I think you'd be good for the networking group. Nobody.

B

Is nobody something about not doing the creating unethical I mean what Andres saying is that if, if it's a requirement for people to start putting bugs or linking and creating issues, and all these subsets of courses that probably it's not in under either environment or networking? Yes,.

E

So this week we had a good workflow meeting, which Martin was right, I believe Acosta. You were there right, so that team is actually producing the standard requirements for Pio issues, so I think there are design. There are a lot of consensus from the car this week that we don't want to overwhelm you a developer so quickly. Us we are looking at maybe have a little bit more template into the PR, so people at least they need to clear us out some of the required information for the pr2 coming and merged. That's.

B

That's just fine and that's a working group that I mean again, and they are requirements at all. Bugs should have a three day. Guillotine should not be open for more than three days, and you know, without a comment and without.

D

B

And should be closed in a timely matter, so using PR issues for for this kind of stuff. Again, let's leave the working group to the staff and he or she decided not reading right, Franco.

A

Seen, however, we shouldn't be prevented or like Phil, that it's not our job to inform the TOC promptly, believe you know one way or another, so I don't think we should let every decision to be top-down. Coming from the TOC, because.

B

That is already in turn right.

A

Right, so let me tell you, like I, think it's really valuable to to track the roadmap. We unfortunately don't have enough like enough visibility on what's happening in general, so III heard from you from linen from Steve. Does anybody else has opinion on that? So.

D

My comment is anything that would help us. You know, you know, new people understand what the roadmap is and see. It is beneficial.

A

F

Also to know the progress, how we are doing I think that's where something like an epic helps. Now we can change the format, but it's really good to know if you are making progress in the features that we are going to deliver.

A

Okay, thanks Josh, so how about I? Take this like discussion to the TOC right I think there is a meeting on I'm going to take this particular item and ask you know whether they would like to follow this model for all the groups, whether they wanna impose a different model on all the groups or if any group can decide how they track their own map. I believe.

B

Is the working with already working on yeah Andrew.

G

We met just yesterday and they had work flow and we're talking about stuff exactly like this, so I'm, not sure that we need to rebreathe this up in the TOC as well. Okay,.

A

A

B

Its conclusion is reached to be communicated minutes. It's a working group is still working and they're still, you know so.

C

I guess, while the working group is sorting that out, we can kind of do our own thing, but yes, I think it would be valuable to have some type of roadmap. You know a short five six items that were working on for the release I would find that incredibly valuable I put together so.

B

We can keep me nobody's saying that you cannot create whatever issues or things you want and under I can create I'm. Just saying that, let's not have each working group define its own processes and requirement or impose developers must do this and must do that. Joran strategy. Okay,.

A

F

A

Are two parts to the issues right first of all is whether we track the things with the epics, so it looks like that's beneficial to have, and I can definitely like do this exercise we're adding half within the form of it, and the second part is like if any PR is linked to an issue. I think there is a similar proposal somewhere in the code move document, so we'll wait to see if that you would like, particularly you know further some for developers. This is like a process, that's being generally like forth in industry,.

H

A

So you are breaking up badly I! Don't think your that's a twice! Well, if you want time, I mean fusion drive, you can just come here.

D

G

Added a link to the proposal that we were working on for the new issues worth loved to the page.

I

So I think we're mixing up. Two things here: I, like first, is definitely the process of whether we require an issue for HBR. What in general would be issues but like another thing, is for each feature: it's probably a good idea to file an issue. That's what looks like we've been doing forever. It's not the change of a process and just makes total sense for me personally. So, let's just probably discuss them separately.

I

The were closed out, definitely makes more sense for them, or the relate irrelevant word group, but for like stuff that we're planning to do. Why? Wouldn't you just drag face and form of issues or any other form.

I

A

B

The networking so.

C

Real quick and I'm not once and outcomes what what what was out I was late. I'm. Sorry! So what was the outcome? Andrew? What.

A

Is the outcome of this discussion is that we will okay, we'll take the action of opening with hub epics for all the features on the roadmap for one tool, and we will let the code move for a group decide whether PRS are associated with an issue or not cool.

C

A

Okay, that's my understanding. Maybe.

B

Wait a bit until they figure, because the requirement is that any open issues they are going to have metrics and and to make sure that any open issue only stay open for a certain amount of time and it's closed and anyone who's assigned to it responds in three days. So is a whole process coming through and I. That's why I'm saying let people who are working on that finish the design and not solve this in networking, so.

I

Just to make sure there is no confusion about that, there was no no effort to kind of impose SLO on the full issue lifetime. It was.

D

I

Effort to enforce a law on basically three icing things: she would make total sense, but the issues are different. So, according.

B

To issues creating and responding to issues, the idea is that we need to respond in three days for any open issue and there will be metrics and it's not clear yet where and how and.

A

Enhancement costing right and epics are, by definition, enhancements. Okay, so we'll go with that. For now, let's move on there is like a similar governance thing produce a decision log for one two. So this there was a bit of a discussion on slack and this is about informing I.

A

Think all contributors on the strategy, general strategic decisions right, it's not about every single minor decision, it's more like the long terms, for instance an example would be: do we use CNI or not by default, like you know, or is service entry, namespace, copped, API or a cluster wide API? So this kind of things and the proposal was on slack- was that we record this in a documents called a tea. I actually forgot what ADR was standing for, but I can find it and the we we document the context.

A

The pros and cons of you know some various approaches, and then we record the decision. And while we have this working group meetings, we can also I guess link to those little documents. The documents would be added to github, Summer, Street, Me's or maybe in a folder. They could also be in the east. Your team drive dog, like we have a separate area for our working group, so this is by the way it's not a decision of any kind. Yet it's just the discussion.

A

How do you feel about this and how we could make this work without paying again to to honor a civil process? I would.

B

Say same thing during this: what document working group ends? There are some other meta working groups that are not so we don't have to make this image working group.

A

This is about recording our decisions right.

B

A

Document working group.

B

I'm, just saying that this is some should be something done consistently across east your organization, not fair working group. That's so.

C

I think we could make recommendations for how that should be done and that's why I put it on the agenda just to make a recommendation. I, don't know if the work groups in Kona are looking at this or not I. Don't really have.

B

Meant working group I think as well and.

C

Watch one documents.

B

Documentation: okay,.

C

This would be more like an engineering decision log, so not a documentation decision. Why? But.

B

Is it networking specific its environment? Specific is security, specific will George.

C

B

Would have a separate decision lock process? Basically, where did they put it, how they put it? Is it.

C

Yeah, that's undefined, but that's the general proposal. You know I guess: I should have taken us to the code. Mod I, don't I'm, not I, don't have time to attend the four hours a week of code mods so yeah. If somebody could pour this on, I would appreciate it. Maybe 100, maybe.

B

It meant some something, someone can start something can start the prototype, see how it works. You how it we shouldn't make big decisions, taught any data, I would say: okay,.

A

So we can still have a discussion whether at least the audience audience in the networking working group feels that they would be helpful or not right, because then we can propose this for other working groups, but I don't think again. We should let every decision come from the code, more meetings like that already many fish to fry in those meetings. So how do we want to record our decisions and by the way these are called like the proposal was to use architectural decision records. They certainty, adrs.

I

How can we use the current process, basically keep maintaining the dog, and maybe eating have github pages for first so.

A

I, are you saying Phil like just recording the meeting notes, yeah.

I

That's that's one way that, of course, once we have a consistent decision from working group, that's great, but before we got there, we definitely need to keep track of everything so so yeah the dogs would have to would probably be even better.

A

Right so that would be I, so you're saying github would be better than dogs yeah.

I

I, don't know what are we trying to fix it? Is there? Is there any limitation with our current approach, basically maintaining and meeting notes and video recording? It's.

C

A really hard for other people to catch up. Sorry, Andrew I cut you off their heads. You know the reason I proposed this on the agenda is because I think if I were coming into issue. Oh there's been thousands of decisions made, and maybe a hundred of those are strategic and I'd like to know what those are.

C

That would be very helpful. If I don't have that information, then we have a rehash of that old discussion. Every working group meeting. So that's the driving force behind this idea, probably again a topic for the code mob instead of the work group, specifically how.

B

About discuss, we already have discussed topic its customs. There is track of what was discussed, use remaining cooks, use, making lists, and discussions was a mailing list. Apparently we don't have a million missed anymore, so discuss is a replacement I'd like something a.

C

Little more formal because discuss gets, lost people lose track of the records, I. Think of the decisions I just might my feeling how.

B

Do you feeling getting to maintains those discussions, or do you want to impose that something on everyone I.

C

Just opening up a conversation, Carson I I, don't have a proposal of how to do it. I I.

J

Would say that I'd see if I think you do a very good job in maintaining that log you don't have to I just think he would do a good job. Thank.

C

You I appreciate that okay.

B

Clear I mean my frustration is that there are 20 working groups now that all try to impose decision and processes and change everything when we have a problem that we need to improve testing I mean the problem is when you think of testing, and everyone is starting to create processes and change everything at once and mostly out of topics. That's my only reason to be so negative here: okay,.

A

So it is true costing that you know like normally, we haven't been doing governance and just like working group group right most of the time we've been discussing like networking specific issues, however, state brought Steve brought up these governance related topics, I think it's okay to like discuss a little bit on them on this particular architectural decision records.

A

What if we actually bring it up to the TOC to this side, because it's like some of the strategical decisions are not so much related to networking, but there are of a more general nature and I think those are the ones affecting most people right. So I will take an action item to bring this up with the TOC to get some my guidance on this.

A

Meanwhile, nobody prevents us from taking meeting notes in this very networking group meeting notes document that is attached to the meeting and record our decisions right, whether we taking we take it one step farther and we actually store those decisions in a more elaborate format. Again, I, don't think anybody can prevent us from doing so. What.

J

Is that, for me, I was the file you can get along with the source code.

A

Along with the source code, yeah.

J

Well, you know some markdown file with each component yeah.

A

Exactly that would be a good one right.

A

It's the reality is that this is like again quite a bit of work. So it's a matter of being disciplined. It's very easy to ask for everything to be documented for you, but each one of us would need to do that whenever a decision is made so I hope there is not the expectation that you know the person facilitating the meetings would actually take hold the notes and record every decision, because that's and/or add those documents to github. So I really.

B

Like the proposal from from Josh, because that will record the decisions that are actually have any code or any implementation and all the decisions that kind of spur fishel and don't have any and it gets a go through code review. So.

J

We get our you.

B

J

B

Not good associated with it is just mean to.

K

Everyone empty go, finally, which is in the beginning of the package, which has all the stuff in it. It's like what you have in the locks kernel.

K

That's one file, header file with all the hundreds of lines of comment explained in the context, and that should be maintained, though, as decision saying that file should be updated, I mean, if you look at the service model thing, we have like huge Commons explaining what is what and how we do this and we try our best, not always to maintain that the main core service model and the model. But so we start off and say this is how the rest of the tunnel design similar way.

K

We should just do it for all the other main EK objects or positions. Rb2.

A

Right my main concern with like committing this is that it has to go through the regular process, which is not super fast. So sometimes it's easy to record the decision. You know you know a meeting notes or a dog right after the meeting or during a meeting, and if we wait for this to be committed to github and somebody would get frustrated that the PR doesn't get through the test points and everything then we'll just make it harder for us another.

J

Way of looking at that is we're making sure that the people who are actually writing the code are actually involved in the decision and that's not something that's inside only in the committee writers.

A

But it's not always a like wait for the code type of decision. Sometimes you have to make the decision before you write the code.

B

Okay, write the.

A

Code, the decision is just.

B

A

Well, it gives you guidance that you're doing the right thing. Okay, so that's that's exactly what's happening. A lot of people write a lot of code that is not necessarily like strategically aligned, and then they get frustrated that their code is not approved or it doesn't, you know, is not even revealed because I mean nobody. May you know, may focus on that particular aspect and people have their own things in mind, and so this is.

A

This is basically about working a bit better and more focused as a community right, it's not about who gets there to write faster, the code. It's about writing the code. That is actually the right code.

C

Well, Andrew I, like the idea, I sort of proposes I, guess I, don't know how to execute it, but yeah I I think you know. Unless somebody has objections, we should figure out how to proceed as a community. How to do this community-wide almost but again, I don't have a good proposal of how to do it. I just want to have like a five minute discussion of the 30 minute discussion on it on this topic, so to see if people thought this was worth pursuing, I.

B

Think Josh and you know good point and maybe we can started what they suggested, which is we had read me or or or markdown files in the code because for things that are important enough, probably they should be in 3d and easy accessible and then you move forward. We need to create more epics or whatever that's fine, but I think we already have and for the Porsche you know hypothetical or maybe wonderful, flower design. Don't we have plenty of stuff already? So it's not a.

E

You know one thing: I'm thinking: can we align this with the release notes so today we always create the release, notes and they vary, and can we actually are, as people have their code merged also require them to update their file? Maybe we can create a release, note file either per component or maybe in one big file so that they could also remember to before their code get merged. They actually remember to update that.

J

So they we do that, okay. So what is it kind.

E

Of like kind of like what you guys are suggesting, but focus more on the user interfacing wise right, because those are the ones impacting or by user, and those are the ones we're going to do to work anyway. I guess.

J

I'm just wondering when we would do that, we would do it for every minor change, or is this for more strategic stuff? Well,.

E

Only for user impacting ones that you want.

J

E

People in the release notes right like the default changes, maybe some major improvements, maybe some of the API change, because that would be help us much easier to pull out the release notes together. There.

G

We talked about this in one of the codemod ones and I think we yeah.

D

G

That we did one do that. I saw an issue open to start getting all the pieces in place for it. Yeah.

E

I, remember telling you were discussing that we wouldn't we haven't decided like whether we have a top-level one with motor repo going on. Maybe we have one per components or it would be easy to transition to separate, oh but I think the general consensus from the code Marcol was people were wearing in favor for tracking this and github.

B

Maybe someone can really write a spreadsheet. It was a 100 steps that a developer that wants to write a bit of code needs to follow through we towards the process proposed everywhere, because I'm losing everything.

C

Made a great point: we don't want to make it too hard on developers. It needs to be easy and friction-free, but certainly the major decisions, for example, just stealing something from the environments worker, meaning we've decided to use home only as a templating engine.

C

No a lot of people don't know that the contribute code, I reviewed three or four pr's a week where people are adding complex features based upon home I know, that's not networking specific, but I. Don't work a lot on networking, so that happens and if we could record okay we're just using Elm as a template, an engine we don't have to tell people every time they submit a PR. They don't waste their time. Working on that we can say, here's what we're doing instead, yeah.

E

But I'm not blaming people for not knowing that it's.

C

Not their fault.

E

For not attending the work group meeting I think it's over for to not communicate that you overuse it in the release, notes right because we never spend the time to communicate to our user hey. We are only favored through the template approach and we so while how would they know? But.

B

It means up in the template directory of perfect Scott yeah.

C

That would be a start, I think it's start start.

B

By doing I have means an installer, so we started.

E

Okay, very good. Oh.

A

It looks like we're like a bit going in agreement or words using this, like readme files in various directories, to inform about the strategic decisions right. Should they be called readme or something else like.

E

Well, I think the problem with me is: why would the people spend time to go through your github readme? Most people is afraid to really release notes. To be honest with everybody.

B

Notice, you have two things, one is notes, and one is how you should do stuff is this component I mean it's not.

A

You must use.

B

Him only for technologies, so.

A

Release notes seems to be more for the user, like user. Visible features right well, these files or read means would be more for developers more internal stuff.

E

So we'll have to communicate at your people because most people probably don't know before they submit appear at your component. They look at the readme first.

A

Right so my proposal about using an issue for any PR was exactly that. I mean before you even have the PR. You open the issue and people think you know that issue is valid, they would accept it and then your PR will be good, but there is no point in working on an implementation that doesn't fix any problem or doesn't in.

B

Three days, yeah.

A

But if it's an enhancement, let's say somebody proposing an enhancement and like the working group reviews it and say you know this is we want this feature then they're the PR, the Associated PR, will not be going to waste right. But if the PR comes, somebody spend like two three weeks working on a feature, and we say sorry, but this doesn't fit our model right.

A

Anisha is easy to open when that and we have like maybe three days to review. If we say is this good or bad so.

B

They're complaining some people, don't read million, and but they will find all the issues on 100 dishes of memorize it and read all of them to figure out what is there and if someone has proposed it or with the three days approval that we have planning and all the other stuff I mean federal. Let's, let's try to put with the component and see how it works. Maybe.

C

Yeah, this is more complex, I think Costin and Henry both make great points, and maybe this is something we should kick to the codemod team to think more about because I, don't think well, I, don't know. Maybe they have thought about it enough. Maybe they have I, don't know. I haven't seen any evidence of the results of their work yet so the first thing vision, log I, think, is easy. Yeah.

E

But I I think I do agree. We should have something to pilot with that's one thing: we've also discussed in a codemod anything we said to the team as the recommendation it's much better if we actually gone through that as a golden component as a coding example, so that we can actually know it works before all the other components jump on it and.

B

Also organize the owners it'll be great if the component is chosen so session. The owners of that particular component choose to follow particular process and it's a guinea pig and we can get feedback and we have done from 16 years, I think for, for example, move to Moodle. It boys kind of the same thing with one component see how it goes. Yeah.

A

Okay, okay fall, so we spent quite a bit of time on this governance issue. So let's move on to the more networking related topics, so Vadim I, hope you're still with us. So you have a like how you just follow up on the last meeting about the multi-class term, naming mm-hmm.

L

Okay, can you see my screen.

A

L

Okay, so, to remind you, the current status of multi cluster implementations, we currently have three major ones. The names are here in the concepts document. The means are multiple control, plane, topology, single control, plane with VPN connectivity and single control plane without BPM connectivity, and these names are not exact. I would say, because you can have multiple control planes in these settings.

L

Okay, so it's not necessarily a single control plane. So here are so. These are the names in the concepts document and in the examples there are other means. So here we have deeply connected clusters versus cluster, where series routing and also consistently yes. So all these are first of all, they're known names or implementation details so, for example, sprinter eyes in the Year season, implementation ito, it doesn't say much to the user I would yes, and these names are rather confusing. I would say so it's not clear.

L

What's the difference between cluster where and gateway connected- and it's also not clear when they are, should be used. Okay, so I propose to provide some simple kitchen names. Okay and I came up with the idea of primary secondary versus peer-to-peer Multi cluster mesh. So here let me show you the primary secondary setting.

L

There is that some of the clusters are primary. They have the full control plane with pilot and some of the clusters are secondary, so they don't have pilot and they have to connect to some remove pilot, so these secondary pastors cannot operate on their own if the cluster becomes an available to others,.

L

B

Because we are.

B

B

B

L

A

Just proposing like we had asked meeting, we had this discussion that we have confusing names for the various stations and spectrum of possible deployments and single plane, multiple control pain and all that so I didn't took the action of actually looking into that and proposing consistent naming yeah.

B

But it's not only because he started working with with the implementation, because in with them in stores, as far as I know, we agreed on is that it's a la carte and you can install or not install stuff independently is no. There is no primary secondary distinctions that we are planning to make as a future yeah I possibly made it just work to simplify the documentation. It was never required to run a single pilot.

L

Right all right, so I just proposed a name: I propose to call the cluster with a pilot primary and the cluster without a pilot secondary. So we can choose some other names. For example, I, don't know pilot full and pilot lace, whatever okay, so just this is the distinction, and let me compare it with the other implementation.

L

The other implementation I propose the coda peer to peer. So here all the clusters are equal. Okay, you do not, as the pilots do not watch kubernetes API servers in other clusters. They do not provide configuration data to sidecut boxes in other clusters. Here the connectivity between the cluster is provided by defining or categorical cadence every centuries, and you have to run it in a server here, especially in a server which will handle those global entries just to provide a complete ISM, okay for or for the user or treat or which one to choose.

L

So first, you have high availability, which peer-to-peer full availability. So if some cluster is crashes or is unavailable, okay, this second, which means talker it's still and.

B

Button wait, wait, a minute does make any sense, I mean we want all the features to be available. In all situations, I mean in all cases. You will have availability. There is no situation or will not have high availability. So most cases will have multiple clusters running pilot and multiple. So when the pilot is never required to run the cluster, you can have manage, you have personal files that is running on a VM or some separate environment that is whatever running is a cluster for security reasons.

B

I think this kind of the triangle doesn't make any sense with the future that we are planning or we what we have yeah.

L

My point is here: if you, if the cluster without a pilot, loses connectivity, its pilot I mean it will not be able to operate.

B

Which part? Because, again, the idea is that you returned and clusters running pilot you lose connectivity to internet completely for.

L

B

You not be able to reach other ports, I mean it.

B

A

Work in that cluster good.

B

You to work, of course you cannot make changes. Yeah.

A

So it is a difference. Here's a good pointer there is a like a separation also.

B

Dns, we should have DNS in your keys and we want to make you know a B where you know this is a spectrum and you use an S choice. What we install and what not install it's not like. We. We want to continue to support two cases and have a red line. You cannot run B and a global DNS. If you, if you choose not to use peyote nice data center,.

L

Yeah, okay, so I propose is currently to name these two mutations. Somehow you know. Currently we have these two different examples with the names that are not how.

B

About not naming I mean just have multi cluster and then in woody cluster you have options of deployment as your first deployment is you choose to deploy or not deploy a pilot you choose or choose not to you know, deploy DNS I mean it's it's much simpler for a user to have, because with the cluster is not a clustering. In the end, you have pods in rough, deploying multiple clusters talking with each other.

C

You know the issue is that we have a spectrum of different deployment models and we're documenting them in the docks as a we're, labeling them as a specific type of multi cluster or model of multi cluster agnesi.

B

Suspended I mean I'm gonna change that but I don't.

C

Think we should double.

B

Down on the bed, but we should fix the problem. The food problem is that we really have a single moody cluster and the moody cluster has different deployment options so.

C

Cuz I don't know if you've seen the document that balance been working on, but there's like a hundred and fifty comments, and it probably so this is a hot topic. I can link it to you later. If you like,.

B

My season and my reaction is, is again it's it's not doesn't match what I know. We are planning.

A

Planning to change the things we have I write in this perspective, but what I hear from you is that it seems a good idea to separate the deployment of pilot from all the other connectivity options. Right like he has permutation on deployment on whether it's VPN connectivity or not, and I better, is one related to the routes yeh like if it's a federated model or not.

B

Support any case where the CA is not really where we don't have a Cisco router bit of trust. What I'm not aware of any plan to support such a thing? Yeah.

A

It's not supported currently right, but it is.

L

Yeah, of course, and so I just proposed to name these deployment options, so we have different deployment options and I propose to find some instictive names for them and to explain the users. What are the difference currently so here is okay. I mean I. Do not insist on these means. You can find some other names, but I think it's fine, something better. There just eat the impostor aware or spiritualizing years so.

B

I agree with that and I seen. The solution is to have one name which is moody cluster and, as you said, describes all since you have one ad promoting cluster. We.

M

Need some shorthand names because if you have a multi cluster and you want to install another one you're going to build to tell someone I, have this kind of multi cluster set up another one for me or, if you're having trouble someone's gonna ask well what kind of multi cluster do you have? It has to be a short summary name for the most common types, but.

B

There's no such thing that should have one type of multi cluster. You have multi class that meaning you have multiple could not because they have more than one cluster. How do you convey? But if there is no rules, that you have to have only VP and have five clusters, ODB n, you may have three clusters are in DNS, let's not be pilot. You may have two clusters learning. That is that's a deployment you choose based on. You know you have global.

B

What concessional is tour of East? You may have local. You know small clusters that are running locally and you have different ones. There is no one type of clutter, Asya that it's both of them are possible. At the same time, you can have cluster, which part of the kiss one-on-one shared that that's what idea of multiple networks you have a set of class. That's on VPN another set of cluster, another D VPN. It's still one mesh. You don't start with a mission. Stick with that mesh forever. So.

I

I think there are two two things here that the first one is really. How do we document from ulta, cluster and I agree with cost, and it should be flexible and really displayed that there are no like Street requirements of what we do and like another part to it is whether we wanna provide reference examples to our users.

I

Basically, here, oh yeah, we can call them like reference setups for examples, like literally and if wanna maintain such like reference examples which are only for shoes right, then we would definitely want better naming for those than what we have right now, but this probably should be should be just separate and that that would how.

B

About we said about, we set up an example and we we document multi cluster. We have a single document, described a multi cluster and we have a test case even with a multi cluster that has all the features and openness a week.

B

We make it clear that when you set up a model, is your multi cluster, you can be promote the cluster with some subsets running finalsub subsets, not running so we see we settle it with less than five clusters to observe running pilot when in front PPN, one exam behind the gateway and basically with all the all job, just make it clear to use that set. We have options of deployment to match your organization, but there is not no such thing as two kinds of muda cluster.

B

There is only one muda cluster with different networking internal implementation.

L

Okay, so let me describe maybe the implications for the users regarding these different deployment options. Okay, so in one employment option they have to provide it configure access to kubernetes api is ok and they also have to configure the sidecars to communicate with remote pilots. Ok, in the peer-to-peer deployment option you do not configure access to kubernetes api is ok and you do not configure your psychic boxes to communicate to remote pilots. So this.

D

Is the difference in configurations.

L

But there you have to replicate or create service entries, and you have to deploy this DNS server for that global.

B

Balance even implemented I love that.

L

These are now orientation, Ito's question. Ok, so in general these are two different deployment options and they have different implications for for the users right.

A

And I think I, really like Phil's proposal about providing some reference. Architectures, yeah and I think those should be a bit simpler to understand Beneful architecture with everything combined in there. So I doubt everybody would wanna. Do you the VPN connectivity stuff when they don't have that? Okay, so like taking on this almost Herculean thing, was trying to to name this and find a good way for us to refer to that. So we have like this document and we have like somebody said there are over a hundred comments. We should.

A

We should definitely continue commenting on the document and come reach some conclusion on that, because what we have can't is really not good I call this name. That's all the internal implementation details peering into the talks like split horizon ideas, but not the concept where the user right and it's really like. We really have to do a good job here. Okay,.

L

Let's continue to work.

A

We reconvene on this topic in two weeks. If I deem you can join I know the time is not the best for you, but I think we should revisit this in two weeks after everybody spends a bit more time. Reading the document costing just said this, the first time his soil and.

B

I was not aware: this is similar in scope for wonderful code. No, because one thing to remember is that out of holes is discussion, only one is better quality and has testing, and the others are still alpha and promise should not be mixed. For this reason, in the list.

A

Listen cos did not. Everything is called more here. Okay, this is the Jo networking meeting and we have to improve the user experience.

D

A

Well and the user experience relates to how they receive our features right if they read this page and they don't understand what this is about, we haven't done a good job, know.

B

What I'm saying is that that we have a roadmap for 1.2 and you know probably we need to focus on you know if this is your roadmap, to make some of those options better quality or production quality 1.2 perfect.

B

We should document them in and said have them, but we should not give the impression that all of things here work or are supported or are the same level, and so they have options that we have different level support the different level of stability, and we need for user to be aware of what exactly is possible right.

L

E

The way there are far status if you're, looking at 1.1 website I believe.

B

We we have, one of them is kind of I mean we, the TV agreed to move was discussed, not.

E

B

No okay, whatever right.

A

But multi cluster is definitely on the roadmap and by the way, this exercise is related to improving the documentation, and it's for a consistent naming of our features is not about code changes like what Vladimir doing is trying to get consensus on how we name these things, which is obviously like pretty hard to do. Yeah.

E

Understood I actually think for a documentation today, with the multiple deployment model is actually clearly spelled out on the differences, so it it actually I like the notion of single control playing multiple control, play it's kind of a separate really nicely, and it's much easy to explain to other people in the way we have. So if we come up with something I just want to make sure it's actually much better than what we have right now. I.

B

Think woody control train would be something you would have on a single cluster with an installer.

A

Because there is no like new installer as far as we know, right like we have to see if and understand what is so different about it.

B

So far has been a little person, we have consensus to to use herbs, multiple environments and multiple.

B

You know namespaces and support multiple versions and configuration and same time and I think that's a decisions are what we need to record it. Thank you, Steve right. We should think you're of make sure.

A

That this at least.

B

Is clearly control planes I think that's currently is a planner fragment so.

A

Martha standing was that the new installer it's about separating each component like pilot galley and mixer in their own namespace, and has nothing to do with the multi cluster.

B

Control planes in a single cluster or master or whatever, but you will be able to choose your control plane. Okay,.

A

So maybe next time you can walk us through this or in the environments meeting as well. Okay, so guys we only have like four minutes left and there is one topic, one more topic and I hope antinea.

N

A

Just an update exactly.

N

Yeah I just wanted to say that so sir gave this Varkey he's gotten a lot of good progress on ipv6 he's got one. The few PRS merged and one fee are left and we started trying to do end to end testing with I had a lot of experience with the circle CI testing with the C&I, so that actually the same the project that I based the CNI tests off of actually is what kubernetes tests ipv6 with in circle, CI.

N

So I just hooked up the test for ipv6 and and I've been running that with surveys, ipv6 changeset, so perfect, yeah, it's it's! There are some warts, so we have to. It looks like node ports not really working correctly in that environment, and some of our tools depend on that. So there's some things that are still gotchas, but we're able to do something right. So.

B

N

Unfortunately, I'm using well, so we looked into kind kinds, not really ipv6 ready as far as Sergei found out so KDC is another dinde variant, so it's actually ABC yeah. Take.

B

A look, if you don't mind on the east, you installer so nice to ecosystem century stoner we're also we have now. We are using kind, but I think we can. We can plug this as well, so.

D

B

This problem for the historic testing, the new installer and part of good move, okay.

D

B

Not attaching any way to kind I mean any solutions that would work in a similar way with kind of support, but it.

N

Should be close, I mean I was trying to get more familiar with how specifically kind sets of qu bottom so I could we could potentially tweak it to work with these pics so that that, but we have, we haven't really gotten time to spend on that. Yet so yeah.

O

Actually I was talking to the client developer and I mean there is a mixed approaches or entertained within the client. So there is no consensus.

O

Even on their end, I mean some people are pushing one configuration, other people disagreeing or pushing the difference, so I don't see in the near future a good, so I be the six solution with the kind so I mean I think what Tim is doing makes more sense and it's more kind of interesting, because I mean it's there already and at the same time, I put together a script that brings Ubuntu based installation of a single node with the ipv6, where you can also test test the IP receive changes.

O

What would really help is actually to merge them, because now we have two based peers on peers on piers and it's not very productive. So the.

B

Idea is that good move requirement is to have to test for each features. That's the reason we and- and we can have a branch we can whatever, but we need tests. We cannot write. Pvc is broken because we didn't have tests so many things that can be able to make. It is perfect. I, don't carry this kind or dined or whatever, but it needs to have an automated test that someone else can produce it and leave it.

N

Yeah, maybe I mean maybe the branch model is the way to go for for this. For this feature and then once we because I think it's going to take a little bit, because we have.

B

Branches, and then we can we can, we can do development on branches. We did this a long time if it's a program of.

D

B

Bar is not blocked in any way and I'm not asking for route of tests and for this PAPR I only ask to have a way to reproduce it, so someone can verify that it works right here. My name is man when I think we can live with it. Since ipv6 is not, you know used by everyone, but we need something at least yeah.

O

If you could check the latest pure I, the second Peter that actually brings up the ipv6 cluster, so once it's merged, then I mean it has no changes in the API or anything it just the script to bring the cluster so once it's merged, then it's gonna be more easier to run the e2e test and to deal because I mean I. Have everything in the same PR. It just doesn't make sense.

B

Didn't have any test and I think everyone who's reviewing Pierre should start doing this because that's a requirement one off to make sure no PR goes in without some testing.

B

Sorry I mean I'd, you know try to be to be hard to do to singular, but that's that's what we've been told that we need to do.

B

N

Sergei with the script that you're doing would would that be potentially runnable and proud because it's just single node and it's just going to set up a local ipv6 interface and and used like calico. I guess yeah.

O

N

Set up overlay, give you six networks. Well,.

O

You know I'm not familiar with the pro if it gives us a vm likely.

D

O

Neol or Bionic, then, yes, we could do it if it gives you actually.

N

Well, so it'll give you a VM that we could. We could use to install.

M

N

Well, I'm, thinking like that, there's a VM for that you guys use for mesh expansion test. We could maybe use that to install a KU bottom. You know have KU bottom run and that environment first single node that.

B

Me what we can we never dedicated VM that is just running ipv6 test and and this updated post to MIT I think that'll be acceptable.

N

The boscoe's pools already have a VM that just sits there for the mesh expansion test. I hope.

B

Someone to have these are supposed to meet tests. Also, my concern today is to, without.

D

B

Everything can be test for stability and I want to have a long running test, so we can qualify it just like what if I was the other features, but is that to be perfect because we can maintain a VMs that is running the latest? And let me take this action item ago and see if I can I can get so one VMs that were a set of VMs that are running.

B

You need that BBC support, extemporary or just 36. No.

N

Just think of notice, okay,.

B

N

Cool, that's all I want to do is just okay.

A

N

A

Okay, so I think we're done for today. Anything else burning.

A

Well, thanks thanks team for the update and thanks everybody for joining we'll reconvene in two weeks by sender.

C