Kubernetes WG Multi Tenancy, 8 Mar 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Multi-Network Bi-Weekly Community Sync for 20230308

Description

Multi-Network Bi-Weekly Community Sync for 20230308

A

Foreign welcome everyone to the multi-networking comics communication meeting and today is March 8th um today in the agenda. I want to touch on a true thanks.

B

You became muted for me when you uh did the screen share. I think it does that please do it.

A

Am I still muted yeah.

B

I hear you now: oh you can hear me: okay, yeah, yeah I. Always do this I think when you do the screen share. Maybe you just have to unmute.

C

Yourself yeah I know: can you hear me now? Yes, okay, thank you all right. So uh first link is by recommendation from Michael I want I created a road map, and this is based on what we discussed in our previous cap discussion. So I want to go over that and then continue our discussion on the API. We started stopped on one of the fields.

C

um Any other points to discuss. Please are the uh add your other item here. If you want to talk about something quickly, the I assume that the API discussion is something that we will take um the rest of the meeting. So if you want to add something just add before that.

A

Bullet point great: uh let me just try again share the other detd presentation that I have the roadmap dancer audio okay, so here.

C

um So I created this deck just to kind of put in one place, the current kind of phasing and more or less when I think we can do it and bear with me on this one, because I am an experienced, completing experience in terms of how stiff stuff can be developed in kubernetes. So this is some very rough estimation of me thinking of what it can take and what it can really be.

C

So some main point is something to for you to review from the offline, but this is just a phasing that we defined in the uh the requirements cap. So this is a copy paste. There's nothing new here. This is based on what exactly the link is here. So, basically just to kind of reiterate phase one is the basic API definition and how we can reference this in in the Pod spec, so um the handles basically have stopping at that phase.

C

Two is making the Pod Network selectively available across the cluster, which will then be engaged scheduler and how we can kind of enable that, and the next thing would be uh cubelet an API probe. So this has to do with today's basic functionality of every part which is being probed by the by qubit and the apis as well so accessibility for those two, the additional multi-network interfaces in the network in the port.

C

The phase three is about extended, extending multi-network to other features like services and for policy, so enabling those things to a port and last phase is some additional extended features like namespace profiles for pod networks and so I, don't have to specify explicitly on the Pod spec, then ability for hot, like an ability, of course, the interfaces themselves and the IPC.

C

So that's something that the phases that we establish in the requirements- if you have some other comments on this, please go to the cap and comment over there. Yes,.

D

I'm looking at the schedulers, we need to become very focused because we basically have a drop every second meeting.

C

um Yeah and and now, okay- let's, let's go through that- okay, now you're commenting on this so and bear with me. Those are some sort of Milestones that I think that we can I hope we can achieve, uh but going on and and I have two years kind of draw out, but I'm not sure whether they are how much accurate they are. I assume. This is very aggressive. At least I think.

D

It's a little bit aggressive so, but it means that we need to work on the reality phase. One and phase two in parallel, probably I, mean to to start.

C

And this is something yeah, so this is something that I want to kind of call out, I'm, not sure whether that's possible or not. uh That's my wishing, but whether that's possible- and this is what I think what you call is, as we are doing- defining the uh DD phases, because, right now, what I'm, considering there is definition of the cap in terms of like I'm, considering this like a design, designing phase of specific caps and as as I'm assuming. This is a track of design. You can visit in this meeting.

C

Is for that part, as we finish, that we can kick off the next designing phase, but that would mean that, in the same time, we perform implementation of that cap.

D

So what I would suggest that we can already you can from this pretty much only the set again. That's for the meetings I mean next meeting. We need to finish the requirements cap after that it needs to be merged right and then then it's really phase one work that we need to break down, so we dominant all of us and I mean I'm really better than getting much done in between the meetings, because I have too many other things to do, but I think we're going to be able to keep this sort of faith speed.

D

The we need to have I mean also project layout sort of what do we discuss on the different meetings and what is expected before the meeting, because.

C

Otherwise, I think, in terms of like the the requirements CAD merge, we had that established, I, I I went through the first round of reviews um right now. I think there is this week is busy because of uh like the release for the next um for the next release of kubernetes. So there is a crunch time on that one. So I'm, not bothering anyone about additional reviews, but next week I'm gonna start pinging folks to kind of get it matched right.

C

So I'm I'm, counting that by the end of the March I, should hopefully get that done.

C

um So so I'm not concerned about the beginning of the year uh in terms of what you think I'm trying what you think uh pair I'm trying to for us to establish the definition of the apis by let's say July or so right, because this is a June here, so basically July August I think this is what I would like to have as deciding on what the phase one will look like.

C

What is the final score so right now, that's what I mentioned is the definition of the apis, which I think we are at least halfway there uh and then definition of how that's going to behave right uh and publish that you say that that's very aggressive.

D

No I just think that. Well, it's aggressive because when it's in time it seems so long right. But if you start counting number of meetings between different.

E

Things they're.

D

Not that they're not that many rights, it means that we need to be focused and I think do some planning. So we know what's expected. So uh that's so.

C

The other so some.

D

Of us, I'm include me right, need to become I, mean you're working, much more full-time on this than I think anyone else right, but there's others that needs to a little bit step up and contribute that I'm, one of them.

C

Full time it's maybe overstatement but I am I am definitely trying to get this uh pushed and maybe- and that's something that at this point we can consider, should we increase the frequency of this meeting, because I think we are at the stage where, where we can get.

D

Or do we have different type of meetings that we have sort of community meeting where we'll discuss this? Our other meetings, where we work on action items and so on and discuss that and sort of Drive the technology forward. I, don't know.

C

I think right now this is, there is not much like, let's say the uh maintenance of the project itself. There's not much I, don't think, there's a lot of work around that one I would consider the main figure of the meetings and discussions always will be around the API yeah.

D

Andrew is not here today right, but for a long time he was having the uh the network policy meetings every Monday and uh just the fact that it was every week I sort of the focus became much clearer. There was not so much remembering what was there to do and sort of so we had.

E

D

Would say a much higher pace from that, so uh fortunately also the number of people that connected every week shrunk because of that. So that is the bad side, but the the continuity. The continuity, is really much easier.

C

Any other voices around that because that that's unexpected proposal, I didn't kind of came here- that this is gonna, come in and thank you for bringing that up, but any any noise on that and it should be maybe increased. The speed on this uh come on.

F

Yep I agree. The first comment so I mean that the this this schedule is a little the more than a little bit the aggressive. If this meeting I mean that we have the only we have the Bible meeting so but then maybe the uh the and of course this is I. Let me double check that this is just a stretch, this schedule. This is not the commit and then after we do not this.

C

Is the SketchUp that's a drug? That's that's correct. This is my first kind of draft of this uh yeah I I I I.

C

Just the main thing is that, and this is what I, what I went through the whole like I, don't want to go through all of it, but the main kind of idea here is that I would assume as soon as we consider the designing phase for the first for the specific phase uh we- and we finish it- we kick off the next phase and in the meantime we do the implementation, because you can see I have a implementation availability defined as well.

C

So that means we do the work as well in the meantime, to do the implementation itself. So this is where I'm not sure whether that's possible, that's something that I don't know.

D

It's that kickoff uh at the uh plan to be at the kubecon or in time with that there is that your second coincidence.

C

No I don't align this anywhere with kubecon I. Don't want to uh the cube counts for everyone's.

D

It's a coincidence. That's.

C

What it is, if it is, if there's some some something yeah I, probably some of this has to be aligned with maybe a specific kubernetes releases, which I did it down here at all. So there is that aspect. uh So probably this has to be better spread out and aligned with with the kubernetes releases, if possible. So I didn't do that here, so so, yeah.

F

Another things is about the, um so this I I feel that this schedule is the. uh It assumes that we do the kinds of the waterfall approach and therefore each phase I mean that design and then the finalized design and the implementations, but I'm a little bit wondering that this style is feasible or not, because the the this API is pretty pretty new and then maybe during the uh design discussions we should testing this API.

F

Maybe we should the other.

E

Thing or some stuff during your design and.

F

Then we should this stuff so currently near this as far as I'm. Looking at this stuff, the uh it's missing me right: there yeah design and they conclude their design and after that we started implementation, but maybe we should the kind of idea overlapping. So.

C

What I'm thinking is here, the implementation would start I assume after we publish the cap right as we defined okay, what more or less we can do. You have you have the time here right in in between uh publish of the cap and the implementation done, because this is availability right. This is where I think it will be finished. So basically I'm fine here you can see I have what is it like, almost half a year to do some sort of implementation because kept emerging so here before the cap merges you can start doing stuff.

C

You can start uh posing what you said exactly experimenting and then, as you have a cap merge, then, when you have already some of the code, you adjust it to the captka being merged, and then you finalize it so that you can merge it for the implementation, um uh Peter I think Peter.

G

Yeah yeah, so I was really just going to say something very so much what tomo said uh so my concern here is: we've got these phases. How immutable are these phases going to be and I think that this is quite reassuring because Thomas said the same in looking at what you've done about Alpha apis? Maybe that's that's true. I think what will inevitably happen is we'll do phase one and we'll get it wrong.

G

There'll be things about it that we want to change later on and so I'm very keen that we do something iterative or we come up with something. That's we could show to people and say what do you think of this and find out the things that are wrong with it and then go back and change it without locking ourselves into.

C

It I I, agree on that. So maybe that's a fair point uh and and that's a very important I will add that so that.

D

But we could still say that you want to add in the following: functionality doesn't say that the other functionalities is not changed right.

G

D

G

Long as we do it in a manner that means that we can change it.

C

No, no I'm quite happy.

G

To to to play ahead of this at the schedule so long as we don't lock ourselves in which I think we're I think we're no I'm just so.

C

That that is, that is true, so uh and that's very important to kind of include that and that's what I'm considering so phases is to kind of moving forward, so I assume phase two. This is where we can start thinking about beta of the uh of the. This is what I'm thinking like. Where is it uh only after phase three?

C

So basically beta is here for the API, so only phase two will be still better, so this is where I'm thinking we should have more or less idea of what the final view of the API should look like, and only after we start integrating with some other features. This is what I can say. Okay, this is V1 because it's already being used by something else, and we have some experience around that one. So, okay, we can definitely say that this is V1 and we can say that the AKA that we discussed today should be fine.

C

So that's kind of my idea, thanks for the that I agree that and by the way the phases doesn't mean the phase will have I'm, not sure whether that's even possible. That's another thing right because the basis I think it's something new here in in kubernetes uh this this release process, where, basically, you would assume um a specific cap being driven to alphabetic GA, where I'm, seeing the specific, separate phases driving this thing to uh to GA.

C

So maybe this has to be better organized in terms of how to fit this fit will fit into kubernetes, because maybe we just have to reiterate on the same cat all the time I'm.

H

Not sure so that's something that.

C

That we have to, we have to think, because you know every every cat has its own life cycle of alphabetic uh GA, where in my case, I'm trying to kind of spread it across multiple camps. uh Tamil, you had a hand.

F

Yep uh so they are maybe their holiday, so so the now I'm looking at the kubernetes document and then the the maybe the the API version is the B1, not the alpha better. At that time. This should be the uh G8 in the equivalents functionality. So so there may be the uh the the.

F

uh How do I say at the phase three is they are still in middle of their desktop, so they are so that I'm a little bit wondering that the uh uh we can say in the ga I mean that as the the version one API so.

H

F

This probably three implementation would be one API variable. This means the ga I think. Yes, that's.

C

It that's the ga yeah yeah foreign.

F

C

This is additional features which will have their own, probably life cycle, and this is truly two years away, so this probably has to be better. Probably next year.

F

Yeah or maybe about this one yeah.

C

F

Change it right to the based on the signal networks. The decision I think so stick Network. What is how they say they are more upper community community will decide the ga I think.

C

For the other, for the phase four features, or what do you have in mind.

F

I mean that the um maybe we should talk discuss about the the RGS. The definition of the Dismount Network stuff I mean so.

E

F

Mean so so the hot Prague or this stuff is also the India uh use case uh requirement list. So so they maybe the uh some of them may thinking that the all use case will be is covered. Then there we can say in the ga. So.

C

That's what you mean, okay, so so.

F

I'm a little bit wondering that the GS definition is matched in the disk case. So maybe maybe this this is the should be discussed in the Sig Network or some stuff. I mean that so.

C

So this is this is so keep in mind tomorrow. This is for the API. If you want I'm, considering the atiga right, um I I hear you what you're saying is.

F

Functionality, but also they are usually usually the uh once the functionality is G8. Then the API is also the B1 I. Think the ADV stuff is.

C

Because, what's your concern is we're gonna rewind, the API, where we didn't look into the hot plugin ability? Still right? Okay,.

F

C

That's a fair point. Yeah! Let me let.

F

Me, yes, maybe that at that time the B1 is not not the B1 here. Maybe.

I

F

C

F

G

My instinct about this is that we'll we'll want to go to GA, but we'll want to not go to GA very quickly, just because this is a sufficiently niche set of use. Cases that we're going to have what use cases that we missed or that require slight changes coming out that were potentially very late, so I'd be very happy to go to Alpha fairly quickly, go to beat, go to Beta at some stage fairly late and then leave it in beta really for some.

C

Reasonable definitely I agree on that. One I, just maybe this one is too fast and I agree with you Tomo, that's that's I. We should definitely push it out. Yeah I will I will adjust that that's.

E

C

Very Point, okay I, don't want to go through the other things more in details. We already completed 25 minutes on this I didn't want to do that. So please review this again and if you think something is too aggressive, keep commenting from specific boxes and what's not um any other general questions to this.

D

uh Yeah yeah one sort of so today there are no apis right, so we're adding API. So we looked at sort of which other groups do. We need a list. I mean we know we need to work with the cni team right.

D

Then we also discussed with the cryo teams and so on, but I think we need to start identifying so which areas in kubernetes will uh be impacted by this so and I sort of own the things that we'll have to change, but we cannot change and I, don't know which phase that should be part of it. No.

C

That's that's as we go I assume that that's a fair point um right now, I'm thinking just as we go, we will see I want to kind of Define the API so that we know what's where and how is going to behave in terms of um cni or any of those. So that's again we are you mentioned that and I'm trying to pull back on any kind of alignment to any of those, because that's I'm considered those implementation detail. It might be done in cni.

C

It doesn't have to be done, Cena her and, uh from my point of view, CNA can catch up and support specific uh apis, this API, but we need to look at the implementation, of course, to have some sort of it, but it doesn't have to be dependent on a specific cni if we can get and we have a micro.

D

I'm not sure it was more like identify the groups right. No.

C

No, but but identify groups that would have to do something for this effort and I, don't consider like, for example, cni to as a blocker for that, because no, no, no, no, that's what I'm getting at right! Yes, I I, like the other thing, would be.

C

We have to change the Pod spec right and how that's going to behave right so I wonder whether we can still just do it or do we have to engage the I'm, not sure who's responsible, but the core API folks, I'm, not sure who's responsible who handling the pods back, but definitely those guys would have to be get engaged right, because we want to change the prospect for for uh Prospect generally to include the uh pod networks in it right. So so, for that purpose, I definitely agree.

C

We have to identify those teams and deal with them and kind of handle them and help get their help into kind of an agreement on on that changes. But yeah, but I agree with you. We need to identify those blockers, blocker teams that we have to work to get this API in okay.

C

um Any other questions to this and one more note, I think this is what uh kind of initially uh why Michael proposed to do this to kind of identify.

C

What should we focus on specific phases- and this is kind of came up last last meeting where we start talking about some things, but we said: that's gonna happen in uh later phases. So that's why I'm trying to as well to kind of point out what we are focusing in this, uh the supporters to kind of the generic API and uh ability for it to be a kind of reference in the pot. So that's how what we are focusing today. I know we want to kind of expand that and whatever we Define today.

C

It's not final. It still just will be an alpha as I mentioned. So as we go with all the other phases, we are going to evolve the API to kind of okay. Now we need this field because we need to support this feature. That's what I'm considering is going to happen in the future, but I want to kind of Focus ourselves on on those phases so that we don't get diverge around on the other directions and we don't kind of uh to.

E

C

Ourselves on on the Target and and as we go along over the time and go and kind of.

H

C

The all the other problems that kind of come on. Hopefully that's.

E

C

Clear all right so I'm gonna go back to our any other. Let me see.

G

Can I ask one more thing, so yeah there's facing there and there's stuff about getting the spec right and that obviously can be done in this meeting. There's also implementation, so one of the outputs of this has to be an implementation.

G

A couple questions on that one is: is that intended to be a final implementation or a prototype or a proof of concept? What's the kind of Quality Bar there is and do we have people lined up to actually write that code, because clearly, that can't just be done in a meeting.

C

So uh I am definitely signing up for that uh in my capacity uh that I'm gonna be available. So definitely I am going to drive that even implementation. So and that's why I said it's an it's a it's a aggressive, uh even though I I created myself but I I. Consider this being an aggressive uh um schedule. I'm not sure, would I be able to do it in half a year either right, because there's a lot and I never did any of this. So that's for me.

C

It would be quite a lot quite new, a few things. I.

H

C

Appreciate if anyone wants to kind of chip in and help, that's that's as well helpful, but to kind of the bar should be. We should have a functioning CI in obviously in option kubernetes, that's the bar. We cannot have API, we don't want to go to the stage, and probably everyone is going to push back on a case where we're just going to create API similar to like what network policies is today where we don't have a full implementation on it in in in in the code.

C

So that's something that we don't want to just do. We have to have a at least a reference implementation for this yeah.

G

And and from my perspective, one of the reasons I'm asking that is, there's a chance that I have some time myself to do some work on this or that I can get someone else to work on this or to or to put a little bit of effort in to help. But um we'll just need to make sure that we get a an ask that I can make to a management line to get some time. Oh.

C

Yeah yeah so right now the the uh as I mentioned right right now. By these this semester, we want to finalize the apis right and definitions and, as we go along, we can, uh or we can start discussing here, what can be our reference implementation? uh Probably next and next next meeting we can start try to look at that. What can be our reference uh kind of project in which we can do the reference implementation? I talked with Antonio. uh He said there is a what he called. There is a cni.

C

He has in kind which is in cluster in the code of kubernetes, which we can just add to and try to build implementation in here to kind of implement all this API there. So that's something that we can definitely look at and that will be like the first thing. I will look at where to implement this.

D

I think Perry had a hand yeah, so a sparkly question to to Shane or a comment from Shane. So what I've seen in other projects that, once you have it's very hard to start sharing and scale up what work is just with the at least for me. Documents like this to sort of start, organizing using git and having a way to come with suggested changes and merging and so on. It makes it much easier for more people to prove I mean to to contribute if we're going to start working on apis.

D

That is some sort of file or files. That I think is easy to work with in uh in a repo I. Don't know what others think, but uh I think we need to go there at some point.

D

um Shane do I, have a comment on it or.

B

D

B

You um go ahead, Doug.

C

And was there a question to me per I'm, not.

D

Sure that was like yeah, so that worked to everyone sort of. When do you think we should sort of start going on more to a repo based approach and then sort of how to be able to contribute and comment.

C

D

C

I think, right now, as soon as we're gonna have some initial phases, a kind of view of the uh of the apis right. I don't want to I, want to kind of establish on this and I think two things this part and then the next part will be. uh How would we? How would you reference that inside the pot I think this is where the starting point can be, how basically the basics you have defined and then start doing something inside the repository where you can change that right, based on that I.

B

Think this is that's what perv was basically saying: right am I missing something. No.

D

No I sort of I I want I prefer to work from a git repo with sort of files that you can yeah.

B

D

And sort of remove easily and uh everybody.

B

E

It it's, you know, a single point for everybody, yeah yeah.

C

That's about the I, don't think that that's the other thing is keep in mind. This is I'm, not sure how that we can be implemented as something that probably I will see for your guidance on that part is. Should we won't that be most of these changes directly in the KK repository? uh That's that's one thing right so having uh I think uh Shane, you have a like a an angular bring up Gateway API stuff. You have your own repository, so basically you can kind of you kind of yeah.

C

It's really nice to have that's really nice to have I'm, not sure whether we can have that here right.

B

H

Not sure, maybe that is.

E

C

C

Maybe okay, but then you still have to change like the Pod repository pod spec, that has to happen in the KK right, uh then the Pod Network API probably can be a separate thing. If we want to consider this being a CRT initially right, though I would prefer having this as a as a part of the core. But- and this is where a shame, probably you can give us some experience, watch which, because you yeah.

B

I know the appeal of wanting to have stuff in core, but I wouldn't do it now, in retrospect, like I, the the not being in core has a lot of benefits in in part of that is velocity. Okay,.

E

B

Especially if all you're trying to do right now is I if I think I'm understanding what Paris suggesting is basically just let's kind of move out of the cap for where everything is and let's have a playground more or less like a place.

D

B

That makes so much sense to me actually I'm doing something in Gateway API right now, where I'm, adding um some prototyping I'm, actually prototyping the conformance profiles that we're working on I won't go into depth about that, but there's a gap on our site. If you want to see what that is and using like build tags to basically make it clear to people hey, you don't actually use this. Unless you know you want to use this, there's some simple things that you can do.

H

B

Sure that everybody has a central repository but you're not like make you're, not you're, being really clear about the fact that you're prototyping and that it's it's it's not something that's going to be stable or potentially even continue to exist, and that's that can be really helpful for some people. I I personally, like that I think that writing the cap or in this in a lot of cases. For me, it's like writing a gap, but then going and kind of building something that feeds back into the cap. You know like it's.

B

The prototyping is part of the development is a really it's really helpful.

F

Plus one all right.

C

H

Other comments.

C

Of this I I put that down in the meeting notes uh yep, something to consider. Probably we can. We can start thinking about like kicking off even a new repository, it's not something that I would start looking into um and I assume there are no voices around I think we are all agreeing to kind of kick off. This I think it's something that we need to point out.

C

um You just stated here.

E

C

Will be acrd any.

E

Objection to this.

D

Will it be a 30 really, the crd well I mean if you're in the, if the incubernetes you're, not a customer.

C

No, this is where this is why what we are saying I, don't think that that's the only way you can have a separate repository around this support network object.

C

We can. We can maybe merge it later on.

G

C

What what uh Shane was saying as well.

D

Right because it gives more flexibility, that's for sure so.

G

Just to be clear, the new resource we're going to make it as a custom resource to start with and.

H

D

It out exactly yeah I'm.

G

Fine with that, as a.

D

Yeah same here.

G

Speed things up, I don't have that.

D

Kind of hands-on.

G

Experience and to know what the impact is, but essentially.

C

So my my mom okay, let me figure it out. What is the impact, uh what is the impact of this and is it possible to transition.

G

Yeah, the the bit that I'm, not sure I understand in this proposal is okay, so the Pod Network can be a custom resource. But what about when we start changing the Pod spec to uh reference is.

E

That does that not require.

G

Us at that point to change over.

F

Yeah I I think I'm also agree with with me with.

H

F

I I mean that's the maybe the initially. This will be the CLD, but at some point they received their move. The CLD as the real, the native object.

D

But then we use annotations from the beginning and then when it's ready to move you change, The annotation.

C

D

No, no! No! No! No! We.

C

Already have annotation that's.

D

The point of this whole thing: I I, agree, but when you use crds, you cannot.

C

Right away, and that will be the consequence so I will I will validate with uh I, know someone someone here can kind of speak up to this, but if not I probably can paint Antonio or uh Fox from my size. I know what will be the consequence of this yeah.

G

So my concern about this is that in some ways, maltes is absolutely fine in terms of what it does. The areas where it's shaky are the areas where the scheduler and and so on, need to have a really deep understanding and where the container runtime needs to do something special. That requires knowledge of networks and things like that, and that we can't do that with crds. So we could maybe do some use crds and annotations to figure out the early stuff and play around and have a playground.

H

G

It has to move into some kubernetes.

J

G

C

Soon, as we've gone past phase.

G

C

Yeah I think the alpha will have to be in in kubernetes as well at least yeah from the get-go right. So pocs, probably we can have something, but then, um in terms of repository, then that we can just create something common for our group temporarily or we can just kick off something for our own personal stuff.

D

So I think we agree when it goes to Alpha in kubernetes. It cannot be a crd, but when playing around with before going there I mean you can use, we can use crds. That's.

E

C

Yes, but that goes down to my you know, because you, you initially started discussion around like having a common place where we can do that right.

D

So yeah yeah, no, it's like I I want to be able to or sort of so.

C

What I'm getting and whether we cannot have done something officially coming from kubernetes, to have something like that, like Gateway.

J

C

Has a centralized place? I've always you know fully flashed repository where they develop and have official, PRS and all the issues, and we then cannot have that. We had to work off of KK anything else. That would be just temporary that everyone can either we can create. uh Someone about. Some of us can just create their own personal repository and then share it with everyone, so we can just play around for the for the time being, but eventually we, the core of the things, will be in the kubernetes repository.

C

That's that's what I'm trying to get the central point of this whole discussion that you were thinking of having will have to happen in KK. That's that's! What I'm trying to get to uh there were some other voice. I interrupted. Sorry I,.

F

Maybe that this could be the as the implementation or design discussion point of video yeah. We should have the first approach. I mean that the first phase we create. We should create the CLD file, and then we do the discussion at automatic cfld. What is directly introduced in the real running recommendations cluster so that everyone can testing, not not the perfectly, of course, but the sum of the testing the uh these API is the physical unlocked and then, after that, the before the uh before. Is it better?

F

So this is just the prototyping of the pretty first phase of the prototyping, but totally, even though that is still using the CLD in the GitHub. It's pretty good to managing each the issue, or some of the change tracking I mean that the the contributor can providing any issues and then also the following any pull request to the Improvement in this stuff. And then this is the good and then I mean that the yeah, maybe the Google Doc, can managing by their comment. But they are, of course, the copy copy paste.

F

The GitHub the running cluster is the awkward anyway, so so the uh I suppose, and then, if and then after there's, some certain I mean that the ones we implementing the core kubernetes I mean that the uh at least as the phase, the phase one we need to have a Ci or some reference implementation. At that time, we should Port uh to this CLD to the area of kubernetes stuff. So.

C

So that will be uh conditions under. Can we then reference such CRT in the pot if we and in a spec I'm talking only directly in display yeah, if we, if that will be a blocker and basically the the folks from the Pod spec will tell us? No, you cannot just reference some CRP. Then we will not do that even for the phase one we have to, but that's the main. The definition of phase one is to have an API and be able to reference it in a prospect yeah.

C

So we, if we cannot have that, then then yeah.

F

So, at that time, after the at the end of their phase, one they are, this object should be in the native the orchestra sketch, but before that I mean that now I mean that the the uh the before starting the Prototype implementations, the of this having the CLD is the pretty good to understanding everyone. I think yeah.

C

F

That's something that temporary.

I

C

Something temporarily yeah.

F

And then also they maybe they're this the design, the the this cap, the Google Doc, is to submitting the pull request at that time they read the we do not mention. This will be a CLD at that time, because the the when we implementing this port Network this should be the native object, not the crd. No, that's, okay, yeah.

C

I think, maybe let me investigate on this one more and then probably the statement will have to go away or I will give you more clarification, yep, yeah, um all right. Let's, let's move on so uh from our last meeting. I think we, the kind of uh stopped on the provider field. What I did here is uh I updated the hold off with the Pod Network naming so now, I think I I got all the spots where it was a network, not the Airport network.

C

So I got those spots a bit more clarification on the uh ipam, just to kind of the two pieces that we have: the iPhone, the external and kubernetes. So I expanded the definitions over here and because of that, I had a comment to what it will mean when specific ipam option is not specified, and this is what I added here. So when it's not specified, that means we do not expect IP on a specific interface from the store Network. So that's what it means.

C

So we have uh basically three options of how this can be configured you can specify uh external and which means you use something outside of use.

C

Non-Built-In mechanism to configure the IP, but you have to configure an IP on the interface you can use kubernetes, which will configure the IP, but using built-in built-in mechanisms, like the kcm's, iPhone controller and maybe cluster cluster cider, something that we have to discuss how the internal will be do because we need to cover that in this cap as well, and then last option will be when you don't specify it. That means that you do not expect any IP.

E

On this interface.

F

Yes, so minor questions, but today is there any reason why you you do not mention the ipb for ibb6 for each description, iPhone, 4 and iPhone 6.. What do you mean so so? The current idiom I pump four defines what is 100 so yeah.

F

Version 4 and iPhone 6 is for IB version 6, but this doesn't Express the uh the explained explicitly so I mean that the you should mentioned that the iPhone 4 is for IP B4 and the iPhone 6 is ypb6.

C

Okay, I see what you're saying uh defines what happened. Oh yeah I see what you say.

E

Yeah, that's me just just okay yeah the yeah. That's a good catch.

C

We'll add that any other comments on this I think this is now clear on what this does and and um what it means.

I

Yeah, um so if the iPhone type is um kubernetes, how does it differentiate from the regular um like regular ipam, which cni uses for allocating an IP to a pod? Both the pods are using the same ifam to allocate two different IPS.

C

No, so so that's what I'm saying this will be expanded today. Yes, today, it's used is just the default one. That's where I'm hoping this cap will change and allow us to configure I pump Network.

I

Are there any like discussions happening on this as.

C

Well, yes, as we as we will get there. If you look at, uh you can look at in my uh I think there is a link in the in the minutes. You look at the top. There are. uh Is there a link, I think I removed the older link, but down the line? If you look at bottom of the dock there is, there are links to. Let me maybe bring this up. There was maybe because you joined just recently.

C

There was an initial draft of this dog, which has much more ideas and I will I will try to kind of link that on the top, this is an old dog that we, uh because now we switch to a new dog to kind of get a clear view of this whole thing, but I will put the link to the old dog in the top of the document so that you can read it again, and this is where I kind of had some ideas on what can it be done and yeah? We will get there. Okay,.

H

C

Yeah, that's that's my idea, that's my so being able to Define pod, Network and being able to uh to reference in the Pod. But this comes with item as well, so I consider icon part of this cat because it has to be there to find right as the default we're heading for the foreign.

C

Just renaming it, if someone has opinions on this one, let me know in the comments all right and and we uh getting back to the provider I think from the hour last week's discussion. We have 10 minutes, so hopefully we can push on um the concern was uh it can be abused?

C

This is not definitely what I want to do so the provider, to give you some more context, what I'm thinking the provider can be, and maybe we should just get rid of it if that doesn't works with us, is definition of who is implementing this network.

C

Basically uh saying I can have five implementers of pod networking in my cluster if they are interoperable, so basically I can have multiple and they all don't bite each other and then basically they can coexist in a single cluster. I want to have ability to identify. Okay, this spot network is going to be handled by the full provider.

C

This support network is going to be delivered or provided by the bar provider.

C

Do you see that or is that? uh Is that clearer, or, and should we or just should we just not allow this, because what I'm trying to hear give the ability of uh kind of that provisioning similar to it think of a Ingress or Gateway I'm, not your gateway gateway has their own classes. They do further that for classes, but in Ingress it has a provider as well.

C

Basically, you have Ingress object which basically can be implemented by very use provider, HTO engines or any other right, so basically depending who's implementing the specific uh Ingress object. That's how the provided with differentiate. You know how you had a hand. You won't say something.

I

Oh sorry, that was one famous. Oh.

C

Okay, uh Tomo yep.

F

uh Almost the things is ugly that but the one one, the one one question is about the uh the: what does it mean? Is the provider is empty, so.

I

H

F

Is now is the operational so so.

C

I will uh so this is to so. This is up to the implementation right, because implementation can do this. Implementation can say: I will handle only the ones with the provider X or my name in the provider or I will handle all the that are empty.

C

There is no provider, so I handle them all, and then, if there is other implementation doing the same, then you you are not, inter or inter uh you're, not compatible with each other, but it will be up to the implementation of whether okay do I handle empty ones, and my name or do I handle only my name.

C

I think: that's that's what it would mean so.

F

So this field is only concerned by the uh non-core kubernetes component. I mean that yeah case em or cubelet do not care about this.

C

No, those those completely because this is all about the downside right so who's implementing the yes, that's correct! This is only for the um for the implementer to to worry about this right.

F

So should we add the omit empty in this Json notation? Oh.

C

Yeah yeah sorry message: yes,.

C

Any other questions on the provider cap you had you had a question: does that I? Think uh last week someone had a last meeting. Someone had a concern that then someone cannot use this and say: oh I want to use and they will reuse this as a indicator of uh like, for example, oh I want to use macvillam here, that's my provider, and they will consider that the event or but just the implementation as a provided right. So it can be. The skill can be abused.

C

F

But another concern is about the uh this.

F

How they say this cap accept, allows the users to launching the one or more provider.

F

uh uh I mean that uh I mean that okay, let's imagine the uh um okay, the amount us will provide the provider okay at that time, they we the models provider and then maybe in that in additions. The exam I don't know, maybe AP, okay, AWS, the AWS is also provide provider provider, so they sometimes the user creating their cluster in the AWS.

F

And then we they running the models provider as well as the AWS provider and then based on the disk provider field, the uh um each provide each smartest provider watching this profile field and then the if this.

C

Program exactly that, yes, that's the exact example. Thank you total, but exactly for that purpose. Yes, that's that that's what this field is for, because otherwise, if we don't have this field, the only other way to uh to differentiate between that would be through the parameters reference, but what if a implementation doesn't have one? What's then right? So basically, if there is no parameters, reference kind of introduced by the implementation, how they would differentiate between, do I handle this or not.

F

So I'm this is just in my the the kind of the feelings, but today I'm I'm thinking yeah. We are likely to writing the some architecture section or some similar section which uh uh describes the uh in this proposal.

F

The which component will be introduced I mean that the not the introduced but the India kubernetes, but they are this, expect to the uh some provider and then the provider may co-exist. Not only do one also, there are, several providers may exist in the one one cluster or some otherwise, sometimes the leader May getting confused because the society, the kubernetes, assumes the one provider because they bought the single interface.

F

So sometimes they may have such assumption and then reading, even though that is describe the mode interface at that time, that they're still thinking that one provider is only allowed. So maybe we should describe the some I, don't know, architecture or some stuff in some section. In this case,.

C

Around which part how the providers would look will work. Is that what you references towards to what we just described.

G

I certainly think this is a little bit subtle on having it written out in more detail with a few examples.

E

Yeah very beneficial.

G

E

Yeah I will do that yeah.

F

Yeah, maybe the example is next uh makes sense, I think.

C

Do maybe maybe I will ask differently? Is it something that we should have it in an outcome original all right?

C

Should we just that habit, don't complicate things, keep it simple.

H

We probably shouldn't have it until there's a actual customer need, or you know, benefit to having it.

C

There is that so anyone because that's maybe unnecessary complication, which basically this is just a field it wouldn't it will be only complication of because we have to kind of additionally explain it, but in terms of implementation, it's just a field for the implementers not for, for it will be only for the implemented, as Tamil kind of pointed it out. It will not be the the core that we plan to change will not touch on this at all right. It will won't react on this coffee, so this is just the field, but explaining it.

C

It took us like 20.

F

Minutes so, and then also the uh this provider is related to problems ref right, so they are proms.

E

F

Or implementation, maybe we should be mention that the.

F

Of the providers uh object or some.

C

Yeah, that's that's true, but uh any any other voices on what Michael mentioned had suggested opinions. What.

J

Is the alternative, if you have more than one um provider how? How do you difference between them? No.

C

This is the only way this is. This would have to be, but question is: do we have to tackle it right now, or can we postpone it to? Let's say someone will come back and say: oh I want to have those two providers in my in my classes and I want to support it. That will be. We have to create a cap and expand the object and all that the whole process, but we don't have to tackle it right now. That will be the the the because there is no other way Lars.

C

If we don't provide it, there is no way to differentiate.

J

You cannot have a defined label.

C

You could probably go with that, but that's yeah that will be better to be a performance right. It's always an annotation or something right.

J

No annotation is no good, you have to be able to filter on it and you have to be able to watch only your exactly.

E

J

That must be a very special field, because you cannot do that in like anything right. So that has to be considered.

G

J

Free, if you have a label.

C

Yeah or or this field right so I think, let's keep it I think it might be. Cheap I will add the description of what it means. uh I know with functionality wise it's not something that we um gain much here, but but I think we are not opening this object to now kind of I I want to put labels and now that's how I want to differentiate. So let's try to avoid that and let's have this field. I, don't think it's.

E

It's all right.

C

um I think we're gonna move on I already take the Liberty to cross out the routes. uh This is something that we can decide or I. Think we, what period? What you said here and I think this is kind of implicates what type of network it is. If you have browse so I agree. This should not be part of this object and I'm cutting this out. This should be part of your implementation details, uh parameters, ref uh inside parameters, ref. If you want to kind of provide some.

E

Additional stuff.

C

Here any comments on this nope I think everyone's agreeing on that and uh just gonna mention it. But I don't know what to discuss the.