Kubernetes SIG Network, 15 Mar 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Network Plumbing WG Meeting 2018-03-15

Description

Kubernetes Network Plumbing Working Group meeting 2018-03-15

A

All right, we are now recording, welcome everybody to the network, plumbing working group meeting for March 15th 2018.

A

So if you take a look at the agenda, it's mostly I did a few spec updates, not too much I have an item at the end about question. I had with those updates and then also Doug has been working on implementing the spec in the multi CNI project, and he has a number of questions and issues with implementation that he'd like to bring up and talk about so to kick off.

A

I reworked Doug's text to formalize both the network selection annotation formats, which is what we agreed on last meeting that we would try to support both one question that I did have for that was: are people okay, with using the same annotation name for both formats? Or should we change the annotation? So you can either specify the simple format and or the extended format, but they would have different annotation names.

A

It might make it a little easier for plugins to work with I. Don't have a strong feeling either way. I could.

B

Go either way too, although I there is some merit to having annotation named for either format, just in terms of error, handling for the meta plugin, so I'd be open to that as well.

C

I'd be able to do it if we don't spend all day by hitting the names for the to of annotations yeah.

A

Fair enough, we've kind of been putting off that naming anyway for the moment.

A

Okay, well, if nobody has any thoughts right off the bat I mean the only ones that I had were networks and then like network lists or something like that. I mean I, guess they're, both lists, but.

D

Net will config for the advanced format I.

C

Mean look here goes right, I mean if you're gonna name things. You know if you have two different names for the same thing with slated formats. The difference in the name should indicate that it's a difference in format, not that it's a different thing. We.

A

Could do extended networks, for example,.

E

I'm second, on that, because yeah so country, the meta Pro, we also are the default network. So the ADIZ, a notation, is the all for secondary network, so I think Pia, but.

C

That was ice point right. Both annotations would be for sidecar networks. The the my concern was that they should see like two different ways of saying the same thing. They should indicate in the names the difference between the two different ways of listing your sidecar networks, yeah.

F

A

I guess the real question is: isn't that big of an issue for plugins to try to parse the format for both of them? I know it's probably not in go. It wouldn't be that big of a deal and go to parse that but for other languages, maybe it is but I don't know, I. Think my general feeling is: it's probably easy enough to parse. It's just a question of clarity in the spec yeah.

G

I think it's easy to fart like out prefer keeping the same thing like that was my suggestion. So I don't mind just keeping one thing and keeping and no on okay.

B

It may be easier for the user to that. It's just always the same name, and then they can chuck whatever they want in that field. Alright,.

A

Fair enough fun that sounds fine to me, so we'll go with that will keep the same annotation name. The next thing that I added was I realized. There is a gap in how we were talking about IP requests and Mac requests and that there was no way in the specification or the specification didn't say anything about how those actually got sent to the scene plugins. So I added a section there. The only gap that there that we have is that there is no way currently to pass a MAC address into any of the CNI plugins.

A

Well, let me correct that there is a way to do it, but none of the plugins currently am implement that way. Anybody could implement that in their own plugin. So there's that outstanding question. You know we could implement that in the CNI reference plugins, and it probably wouldn't be that hard to do so. Be aware of that, the way that this would get passed down to the senior plugins that I identified would be through the conventions document and that's the way that IP address requests are currently passed down to the plugins anyway.

A

So it seemed like Mac requests, can go the same route and there's some text in the document about that and a link to the CNI conventions document. The last question about that was that there is no way currently that plugins implement to indicate that they can actually handle the IP and Mac requests.

A

So you would essentially be sending those into the void currently, unless you knew that the plug-in that you were specifying actually supported those, and so what that would probably require is an update to the conventions document, or we could also define a de-facto capability for CNI plugins to say that they could do this, and that would probably be fine to carry through to CNI. Officially. Is that this issue unclear to anybody? I can go into a little bit more detail before I hand over to Doug.

A

Yeah sure so I mean as we've defined it. We want to at least allow plugins to or excuse me allow users to request specific IP addresses and MAC addresses for the network attachments and the way that happens is it gets passed through the CNI Jason configuration through the args program in the Jason configuration, but there is no corresponding capability that AC and I plug-in advertises to say that it actually supports that right.

G

My question was like: what's the issue, if you shoot it into wide like that was my question, so it.

A

Doesn't support it currently, plugins that don't understand the IP and right, why stuff would just assign a different IP address, and that seems like the wrong expectation. I feel like if the requests a specific MAC IP address, that the plug-in should either allocate that address or and assign it to that network, or it should fail. Okay and again it's it is only a convention.

A

So the way that this would theoretically be solved is that if you know that the network plug-in that you are implementing that will be called by the meta plugin does support this feature. Then you would add that capability to the configuration or excuse me to the Jason that lives an Etsy CNI net D for your plug-in or something like that. Most of this is described in the conventions document and then, of course, you'd update your plug-in to actually respect that and look at that argument. I mean it's config the only missing bit.

A

There, then, is to add to this specification that the meta plug-in should look at capabilities that are in the Jason of each configure config list before it actually runs that network attachment, and if that plugin does not support.

A

So does that make more sense, suresh yeah.

G

It does like, but it's only half the problem right like because, let's say I do my plugin doesn't understand, but it's like unable to allocate this address like or unable to assign this address. Like that's another error as well right, you need to handle yeah.

B

G

Okay, so this as long as there's like yeah, it's not a two-state thing. It's like a three-state thing, I'm, okay,.

A

Yeah and I mean the way that I had sort of worked around it. Now in the specification was that the meta plugins should ensure that the requested, IP and Mac is actually returned in the result structure from that config when it actually executes that config, which is kind of an icky workaround, because it adds more code to the meta plug-in. So we probably don't want, and we and of course that would happen after that. Attachment had actually been run. You've done all the work you delegated everything and so that that works, but I think we'd.

A

Rather have that check happen upfront before we actually call any of the attachment stuff.

C

This is not. This is a two-state thing. This capability is it yes/no capability, not I, guess no meanie. The issue of not being able to assign the requested address is always present and has to be handled differently. That would be handled as a error returned from the plane after it's invoked correct right.

G

Like so my point was this right like so anyway: I need to go and check the result to see if my requested a doesn't got assigned or not right so like why don't I just check it and be done with it? Why would I check for the capability? That was really my question. Sorry yeah.

A

I mean that is valid. You can always do that. It just seems like more code and we'd rather we'd prefer, probably to trust that the meta plug-in and the other plug-in just does the right thing, and then you wouldn't have to do all this validation on the final result.

G

Okay, but I still have to handle the runtime errors right like that.

A

Yes, yeah I mean at this point at least the runtimes or the meta. Plugin. Probably would just take a look and say: okay, this chain returned an error, fail everything and print some message somewhere, as opposed to you know, at least kubernetes doesn't actually care that much about the errors it just logs them. Okay,.

G

Like I do see is like a simplification. Yeah I just want to make sure that you're not doing extra stuff when one is not needed, but I understand, like you know, simplifying go somewhere else, make sense.

A

All right so I will take an action item to update the specification to add that capability, and then we can probably reflect that through to the CNN conventions document as well. So at this point, I will turn it over to Doug.

B

Alright thanks Dan yeah, as Dan mentioned I've, been working on implementing the spec using multis going off the branch that crawl had started a while ago, and we've been able to implement a few things and hopefully we'll demo that maybe the next meeting or somewhere around there. So you guys can kind of see like the likes back in action.

B

Well, as we've gone through that a couple of questions have arisen for us and anyways. These are I think these are kind of finer, strokes and I'm, hoping that these aren't super difficult to work through. But here, when I just hit him up one by one. So the first one that I ran into is that the annotation name.

A

B

Had penciled in there it doesn't match what kubernetes wants. So it's like domain name, slash the one virus, flash version, slash name, networks right and cute when I went to implement that cubes like hey, that's not what I want I just want DNS name, slash thing and so anyways I was like. Can we just drop? The v1 I noticed that Dan added in here the idea of putting that version before CNI dot, CN CF, dot, IO and I liked that idea, I guess I would say.

B

Maybe we could do like, instead of maybe alpha beta etc. Maybe we could do just a well, maybe- and that's not so bad, but if we did something like the numeral dot, C and I dot, C and C F dot IO it make it easy for the meta plugin to scan through like previous versions, so you could like put in it like this is version 3 and I'm backwards compatible with versions one two and three.

B

That would be one idea, but anyways I wanted to bring that up and see what people had to say about that particular version in the name and knowing the limitation of it.

A

Nope I mean your point well taken. I had just penciled that stuff in and you've obviously found that it doesn't work so I'm perfectly happy to change that.

B

Cool yeah so- and you know, I'm happy to update this back with that, as well with the numeral, for example. If anyone.

A

B

Input, that's awesome, otherwise,.

A

Okay, so I had just typed into the oopsy F dead. Okay,.

F

A

Just type into the agenda I assume that's what you're talking about it would be: kubernetes dot, v1, dot, C and I dot, C and C F dot, io / networks. You know that looks.

A

Any other thoughts from anybody is that format. Look okay,.

A

All right in the app okay awesome all right: let's just go with that, then Doug.

B

Alright, this next one may be my own misunderstanding of something that I might have missed earlier along, but this is regarding the multiple uses of the same network attachment. So you know if you had in there, you know Mac VLAN,.

A

B

Vlan, for example, or flannel comma fling. Alright, so you say: I want to attach this twice and I. You know I know Suresh had suggested. The idea of you know like network attachment name.

A

B

Name so like Matt VLAN at Eastside, for example, and I like that and I, don't see why we couldn't potentially support that. But you know, as I was going through and testing it. I was using multi I noticed that what multis does is it basically generates a name. So it's like net 0 net 1 net, two et cetera, and so you know it's.

B

It's not exactly part of the CRD, but I was thinking that maybe we could update the language of the spec to basically say that you know the the meta plugin is expected to create a unique interface name with each attachment that comes along, maybe unless otherwise specified. If we do, you know, go forward with attachment name at interface, name, yeah,.

A

I think that's probably pretty much required.

G

Yeah I, like it too,.

A

So that's I mean again that's one half of the problem.

A

The other half would be the issues that we've discussed before around CN eyes: uniqueness, tuples and things like that, which would be solved by suresh's suggestion for the moment.

A

Are you any thoughts on that Mike or anybody else? This would imply that each separate attachment to the same network would get a different interface in the container.

A

And just to clarify this does not prevent multiple IP addresses being returned in the same attachment. So.

C

For those of us who are working with network interfaces, I think that's totally expected in normal I. Don't remember where we were I know. It has some concern that we don't necessarily have to want to pin this down to making a network interface.

F

So one question is that how do we deal with the cases where we have a user space? Networking stack and there is no sort of kernel network interface to use.

A

B

A

B

Yeah this is this is a really good point, so maybe the language should be updated to say in the case that interface would be created. It's expected that it would create a unique name. Otherwise, yeah there are cases where you know you. May you may not need that interface name whatsoever.

H

Is that as a recommend to create the uniqueness for the same network? Actually I was in vacation for eight weeks. I missed a lot of discussion on this one, but but I'd like to understand why we need to create a unique interface name for the same network. Actually.

C

First off for now we're talking about network attachments and the whole issue comes up, because some people have used cases for multiple attachments to the same network.

H

Okay, but in this case we can add something like ds2 is created all right.

C

So I might a follow-up question on the case of not using a network interface in the case of using DP DK or something like that. Is there some other sort of thing that also needs a name.

H

Currently there is a hack we having in the DPD kv, currently requests an interface name actually. So there is lot of act for the DP DK regarding that, but we need an interface name, because if you have a part which have like three or four duplicate in two interfaces, then we need a uniqueness there. Yes,.

C

I would expect that so actually I think you think something which actually doesn't surprise me very much, which is even in the DPD k case. You actually do have a network interface. You do have.

A

C

Management reasons and accountability, identification reasons, yeah.

A

H

A

The question that I have is: is there a case where we would not want to use different interfaces for two different attachments to the same network? I.

C

Don't have such a case, the.

I

Only use case I can think of is if you want to have bigger throughput, so you want to have two different interfaces, because you have some limitation on there. You clearly want to have different different interfaces.

C

That's okay. He was asking for the opposite breeze, where you want the same one network interface for two different attachments: yeah.

D

I think that that's what Peter said that you want to eventually aggregate the attachments into one logical device, but I think that should be done on the containers, because it's application.

I

Yeah yeah, that's what I'm saying is I think that's the only case we would ever want is the container do it or the whole thing from my point of view, is push all the network complexity into the container. If there's some crazy stuff, it wants to add multiple network devices in DB tikihama. To look the container worried about that. Just set up the physical harbor for it. You know: C&I sets up the interfaces, but nothing beyond the hand.

C

Yeah so I mean we have this concept of bonding. The question is: doesn't container normally have a privilege or their capability necessary to do the bonding that.

H

Is a bonding interface? If you see there, it's a third parties in a plug in actually so for the morning it requests the interface name in order to create a link, aggregation interface or something like 1 0 or something.

A

Well, I think for the moment, let's just go with essentially what has posed and add some language. The specification saying the meta plug-in should ensure uniqueness of the interface name for each attachment, and then, if people can come up with situations where the same interface with host multiple attachments, then we can update the spec either before we finalize it or in v2 or something and I mean you can always sort of work around it in your unplugging. If you want to by somehow detecting that you want to attachments from this one invocation.

G

Yeah I think it's a fair way to do it. I cannot think of any any such like use. Use case like personally like and like I've done a lot of crazy stuff like and usually like either you like either bond in one way or you do you sub interface it in some way right and then that's how you do it so I, don't see why that's required I.

A

Mean the only thing I can think of is you know, maybe more Sdn type interfaces or plugins that we use only one interface and multiple IP addresses and each IP address comes with a different attachment and then all of it is handled by you know some kind of switch or v switch behind that interface, but at least I don't have a use case for that right now. So yeah.

G

Like still the the the V switch, like kind of, has like a bridge where the interfaces show up anywhere, even in those Sdn use cases so like. If you look at OBS like it'll, be still like you'll see the interfaces so yeah as I say like okay, if somebody has that let them proposal, let's, let's our output, it right like I'm sure if somebody needs it, they're gonna, scream, yeah.

A

And it works for me: does that work for everybody else and by that I mean go with the language about uniqueness of interface.

J

A

Attachment and then we'll see if innovations later.

K

Question your comment, Dan regarding the uniqueness problem, where you, where we you know saying I, has the limitation that our name plus container ID is you know, determines the uniqueness, so certain sea and ice may support multiple attachment where others don't. So. How do we eventually solve this problem? The.

A

It could be theoretically solved by adding interface name into the cni spec, as a third part of the uniqueness I did bring that up in the cni maintainer z' meeting and most of them were kind of ambivalent, so I mean we could continue to try to push that.

A

The only issue is that the current plugins that are out there are only required to use the container ID and network name as their uniqueness, and so it would take a spec update from CNI, but then also we'd want to make sure that the plugins that people would want to use with the specification and multiple attachments, also conformed to the that CNI spec version, so I mean I'm, not saying it's impossible, and it's actually not that hard. It's more of a spec and social thing, as opposed to a technological one.

A

K

But you're saying this will be solved in CNI context, not here right, no.

A

I'm saying it could be solved in CNI context, given.

J

That it's stronger right. We would since we're using CNI, it needs to be solved in the c9 context.

A

Yes, we would like it to be solved in the CNI context. Let's put it that way. So I will take an action item to bring this up again in the next scene. I maintain errs meeting and talk about that again. Okay,.

K

And just by I, think using name is is a pretty bad idea. I think we should. We should come up with IDs right. There should be either your ID or other things, because just because interface name itself implies you're using interface right, yeah.

A

Animate, as far as I know, I think the interface name is currently required for CNI, even if the plug-in doesn't actually care about it sure I mean essentially if it is required to call add with the interface name, and if that interface name is present, the plugin must honor that name mm-hm so effectively. The plug-in has to honor that name. If it uses interfaces at all all right, so, okay, so I'll bring that up. Doug will update the spec with wording about multiple attachments and interface.

B

A

All right: okay, Doug default networks, okay,.

B

So yeah default network, so there's a blurb in the spec that you know I make sense to me. There's just something: I think that maybe we can clarify a little bit and that blurp has to do with tacking the pod to the cluster wide default network. So what it says is the meadow plugin must always attach the pod to the cluster. Oh I'd default network keeping the existing communities behavior. This behavior currently consists of selecting the utf-8 alphabetically.

B

First vigo string, sort method on file names, valid CNI, Kampf or dot-com list, and Etsy C&I net D. So you know I get the gist of it. Is we're gonna attach to the default network right and then and then we're gonna add the side cars on given?

B

What's you know, put in the annotation, the question is coming up for me is well you're gonna have the alphabetically first config name: B I would assume the medical again so that you have the configuration for the meta plugin and so that kubernetes calls the meta plug-in, which then delegates to you know the other plugins that it would use to create.

B

You know multiple network attachments, so I was thinking that you know, maybe, though, like just most simplest way to to handle this, and this back is to say, since this isn't exactly related to the CR DS is we could update the wording to say the meta plug-in.

B

Will you know have its own method to define what is the default Network and you could just leave it to the meta plug-in to define? Otherwise you know we could you know more strongly suggest it. So you know the things that came to mind for me. Is you know the way the mostess does it is? It has a way to embed more CNI configurations inside itself. So you can say: hey here's. You know your default Network. Essentially, so you know the way that Malta operates today.

B

It says, oh there's nothing else to attach here so I'll attach it to you know what you specified is essentially the default. You know in this case it will work a little bit differently, that I'll attach to that both the default and then to the additional side card networks that you said I'd like to attach to so that's one way or another thing is, we could say, pick the next configuration alphabetically after after the first, so I was curious.

B

What people thought if we should just word it softly and say it's up to the meta plugin or if people have a stronger opinion about this and think that there's a you know way that we should. We shall specify this I.

G

Don't mind either but I just don't want the you know the next alphabetically next one: nada, tor, okay, all right cool, yeah, I'm,.

B

Not super hot on that either, because that would just mean you know, he's picking the second yeah.

A

I'm not super hot, on either. However, it goes I mean. We've got all the documentation about that. It seems well known that this is how X networks I mean more or less, and the the only other suggestion I had was that the networks could go in a different directory. So whatever the meta plugin is, will have its own directory for C&I config files, and it would be its own.

A

Config would be the only one that kubernetes sees and then it would look for its network def missions in the other directory, but I, don't like that one as much either, because that means that plugins have to know to stall their files and some other directories somewhere, and none of them currently I.

A

I

Like that one in a lot of ways, because what I'm a bit nervous about is, if Malta, the Maltese plug-in config file, ends up having lots of subsections for all the different networks it needs to know about. That feels a little bit fragile and a little bit complicated as people are adding new plugins to say it. Oh I've got a new network that adding a new network process feels like it might get messy. I mean I. Think I probably live with everything. That's been suggested so far, but my instinct is trying to avoid that. Can.

A

You elaborate on that just a little bit more.

C

I

So maybe I've misunderstood what's been proposed, but as I understand it, the Malta's plug-in has got delegates and those delegates in it have got the conflicts stored in the actual conflict from moths. It's the Malta's config file is that right or if I misunderstood how that works. So.

B

Yeah, the gist is just that yeah, the delegates field. There is just JSON within that field that defines either a single network or a list of them in the case of in the case of Malta as it operates today.

B

So, let's say: let's, let's just assume and I guess this is another topic in and of itself, but is the default network likely should be singular? A singular default network so you'd have this field delegates with just another CNI config packed in there. So in the case that you should change your default network, you would just replace that single file with a new one that has your new embedded CNI config. There.

I

It's one file with a convict for every network that multi snows about.

I

All right, but.

B

That's all right, yeah no worries. So it's she. The delegates field is a single statically defined network. Otherwise it uses CR DS. As you know, we've specified here. You know in its own way as it was initially invented, and you know as I modify it to conform to this specification. So that's it does that the CRD method here provides, for you know a more flexible and robust way to add, update and otherwise specify all.

A

Of the network's.

B

That it knows about through CR DS, but as far as a default Network, though the way that multiple originally written it just has the delegates field for, in its case, one or more networks that would be used as a kind of default, and maybe.

I

I'm not answering.

B

Your question great: no, actually that was much that.

I

That clarified something I think I could got confused about how Moltres works. I've used it before, but I. Don't forget a little bit backwards right, I'm, gonna, I, think I don't actually mind I! Think all of these are plausible options. I'm gonna step back and see what everyone else thinks.

B

Very nice thanks Peter I.

K

Think packing the default config into the multis configure self seems fairly clean right, because then you don't need none of another file. Just for all this stuff, yeah.

A

That said, if you're running the other plugins as daemon sets, you have no idea really when they're ready, if I mean currently the network readiness scheme that Cube has is. It looks for a file and at CCI net D and once it sees that file, it says: oh, hey,.

J

A

Network plugins ready, so what daemon set-based plugins do is they will do their init, do their setup and then write that file out only when they're actually ready to process network requests and if you pack the configuration into the multis config first, you have to first, you have to have the looking that you want is default to somehow either update that, or maybe the readiness wouldn't happen same way. If that makes me right.

K

Yeah there has to be a read newsletters.

C

Yes, yeah: how does readiness work with delegates today anyway? It.

B

Doesn't know about that at all, but the way that I've worked around it myself is like say: I'm gonna do flannels, at-fault, Network and flannel. You know the like suggested way that you deploy is with a daemon set and I have just created the daemon set for flannel and I've just said: hey, oh yeah, as part of the statement set, you're gonna output, this flat config file and I've just made it Moses's config file. So by the time that flannel is already, it just writes a Malta's config file with flannel packed in it.

B

A

Clever but I feel like this little backwards from from where we want to go but again.

J

A

A great option here with current cube how to do readiness with Malta's, because I'm assuming Malthus, would write out its config file, either immediately or I, don't know. Maybe Malta's could do its own checks to see if the default network is ready and then write out its config file.

H

Except the danced ideas like higher, also at the issue of it finished start running. Some tick plugins like courier, so I have the same issue which Dan is trying to explain here. Yeah he's correct on that. So.

C

Just could change its mind over time about which to use.

A

If it does, it shouldn't I think over time.

A

Let me go check that out I'm.

B

Pretty sure that cue reads that config file on the on the fly and uses I think.

A

Never is automatically.

B

First and then just as a I'm gonna.

B

A

The question is whether it does it once at startup or whether it does it continuously, and it does do it at startup, and it actually also will do it. Every 30 seconds from the cubelet status news. Okay,.

B

So it's on a 30-second loop, okay, interesting yeah,.

A

I mean what that does mean is that if you get I think Mike, it does mean that the network can change which seems kind of wrong.

C

Well, I think, at the end of the day, what we need to have happen is that all the network plug-in stacks that we want to use is ready before anybody tries to use it.

A

Yeah I think that should happen at least for the default Network, because obviously that one has to exist for all pods for the sidecars. It seems a little hard to figure out when readiness would work there, because you could add those CRD based ones at any time, and so there's no real way to say. Okay, all of our networks are ready other than the default which more or less needs to exist. Before we can do anything.

C

A

I mean one thing that we could do here is for now. We could say that the plug-in gets to determine its own default Network and that it should not write out the meta play. The meta plugins should not write out at sea and I config file that will be recognized by kubernetes until that default network is ready and kind of leave.

A

That mechanism up in the air for the moment and then come back in two weeks and try to hammer that out a little bit more since we're kind of running out of time in this yeah.

B

I, like that, I think that it's probably pragmatic to to probably say something along the lines of here's. What should be done and to note as a further issue for version two, because I feel like it could bleed a lot. If we say hey, we have to figure out all of this like what's necessary for readiness and maybe leave it up.

B

You know how that installation step is handled for now. Look could.

C

You help me I'm go through that a little bit more slowly. The work run. You said you doing now. Now you.

B

Yeah, so what I do is and I'm just using you know how flannel suggests you should install it now, where they give you a daemon set and inside that daemon set is C and I can fake, packed packed into it, and it writes that config out to disk at the right time. So by default it's just a flannel, 16 and I can fake right. So the cool.

A

B

A

I just replaced.

B

That, when the mold is configured side right, the trick is that it's something other.

C

Than C and I readiness that, between your code to created the file that indicates see my readiness, so that's how it gets untangled, okay,.

A

All right added some notes: the spec and there's not specs. Are the agenda and assigned that task to Doug. So Doug gets to update the spec with some placeholder stuff about the meta plugin handling to default. Ness and readiness that worked out good yeah.

B

No, that sounds awesome and yeah I really appreciated the input on this one, because it is, you know, there's the potential working place. Yes, so appreciate that everybody for sure.

A

Alright see next up see potentials short demo for device plugin for host device, see and I plug-in integrated with network CRD, and then Corel also has a small topic or topic about chaining mechanism support Corral. Do you think yours will take a short amount of time, yeah.

H

A

H

So I just want to discuss like two minutes on this training mechanism. So I have a use case in which I have to enable the SRU interfaces and after that I serve. For example, I saw we see a CNI and then, after that I we create like two interfaces of SRP and then after that, I will invoke the bonding seining using multi and then bonding CNA will use these two interfaces and create your link, aggregation interfaces so way in deletion.

H

It should happen in the reverse order, like the bonding interface should be deleted first and after that the SRV CNA should be deleted, and after that the final interface should be saluted, but currently in mulches multis doesn't work in the way like what I suggested right now. The multis will go for the default. Network built the default network first and in then it goes for the other networks.

H

So this was me and problems who I made some more current, so that from ulta still called multis, so that issue has been solved, but this particular thing really is not capturing the documentation. So I want to make sure that people understand this. There is a use case around this one, so, while deletion it has to go through the reverse order.

H

A

This see an ice pack for conflicts at least specifies that everything should get torn down in reverse order. I think what you're talking about is cross chains or would all of this stuff be in the same chain like? Would you have one in the same CNI conflict Jason? Would you have SRO v, 1s r, io, v, 2 and then bonding is 3 yeah, yeah, ok, but also Malta's currently implements its own conflict sort of chaining support right, yeah.

H

A

One of the things that I kind of wanted to do, or was hopeful about, was that the CNI, Lib, C and I code could become flexible enough to actually be used by multi-source Ian I Jeannie. Instead,.

J

A

Basically rewriting their own code, and that would help as well for injection parameters, because lib C&I has its own code for injecting updates and the previous alt, and things like that. That's a way to fix this in multis, mystical over to the Lib C and I code for network.

H

Okay, okay, encoding.

A

Okay, it's a thought and I see and I live C and I would be open to PRS or changes to make it more useful from other plugins and I have actually in the past, discuss with other CNI maintainer z-- about having hooks for plugins like motifs or CNI genie, where they could register to be called in between each plug-in invocation in a conflict, which probably would be what you want here as well. Okay,.

H

A

Alright, so on to Peter, you might do your shirt demo yeah.

L

Sure let me share my screen. First.

L

Can you see it yes,.

A

L

So I want to present alternative solution for you, that's for funding again. It falls out previous bridge. Plugin I showed that, unlike the bridge plug-in this time, it uses the network object and also it uses CNI on the background and I hope that this example will make the resource based solution work here.

L

So this time, I implemented device plugin for host devices, backed by eros devices and CNI per game, and the workflow should look like this first administrator of clustered specifics networks as Network subjects, with their name resource name, which in balance this nice work and some additional configuration for the device plug-in or maybe you even the C&I- are configured Sigyn, CNI network configuration and then still administrator configures, the his networks on notes, in this case for the host host device.

L

Each interface is mapped to a network by its alias, so there is an alias Electra and when an interface on the note has this array set, it will be mapped by the device plug into this network. This is a bit silly and it requires administrative. We trade each node and configure it, but it can be it which will be replaced by LD selector and then it can get more interesting.

L

So this is for administrator part and in the user, in the the user uses the annotation way to select networks. So you say: networks and list networks based on network object names. Then the initializer will came into place. I mean I used initializer just to hold fire it's, but it should be replaced by definition, controller I think so. This is just for a POC and would initializer ask it to checks the list of networks. It looks.

A

L

It's very subject, and if it finds the network, it will use its resource name as a resource required by the pot. And for so.

A

Just to be clear, really quick, the box you currently have selected and the resources listed there. Those are the things that you say, or you said, or for the POC with resources, yes, yeah, okay, so those those would not listing the resources required for the networks in the pod. Spec would not be a final implementation.

A

L

The user specifies the list of networks and annotation, as is discussed in the network proposal, but on the background it will be translated to a list of required resources and it will be placed in a site container or something like that. Okay,.

A

So, to be clear, the Box on just to the left, where it lists, networks and resources, those resources get added by the admission controller or the.

L

Correct: okay, thanks.

A

L

So this suppose will be created on kubernetes and it will I mean. Then then it will use the resource mechanism to find it note that has these resources available and that's pretty much it now I can try to show to them and I hope, that'll work.

L

Alright, so first I want to create networks.

L

Network specification looks like this: there is and the annotation there is the resource names resource time back to the resource provided by it device plugin and are some additional configuration, some additional configuration in this case. It's alias, Electra and network, looks pretty much the same.

L

All right, and also.

A

To be clear in the alias parts you're talking about the Colonel's, alias attribute for an interface right, so you know, like IP, link set yeah.

L

That's what I need to do now, thanks.

D

Note on that, so the reason for the alias was that an admin choose. You know we don't depend on the device name, because we expect a heterogeneous cluster, so an admin could, in theory, go through the cluster to the nodes and set an alias and all the appropriate devices independent of the device mate further down the line that could also be automated. The point here is that we're using C now in this device plugin to achieve all this.

L

On my mini cube instance, I created three additional links: page two, three and four now I can set matching aliases for a selector.

L

So we have sweet eh to floor network, read.

L

And teach for aerobics will be connected to another loop, and this decision was beaten by administrator of the cluster arrived enjoyed by the LDP.

L

And now the device plugins should get so device plug-in, looks for further network objects and for links available on the node and once there is a matching interface it to expose it and not available resources. In.

L

Check if it works so there there are allocatable resources for Alaric's. One interface framework returned.

L

I thought that I will create in its annotation. It says that it wants connections, monitor correct and blue I had some troubles with the analyzer, so there is a little hack.

E

L

I mean I, add list of initializers manually; it should be done by kubernetes, and these three lines shouldn't be there. So try to ignore it. Now, when I create the dots.

L

So it's really out of two, because there is container I just created and additional container it by the initializer and it doesn't work II. Don't need to check why! Oh.

D

It might just work in a segment because he yeah.

A

It's trying against okay.

L

It's writing down things, and so what's okay, let me show you the the actual pot that was created.

L

So there should be extra container. Yes, I, don't know in this book.

L

There is the extra container and right now it's it's visible, although it could be just a scratch container that is no OS running in it, and there is a silly sleep for for a very long time. But this should be something reasonable and it has resources. We request it in the annotation here and when I go to.

D

L

It has ETH two and four moved out of the house into this namespace. It's. It keeps the name of the original name of the interface I.

A

L

A

L

Idea how to name them, but this could be something changed and that's it so I just wanted to show you that the whole picture would network obvious involved and CNI on background.

L

H

The DB itself will take care of the network connection, and so this right, anyways.

I

H

The device plug-in itself will take care of the network connection. Yes,.

L

H

It it will bypass the CNI.

L

No, the CNI is executed by the device plug-in open, avocation.

H

Okay, so you call the CNA binary the device plug-in so because, yes, okay, so.

D

The plug-in is effectively the device begin is effectively shipping, the CNI yeah binary is or libraries. However, you call them and is calling them. So it's not this in our instance of the cubelet or shows the unit, the other duplicated slightly written. So.

H

You mean to say that a code is duplicated inside a device plug in the creation of the network. I was just going through the document, so in the document it has been mentioned that.

H

The device plug-in API will not directly allow any see any plug-in to be used to within the DB. So I was trying to understand this one. The relationship CNI so in.

L

This case, it's just wanders allocate call we we track the container that is supposed to be allocated or created and when it's created, we just execute this CNRI with with and also don't see, nine network configuration is inside the device. Plugin. Okay,.

H

So that I have done other questions so that if this plugin will be invoked before the sandbox creation right.

L

H

You mean the infra container, the container which shells the network namespace.

L

Yes, so the device pocket runs, it runs the whole time and it allocates call is active. We get the allocation request before the network. Next base is available, so we so we hope.

H

L

H

Keep the track of Ted and hoc. You know: okay,.

L

At the moment, it's like Civic, but we work with resource management group, and we hope that there will be a better API for this case.

H

Okay, so so in the DL location, how do you do this? The allocation method, so the one gap I find it in the device plug-in? Is it didn't, have it as the allocation, but you don't have the deallocation. So are you filling that gap yeah.

L

So we still hope that this, the even the delegation, will be added to the device plug-in API, but at the moment I am junuh up on the allocation, allocate call. We we keep the allocation requests inside the device plugin and we monitor the container as well. So once the container disappears.

A

L

Call the allocate, but it's again it's implemented by us, so provided by the device FBI.

H

Okay, so wait and the part is get deleted, so you you will keep track of the part which is getting deleted. You will delete the interface right yeah.

L

We all know get.

H

L

It back to the host or home space, okay. Okay, thank you. Welcome.

D

Actually, just a note, one important point of this pure seeing is to understand what device plug in changes are needed in order to better support network device. Plugins so like what you meant the day allocation is one point, and also the timing got the sandbox.

H

So that was the main concern about me. I mean I, look into the device flick universe that same question actually only is the big allocation and the sandbox actually so, but that was another professor I, don't know if you guys seen, that is some guy called because so he mentioned like doing one device plug-in which does both CNA and also the device plugging. So so is the same proposal. It's a different proposal actually.

L

Yeah we work with because and it it falls pretty much the same idea. He has okay.

H

D

Is a punch that quickly there's actually one difference so in because proposal we would provide enough information through the DP to use seen I as it's used. Quite the plot informations and be yeah I. Think the plot informations to the device plug-in and then here the TP would do everything like the allocations. Well in our component.

D

Leave the allocation for the moving of the interface to the cubed or to the DP part I.

H

Was comparing these two proposals in the vicar's proposal? What was promising for me is like the CNAs involved so that there is no need for the d location, because when the part is it deleted, the CNA will be nope. So it will do this reallocation. We define using NES or IV based or JDK based thing. I can relocate it using the scene itself. So I was trying to understand these both proposal before. Actually so all.

A

Right thanks guys, we are also at a time, although Jeremy, if you're still on, if you want to do 30 seconds about your item,.

M

I I just wanted to call attention to the finalized agenda. We have for resource management and mmm looks like Fabian and Peter have put together some of the content for that there's several other documents floating around I've pasted in part of the part of the things that I think this group would also be interested in Peter I, don't know if you looked at the latest document called representing compute resources and kubernetes.

M

That was something we briefly talked about. A scheduling call earlier today. That's a pretty intense and elaborate document.

M

That's probably the key one for us to know about over the next couple of weeks, but anyway, these are the topics that we're gonna hash out at the end of March two weeks from today, and the reason these are in Google, Doc format is because we want you know two weeks of review from as many people as possible, so I'm going around to different states telling them that these exist and please PLEASE review and you know save us. Some effort from Mike shedding and whatnot would be much appreciated. So that's it all.

A

Right thanks Jeremy and unless anybody else has anything really quick, we are done with the meeting going once going twice all right. So everybody in two weeks.