Kubernetes SIG Network, 5 Jul 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Multi-Network Community Sync Meeting for 20230705

Description

Multi-Network Community Sync Meeting for 20230705

A

Recording all right welcome everyone at the multi-networking community. Sync today is July 5th um and let's continue our discussion. I think um before we will jump to those I had an AI to investigate download API, which unfortunately I didn't have time to do. We had a bit shorter weekend week than usual because of 4th of July. Sorry about that, so I will try to push that for the next week and look into that for the next week's meeting.

A

This is this was for our kind of um looking into slowing areas, kind of reducing the scope and just looking what what it takes to get the download API done um beside that I think that was the only AI from last week so to cover that, let's I'm pushing for the next week, um all right and let's move on to the discussion, uh Michael what you were asking for um I think this was from last week, um Tomo uh you started talking whether we should support um cni, configs and and correct if I'm wrong, but from kind of from the kind of to summary, uh this is what exactly.

A

This is one of the examples of a cni config where it can chain. Multiple um cnis that will in a single call, add multiple network interfaces. Let's say you can change to Mac vlans and it will just add two of those to you in a single call.

A

um I think uh do we have Michael cambia, he was mentioning and he was saying that the standard was to always support one interface per config.

B

But actually the I'm pointing the apolicus 88. This is already immersed. I've seen cni CNN the cni community different struggling support.

B

Can consume the previous interface information and then creating the another interface.

A

Support and slaving an interface returned by ipam, um but I think.

B

So so, the um from the um uh from the CN aspect point of view, the one one cni conflict, maybe the AI, the from the one point or the uh uh cni config- is kind of the conflict which they changed, probably as a default. The chain probably the count they create the multi-point office and then return these informations back to the accountant runtime as the one result object. So Microsoft you know, so they are. Let me publisher, mic is also the cni maintenance. I think is that correct.

C

Sorry I was chewing and had my headset off um and I heard my name. Can you say again.

B

So for the uh So, currently, the cni confidence could create the multiple interface to the content and the result. The uh this return, the one result which contains the multiple interface information, so the uh the right here ipbra could create the another. The IP ipv, probably is Chained I mean that the uh the one cni like the uh host device, then the host device, the the bridge and then using the least spreadsheet interface. The user can create the another ipb interface based on this stuff right. So.

C

This is the Barrack yeah. It certainly does support that uh right now. The interface is is an array, so you can add as many as you want. That's an implementation detail. Okay,.

B

So so that this means the uh So currently, the the port Network object consumes still one uh cni config, like the net attached. Therefore,.

A

B

A

Established okay: let's keep you know something on something on on page: what network is an API which is not tied to cni? Cni is one of the implementations for.

B

A

Make sure that's clear, so what I want to say here is I. Don't think we need to make sure that pod Network fits into whatever C9 does today, because it's it's I can say the same. Let's make sure about Network supports Network attachment definitions for Motors. That's what you're saying that's at least what what I think is the same parallel.

A

So what cni does I think with with what we have with the ability to specify the list of parameters ref won't that satisfy that part, and to be honest, is that a use case and and Michael? Maybe that's that's a good question to you- is that a use case that anyone uses, because I never heard of it or anyone in the in here in the room can can can say, is that something I know that you linked a an example for this.

A

But anyone saw this type of usage in production or trying looking into such such use case.

B

So so they I'm the yes at the last meeting the agenda, no, the 21st, the meeting the cubecon DIA mentions that the lift the company already used such stuff in their their projector I. Think.

A

B

Keyboard's presentation.

A

Oh, that's fair, so low latency, multi-cluster.

B

A

But this is multi-cluster networking, oh yeah I will have to watch for that I'm assuming this is their alternative to Motors. That's at least how I'm, seeing it probably.

B

After using the models.

A

Yeah and why they're not here to drive this use case unless someone's skin is there? Someone from that? That's that's I. Is that something that we really need to support Tomo. That's.

B

uh So the I thought I believe that this Mountain Community they should Target as much as the use case of their current to the these concept, because it's not the enforcing it to you, that's the one-on-one stuff, and then we already understand Network use case is the pretty diverse I mean that even though the amount we just saying the multiple interface but every user have given every different use case, so there we need to somehow uh design these stuff, uh the uh the uh API as much as possible.

B

We capture the use case and then basically so this is about the um pretty so that this presentation is in the held at the cubecon. So they are. This is, of course, the key points of famous conference right and then the this is also the uh the they already did, that the the current kubernetes and then once if the we just dropping hey. This is not support. It's not supported in the rightest kubernetes, and then this is not good. I. Think because.

A

No nobody Tomo again you're trying to pull in cni support to the standard of this. This is what I was saying. Is an implementation detail. Please don't pull that in uh I think so so maybe let's do an exercise. Let's do slightly differently. Let's do an exercise on how could with the existing API. How could someone do what you're asking for so basically having those multiple apis and Let Me Maybe jump back to the um to our draft of the of the text right. So if.

D

B

An exercise right, okay, but today we need to keep in mind the current Upstream coupon that supports the CNR as the network.

B

A

Don't think even even I need to watch that video, though so I'm not sure what is the level of their support with that multiple cnis and, to be honest with you, so.

B

They definitely no. Let me let me finish my thoughts. Let.

A

Me finish my thoughts so sorry, Tom and, to be honest with you, they followed the current approach that they had right now with these multiple interfaces added, because there is nothing else except for multiples and maybe they didn't want to go into Motors.

A

All right, I need to watch the video that you linked, because that's a good one and I want to see why? Because my question is: if they wanted to do multiple interfaces, why they just didn't use the motors? Maybe they just want to show you something native and the only native thing was use the cnis, and maybe when we introduce this, that will give them o a new platter of capabilities where okay, now we can do it in a different way, where it's more standardized rather than having a con.

A

That's just arbitrary adds multiple interfaces, so my my guess to this I'm, not sure but I need to watch the video to determine that. But that might be the case, but put it. Let me you wanted to say something to him. Go ahead.

B

So he said, I'm also strongly recommend to you also read the uh pull request. Ata discussions I mean that the this is the different from the lift use case, but that maybe the the both have the same. Their design I mean that the second I mean that they they create the uh one, the two interface and their one c and a conflict at that time. They are this.

B

The second interface creation is depend on their first name purpose, so this so that they want to this the describe this stuff as the chain problem, so that that's the maybe the one reason and then currently the uh and also the uh if we describing this stuff somehow, maybe they will need to be describing the implementations, but the currently we do not have maltus does not have the dependency diagram yet from the design was. If the someone wants to use their dependency creations at that time that they should use the chain, though,.

A

So studying yourself, okay by stepping back to what they use today and if we were to introduce this this guy and I'm not saying it has to be like this.

A

But let's assume, let's, let's say that cni implementation of pod network will be just by name so, basically, I have a conf name uh like I use, the name as the conflict that I have to select during the from the conflict on on the list of the um you, have the conf files in the cni path and basically the name inside the conflict is represented by pod Network and it's one to one mapping, there's nothing else, very simple: let's assume that's the implementation and, let's assume data plane points to that conflict that has multiple interfaces.

A

There. You go it's it's all installed there and now it's up to cni on tune properly support and fit into the Conformity of the uh return parameters that we Define here. So basically stating how many IPS they return. All that, so that's happened to them to Define that, but basically it's all supported it's all there. It's the way, the way they have it today. So it's not. We.

D

A

Going to support it because that's not true, we are but it's a matter to cni on how they conform to the apis themselves and they fit in because it's the same thing what they have today. It will be then, as well.

B

Okay, so the academy, the adding enough comments on that, so they are, in this case the one and then maybe in the lift or some case, the one cni group as the Euro, the uh the thought, the uh this okay, that's the port network name is matched to the CNN name and then they they lived creating the two interface. But these two interface is not belongs to the one network right yeah.

B

So so, let's, let's, let's also Imagine the first interface- is just the ipv and stuff and then their next interface is creating the Thundering interface. Like the uh selection scales case, the wire guard interface is created so Wiregrass interface, using the creating the thumbnail to the outside the bpm-ish interface at that time, first interface and then the second interface of the different cider different diabetes, different network.

A

It is the same as you were exam showing an example of one interface is going to be Mike villant, the other is going to be srov and I, and you will wish to use. Where was it? It was here and you would want to use multiple parameters, reference for that, no.

B

No, no! No! No! No.

A

It's similar I know it's slightly different from your point of view, but I would say it's up to the implementation on how they're going to handle that later on. It's not something that I I we're gonna face, so we are proposing an API that better represents networking how the implementation implementator is going to kind of use that that's up to the implementation itself right, so I assume Michael, then later on, will look at this API and see how cni is going to fit into this exactly right.

A

I think he has more or less ideas right now, but that's what it devotes down to so look into that so much you bringing that up. It's fair! Let me watch through the videos but and I recommend everyone else, but.

B

So but the keep in mind so currently the one currently the some case, the one configuration May creating a twin toughest and then their boss is maybe in the same network or the both may not ideal same network right that the one interface pointing the one network, one cider and another stuff, another interface, pointing the different side. So.

B

Currently this in this case, two interface created on the one port, Network and they're, unfortunately Port network is, is specifying the uh just in the network like the array, S3 Network one so and then this object, Port network is also used to the uh service and uh Network policy right. So this means if the two were more cider. Different networks is in the one port Network, then maybe the service implementations and then the network policy implementation have their challenges. I. Think.

A

um Again, I think that.

B

I'm just so this, this is just kitima.

A

Sure but I I think that's that will boil down to how the implementation will do that and it isn't cni right.

A

um I feel we are both only two talking. Anyone else has some Opie on this.

E

Sorry, do you mind just recapping a little? This discussion is about whether I I just came in late. Is it about the chaining of the cnis or the multiple different interfaces.

A

So Domo is bringing up a case where a cni can introduce two interfaces in one code. Something unorthodox he's pointing to Links here on. Who is trying to do this I think he was mentioning pointing out to the left, trying to do something like that where a single scene icon can introduce you two interfaces in a single call to the port. So, basically something like the multis meta call, but without Meta Meta plugin is just directly with single call.

A

You chain to those guys, and the concern here is esport network- is going to support that case right. That's that's kind of the gist of it and, in my opinion, cni as we as we established before, is an implementation detail.

A

Cni is not all in all the standard on how networking in kubernetes has to be done. It is leveraged for that. Yes, it's the main kind of entry point for that, but that's not that's the only thing to kind of do. uh Multi kind of the networking, like some other implementations, are doing um I'll only only relying on the cni but the other implementation using CNA as just they trigger and the real system by the agent some other agent on the Node.

A

So um that's when we established that I think we already said that a few weeks back, that cni is an implementation one of the implementers of this of this interface of this API, and it will be up to it on how they will handle pod, Network and now.

A

Thomas concern is that the Pod network will not handle the case where we can call uh when the cni can have chaining and create multiple interfaces to the port.

A

And, in my opinion, that's up to that implementation so basically eventually see an eye on how they're going to handle that later on and fit into this API that we're coming up with here.

E

Yeah, okay, but you know, training is.

D

Is is used um quite a bit, so that's that's my opinion. It's used to add in interfaces so.

A

Right but but my take is I need to watch that video on that what live did and what was the reason behind it.

A

um But chaining is used for uh plugins, which enhance the single interface ad and then add stuff to it, and if I'm not mistaken the standard, that's something that Michael Cambria is not here. But last week, Michael monts was saying that the standard is to introduce only one interface per call per conf file. That's something that he was mentioning I! Think Michael. Can you confirm that or that Michael Zappa? Can you confirm something that is the cni standard, yeah.

C

That is like the the main use case, where you kind of have, like your main, uh your main plug-in that creates like your primary interface and then you have these meta plugins that yeah, you know, add some sugar to them like uh make changes, enable port forwarding and more uh so usually it's one per conflict, but people have gone out and done other things uh which I don't think.

C

It's explicitly stated that it has to be one and if we want to, you know ensure that it's only one I, don't I think we just didn't want to dive into the implementation details but I think by Cambria, since he was like the original. You know, writer of the spec will be. You know the the source of Truth on that one.

A

Yeah he's not I assume, is it recording from yesterday uh so next week we can. We can double check with him, but that's yes. We agree that the the the the chaining is there, but still, let's not take cni as something that we have to support. Cna is one of the implementers okay. Let's make sure that we treat it like that.

B

And then another stuff is the I suppose the C, the color. So this working group is, of course, the kubernetes and the current equivalent support the cni and then already the cni is supported in Upstream. So maybe so this means the wish the this cap is for the kubernetes. So we should think inside inside commands not being this this sections, but somewhere we should mention how we support the cni, including this situation.

A

So now that already we established the cni, oh in this situation. Okay, um that's fair yeah.

B

So cni can creating the multiple interface and then how this net Mouse Network cap is take care of that or.

A

Not basically, but basically, this is. This is the same thing now we are drilling into this as um what I want to say we are drilling into this with um with the notion of oh cni. Can do that, but multis does the same. What do you thinking of doing good Motors, because moltus is just a meta? It's just okay, you have more enhanced uh Advanced.

B

A

On how you select those but with single cni you're, adding multiple interfaces the same way so.

B

So this is the implementation details that you told so I'm just talking I'm, just saying that so the motors is just the one implementations. The models is a part of the cni plugin one of their stuff, but this is not the whole CMI, so so the I'm just talking about this C So, currently I'm talking about the CN aspect versus the mouse Network cap. So.

A

No, but the problem is the same tomorrow, I know, but but basically the problem is the same: I can, with the single cni call I can add multiple interfaces. This is the same as maltose icon with a single cni call. I can add multiple, because but you're just meta.

B

Implementation is a different.

A

B

Don't know I mean that the.

A

End result is the same right.

B

uh No so because the amount models do not care about the dependency of the cni. The problem Creations, but to the plugin chaining is, of course, the the having the dependencies. So in.

D

B

One create interface created and then next is created based on the first thing, but interface. Currently, the models cannot do this stuff.

B

Their case, the expression, the models cannot do the same things I declare, but.

A

The the core, what you're asking for is the same I, make it CM single, C and I I end up with two interfaces in the pot. What's the difference between what what you're saying here and what motors does? What's the difference? It's the same thing, the end results, and now there are tweaks, but but it is the same thing.

B

Dependency is important.

A

B

E

A

That's secondary.

E

A

Because because tomorrow, at the end, I'm talking about the end results, let's, let's put aside what's happening inside how other tweaks are done, but think about this eyes, make a single cni call, and in this case C and I I received two interfaces in maltose case, I received two interfaces or more as well. It's just done differently.

A

Yes, you see, there are some tweaks and and and and and and some uh differences on how, but when the Call Comes Back to cubelet and and basically when I make the first cni call from cubelet and then I come back. My pod ends up with multiple interfaces and I made only one cni call.

A

What's the difference.

B

So, okay, let's imagine the first interface and secondary interface, the is the having okay right there. At the models case, I mean that the one net interface a is created by the internet, that's the A and then the second database net2 is created by the net attached dev2.

B

Requires the uh I the best is a requires. The previous interface information, such as the IP address, plus interface name. Currently, models doesn't support it, but they are in the list case or some stuff I mean that lets them the other end. The one example is about the tail scale. Some stuff I mean that they are creating the uh the VPN is interface at that time. Of course, this interface requires the previous network interface name to getting the connections as well as sometimes they may adding require the source IP address as well So.

B

Currently, the the amount of net attached Dev is just the net attach their information, so so they are they doing when user, creating.

B

Is not being executed, so this means that we do not get the interface name as well as as well as the IP address.

A

Okay, so basically, the difference is being that each interface is represented by a network attachment definition. That's what you say: yeah.

B

A

B

That's the stuff, so that's why the plugin chain they use the program. Chaining I mean that the one interface created and then the second the programming can reach the output of the the first Province output and then they get they got. The interface name IP address in the result, object and then do the creating the next interface right, the Thundering interface or ipb Ram or some stuff so So. Currently at this stuff.

A

And also this is a better light on the on. So data lies strongly on the passing the parameters between the c9s. That's what she referred to.

B

A

B

Did this situation I mean that later abstract this stuff I mean that sometimes the one that the the some user is creating the multiple network interface, but also that this have their dependencies, so so I mean that so they write the currency, the your uh attachment, the structure is how they adjust the wrist. At that time, the we do not have the dependencies.

B

Well, maybe we could add in implicitly adding their dependencies, but also they are sometimes some some of you that wants to utilizing the previous interface information to next uh interface stuff. So so the maybe we need to think about the how we Implement how we design this stuff in the uh in the API.

A

So that's what I'm trying to tell you tomorrow, it's you're trying to conform, one of the implementations, I, don't think we have to, and we should so like the dependency that you refer to or the chaining that's how the cni does and that's they're implemented in the day prerogative and that's it. We are not going to represent cni into this object. That's see a nice job, that's completely different job of this object to represent a network or what you are attaching to a pod.

A

That's it all right, so, let's not get into that on how to kind of represent the other style, because that's not um I, don't think! That's that's valid.

A

uh Let's let me I recommend everyone else as we're watching the the links and reading through the links and comments. I I want to kind of know more about what they have in mind into this, and that may be us as uh Michael is recommending. Let's shout this for the next week, um see maybe we're gonna have more more data on that one, and then we can continue the discussion um all right and and let's now I think in our discussion.

A

I think this is came from uh the um I think the initial discussion came from making the uh the params reference a list which we agreed to make so just to kind of keep up everyone from last week. This this is, will become a list. You can specify multiple uh elements here now and and I think this attempt from us talking about the network interface um I think this is something that I was thinking to introduce I, don't think we concluded anything at all to kind of remind everyone.

A

um This would be a object describing how an individual policy.

B

A

Attached to it,.

B

Sorry, the the based on the document, the uh the stuff, the uh structures we we do not covering all the we do not covering yet about the uh uh part, the spec plus the port Network attachment field. Yes,.

A

I think we we did I, think we finalized for now on so before, because why we didn't finalize attaching pod to a network, because the other object is relevant to that on. How so, basically I was I was showing this this thing last week last time before that, so how we attach and how much you can um customize your stuff into a pod, Network attachment and I was thinking of what.

A

If we were to propose this thing right, because I don't think anyone will allow us to point to a custom anything inside this section, that's I, don't think nobody will allow us us to do this. So what we can do is point to another object that will be will be able to specify exact parameters for that specific attachment.

A

So I think this is what you refer to Tomo.

B

And then also the uh as uh the I mean that the power, uh so sometimes the from the implementations, the point will be implementations- may want to add the uh some additional parameters on the.

A

Yeah exactly what I'm saying and basically those parameters cannot be in this piece. This is POD spec. Nobody would allow us I, don't think. That's my at least considering how um currently the whole objects are. Structurized, I, don't think anyone allow us to point to an arbitrary information.

A

Right so either we um that's that's that's the thing right now we don't have that ability right. uh I was thinking, maybe to provide a individual individualized objects, but I'm not sure whether those are useful right. The problem with um pod Network versus spot network interface right um is that okay, I can reference. Okay, you attached to a specific Network as a whole thing, or you have exact parameters on how you attach to it all right.

A

The problem with that second approach is that it is individualized, so you cannot use this in replica sets, because this object cannot be shared right. This object cannot be shared because it specifies let's say: mac address right and Mac. Address cannot be repeated, so basically, as pod network is just a general information.

A

Okay, this attachment goes goes through this, inter this attachment goes through the spot, Network and then okay I know how to attach that stuff to to to to it and I will do it in a general, some randomized way right, whatever the defaults are, but maybe I can provide and more specific information for those defaults right.

A

I want to use a variable, a b, c and d for those defaults that are in the first use case, but the problem with that approach is that you can use it only for non-replicaset pod Banks right, because you cannot specify and and leverage the same pod network interface into the same. Multiple parts, that's the kind of the problem, and even whichever approach we take. Even if we were to use a specific parameters here right uh on how to attach to a network pod Network those.

E

A

Be even individualized right. You.

B

A

Have those used with um with replica set.

B

So so that you're just talking about nemac address and the IP addresses the parameters and.

A

Those are just examples: yeah.

F

But I think there there is a use case to be made for parameters that are replicable uh so like.

A

F

So one example that we have is uh the type of interface. So if you want, for example, a turn versus a tab or a memory interface or.

A

Shouldn't that the Knight and go into the Pod Network itself as a piece of because if it's, what.

F

A

F

D

F

I would say, probably no, because you.

F

um You might so that that's that's something that that's inherent to the Pod itself, meaning some files in replica set will expect to connect to a given network with a specific type of interface because, for example, they need a high speed interface. Someone with an interface with high Qs. There will be able to Consumer and they want to talk to another pod, maybe on the same network. But that doesn't have this capability to attach.

A

Okay, I hear you.

F

So yeah, so the the specific use case that we have is: um we have support from MF, uh which um and uh regular devs turn tabs, and we want to be able to to have applications that use memes to attach to a network, an application that use regular interfaces to that to attach to the same network and be able and that the two are able to talk to each other. Basically,.

A

A

Oh yeah, that's valid I I, I I hear you, but so basically this is a similar case to what I think Tomo was proposing as saying saying that okay I have a pod network with Mark, VLAN and srov right.

B

And then, depending.

A

On whatever I want to, the network is kind of the same, but I think what if I know the one of arguments and tomorrow was giving the same argument that okay I want to connect to the same subnet right and because of that I'm treating my network I'm representing my Subnet as a pod, Network and and I'm I'm, not going to give you any question. Why why a pod network has to be represented by a subnet and- and this might be what you need to do in your environment, but keep in mind.

A

Pod network is representing what you are connecting to the Pod, not what it doesn't have to fully describe one-to-one. What your um environment.

E

Looks like and.

A

This is this, is this is your if you want to? Yes, you can but I I'm, throwing just another kind of uh a proposal here uh for for your both of you, your use cases why not? Each of those can be represented by a single, a different pod, Network right, but.

F

A

You you're trying to make it because you're trying to make the Pod Network on a level of just ipump and I.

D

B

Why not? Why not go up to the title? Okay, so so, in this case yeah. If the, uh how do I say, one network cider, like the 10 dot, 10.0.10 24 for each interface type, Mac computer have the one Mac we run. Netport Network the IP and the SRB is the SRB Port Network and then also if the SLV have their two choices and that SRB have their parameters, which is like the uh spoof check. Or, of course this stuff is the parameterized as the SRB cni con.

B

So the each parameters we, even though that both is, is connecting the one layer, 3 Network. We need to create a desktop and then I'm I'm just wondering how the network policy is working, Network for so they're, so currently, based on this design, we did not. They cover that yet, but I suppose that the network policy object is associated uh associated with the one network, object right.

E

B

In this case, if we designed for each parameterized object parameterized, we have the multiple port Network object at that point, the most Network policy is not the works right, because you.

A

Have to apply the same network policy to multiple networks. Then? Yes, that's a that's a trouble. Yeah I.

F

B

I think, as well as the memory for this stuff, so SRP have the loads of their parameters and then the RSA TX rates, sometimes in the high hard quality networking I want to specify this stuff, as the demon zip based and, of course, that this is the demonstrative. What the depth the uh replica set they support, because they are not the IP address. So the of course, the same parameters is applicable to the Old Port.

A

So keep in mind that we definitely cannot pass any of those right.

B

So that that's the attorney so I mean that sometimes the user wants to do that. So the um if we having this stuff and then the you that makes the happy this makes user happy so.

A

I'm back on any type of adding any Fields custom fields in this. In this section, that's I, don't think that will be a able and.

D

A

Me run that by by someone in the group, but I, don't think that's even possible to pass that kind of approach right, so I, don't think that's even a a. I I think that will be a no-go. So that's something that we need. Let me investigate into that, but then the.

F

Alternative and annotations will be annotations, wouldn't be possible. Oh.

A

No, no that's like I know you can always elaborate annotations, uh Nathan, that's, but then that's up to your implementation and how you handle that right. So.

B

Yeah but yeah we can use the important annotation on this stuff, but also they are.

B

Network because the important I mean yeah.

A

Your use case, yes in your use cases, maybe because then you have to have additional parameters. That's why and moscow's. Like probably other use cases won't be that and to be honest with you, uh I don't want to go there, but I I think this is like I I think we are here and talking for the last half a year. I think we everyone feels an advantage of that I. Don't think that's right now! uh It's not a good thing to have this.

B

The comments this is the last, so they are this. This stuff is already supporting the models, but this is not supported among Network cap. This means the you that some use are still using the motors, not the important Network, so they discuss the pop network doesn't cover such use case. huh Just keep in mind.

A

Thank you, yeah I know what you're saying so, that's why I would want to kind of um what? What about the pod network interface? Is that any anytime anyhow useful right, because this is where maybe because that will be our object, then right we're introducing a new object that is ours right and then in here you could point to anything custom or we could specify a um I, don't know a a options uh dictionary right, so basically, some sort of like uh either.

B

There is no such objective right.

A

No, no yeah, there is none yeah.

B

Is there any space for that.

A

What I mean space? What do you mean.

B

I mean that so currently the aspect that only have the port network name IP address the macro address right.

A

I'm yeah we're discussing Thomas, so it's not like it's set in stone, so basically uh this will be. um Why will it happen again?

A

Firearms map? Let's say that right, and this is uh dictionary right. Let me just do this very erotic and this is addict right. So basically, then this can help have something like.

A

So that I should call arms map and then I can do this right. Full bar and blah right.

A

And and so on so forth right and then, if we do, how you understand those, um that's just my just one of the ideas: I'm, not sure, that's the best one I think using unstructurized um objects is not the best way to go, so maybe we should rather propose an uh pointer to another parameter here. Instead, thoughts.

A

Should that be this, or should that be a just another params refs right? Where are you here or another, this guy.

A

Because this is something that we can probably.

A

Get through compared to just spec I, don't think we're in a pod spec. We will be able to have like this Portsmouth or a reference to a custom object. I, don't think that's possible right!

A

This guy has more options and then has pointers to some dif some custom stuff right where you can place wherever you want to right, and then you like an example in in multi's case. uh You would, instead of because, if I'm not mistaken today, maltus has the Json format of the um uh annotation right per each attachment. So basically, instead of having a Json, you will just create a structurized object out of that and then point it here right, that's that's what it could be right and then you have everything structurized everything is nicely validatable.

A

You can validate everything nicely and then it's more more clear on how to use that.

F

um I think it it adds a bit of complexity with all the objects. I think it's worth that's.

A

The problem right yeah, the.

D

Problem here is.

A

That the finger is yeah adding this reference is very cumbersome like from the ux point of view. Okay I have pod Network. It has pointer to a custom object and I. Have my network attachment that points to that, because here it says pod network name. So basically, this network interface points um one. So basically one pod Network can attach only one network right and that, because that describes on how I'm attaching to a specific uh pod, so basically I'm specifying spec on how it's attached and then in the status.

A

I say what I really did right and then that's is being used in the Pod later on right. So that's what it will need right. This.

F

A

Way out, instead of you doing those annotations or what's not, on the Pod, this is a way out to do this on a a pair attachment basis right, I,.

F

Think with what we, what we said before on the back that you uh so you're gonna, add the purpose parameters ability those parameters, rep will probably be templates and you probably will only have a handful of those which we can then share between yeah.

A

You could do that as well. Yeah I agree, and maybe my my my Approach, because that's I maybe put it under my uh and I apologize for that under my kind of view of my implementation, where each interface described is unique right and it should not be shared across um multiple pods, which what you showed an example of that's not doesn't have to be true right. So basically you would not.

A

So maybe question is: should we even have those, because those IP address and Mac address, make those those two fields and fourth, that those has to this? This object has to be. This object has to be um unique per each part. Maybe we should just remove those right. You cannot specify that parameters here unless, unless you wish to then then specify any parameters, ref and then I, for example. In my case, if I want to do that, then I will make it it's Unique one-to-one only right, but other implementation uh doesn't want to do that.

A

They want to have it like you, what you, where I, want to specify like a type to select from the Pod Network right or something, and then it doesn't have to be unique right. So maybe that's that should be the case right and the only thing I would want to do. Keep it here is the the parameters here right, because then those gives us ability to okay what I'm really setting in my pod right.

A

What is being said because that's like IP address on a pod Mac address per each attachment is useful right and those are just defined rather than um set right. So basically, this is done by automation. Whatever is being said, the only the other thing here is that that's something that I want to point out. The reconciliation of object, which is maybe in in context of this whole thing, might be slightly contradictory, but I will try to explain. I have five minutes to do that.

A

What it means is, this is an object, a kubernetes object that we reconcile on right. How you would reconcile this on for the network attachment right? um How would you how you would do it? Is you don't because, when you think about this, if you were to take it on a face value where okay I have this object? I, my my let's say my implementation takes this object and sees okay. I have interest pack and I am going to take those values and pass them to the to when I attach.

A

So this is something that you could do. Yes, of course, but what this object gives you ability to is: okay, I can have another controller, for this object particular object that will look at those parameters and say: okay, you want this. Let me check what I have available right and whatever I have available, I will set in a status and only then the other guy, the one that was initially doing stuff, the one that looks at the Pod. It says: okay, I have I. Have this status I?

A

Have this guy selected do I have a status in it, I. Don't so I wait because, let's say uh in in here, I requested a IP, but the LPS, the ipam story somewhere is getting sluggish, and it's not done yet so I wait right so, basically because I wait because I need stuff from read from here. So that gives you additional level of control right. So you can split your controllers into okay.

A

You have the Pod Network one that does some stuff, but you have the the the network interface per Network, attachment a means to do some sort of reservation, some sort of a whatever you would need behind the scenes and then post it in the spec that later on, your implementation will pick and and use and do something about it right until let's say there would be condition stating okay, everything's, good I request that some resources here in the param surf for my custom implementation and when it's done it will say, conditions, okay and then you can start using it.

A

Only then, okay, my implementation on the when, when the pods being started, I can really do something about this. So I just want to point out. That's another flexibility. Another capability. You could do with this object right where I can now additionally gate how I am attaching per each interface to a pod. I can do some gating on how what I want to do per each attachment to the Pod right. I want to have let's say some reservation done.

A

I want to do some I, don't know, configure my switch in some special way and then ensure that everything is set up. So basically I make sure that my controller configures, the switch a a some eye pump, some DHCP wherever the story- I, don't know and then eventually says: okay conditions, okay, I manage to everything set up now you can go and create a portfol for this guy. Something like that. I'm I'm saying that that's something with this object. That's another way, another level of enhancement. You can get to your implementations right.

A

So, that's that's something that keep in mind that that does the same thing with with the Pod right the same fit with pod Network object where we said we have the status right, and that gives you ability to control of when things can be ready when things can be set up, and you can gate things when, when things can start schedule being scheduled, right, um I think that's something that I want to show in uh for all you to.

A

Think of uh sorry, for for uh dragging this did I manage to somehow convince you on this object. uh Tomo I think he's still here. Is that something that that will be valid, I'm, not sure which one we want to go yeah.

B

I'm, of course, here and then yeah this next, the yeah- this makes sense to me. I mean that maybe they promised map is the easier one, and then this is just parameter. We may need no need to add in the structures, object, I, think.

A

B

A

Here is it's always when we, if we were to add this, this map is always what I want to say, give give someone a little and they later on, want even more so that's my problem right here. If I will give them just the map and then eventually they would want to. Someone else would want to oh I want to have this and that right, uh I want to change.

A

Even I want to add even more and eventually what I'm afraid we're gonna end up with the parameters ref anyway, because if you point to anything, then then sky's the limit you can do whatever. Whenever and however right and then it's seated off so I know, perms param's map is from the ux and and a customer like ux point of view, it's better right because it's less cumbersome right I have just a map. I put it only in one object: I don't have to juggle like 20 objects right, but then.

B

A

B

Is pretty how they say: they're good to start implementation I think I mean that if someone wants.

A

B

Moving forward I mean that they asked the uh the person to some stuff I. Think, anyway, that that, anyway, that.

A

Does let's, let's talk on talk.

B

On this next week, so that this this is the adding the problem, the uh Implement implementation parameters in the interface spec is makes sense and then also the uh removing the IP address and the macro address from respect, which also makes sense to me, because I'm a little bit afraid that the uh this design May having the IP address is mismatched between the Apostle spec, uh their network interface back and network interface status.

B

Sometimes we, the user, have a risk about the request. Ip addresses is not assigned, and then the random different IP addresses aside in this is the pretty bad case. I mean that you don't want to assign the port with IP address, but this doesn't in this case the uh it. This part is not created. This. This makes sense. I need that user is the expressly understand.

B

Oh I cannot creating this path, but I'm a little bit afraid that the product is creating successfully and then the IP address is different at that time, then you, it's pretty hard to users to understand, what's happened, otherwise the user always need to check the spec versus status every time, and then this is pretty awkward. You know so this is. This is just a bad evening. Experience.

A

Yeah exactly so so so to that note, and and let's let's on that- let's continue I do have this read through the status section here. This is what I I am working towards. This, basically will be the last hopefully thing that we want to change in API, where a couplet will have to report those IPS that you're exactly referring to here.

A

So basically, the whole implementation takes the Pod network interface and pod networks and the ipam and transforms it and eventually set something on the Pod and there's something whatever eventually got set up returns to cubelet and posted here. That should be the end result right. So having ability to finally say: okay, this is the final IP. So basically, this will be the true source of uh the source of Truth in terms of what IPS I finally said.

A

If, if you even said- because this is this, we should make sure the IP is optional, because some networks will not have an IP. That can be the case as well, so we must make sure I'm not sure whether that field is omit MTS. So, basically, that's that's very good right. So this is, this is copied from The Source right, so IP is omit empty. We would add a pod network name.

A

So basically we will have a mapping of network to an IP and some networks might not have an IP so basically I just add a pod Network. You have an attachment to this network, but no IP right. So this is something that think about this, and let's talk about this next week, yeah.

B

Okay, maybe we should have the interface name in the status field, I think, because the interface name is not not really quite a few right.

A

A

All right thanks, everyone bye.

C