KubeVirt Community, 11 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: KubeVirt community meeting 2020-11-11

Description

Recording of the KubeVirt community meeting on 2020-11-11

A

There we go welcome everybody. This is thecube community meeting november 11th 2020. first topic on the agenda is I'll turn it over to edward haas to talk about ip extraction.

B

Oh right, so I think this topic was raised a few weeks back. I don't remember when, but it's about uh the reporting of of the ip addresses in the vmi status for the interfaces and we had a problem there. That marching is.

B

I posted the piano that we reported in some cases when the guest agent was active, we reported with c with the citr information we mean the mask and if it was not, if guest agent was not active there, we will report it without the the mask without the cd are only the ip address and uh in the last- and this is only one also not only relevant for the- I think it was only relevant the inconsistency only for the port network, but in any case the decision was that that we will always report only the ip address in that field, so we'll be consistent with the port, but now uh now so removing the cidr was a grid and we should only use the ip.

B

But now the the second question: that's the one that I want to raise here is that we need. We do need to represent the cidr somehow. So one option was- and I remember it was discussed- that we will just use either row information. What the guest agent gave us under a new subtree in the status so we'll just take whatever it gives us or format it. So I don't. I don't know what this is one option and the second one is to add the cidr information or the mask itself under the same tree as another.

B

Field, so I want to ask what uh what is other's opinion on this, so in okay, I can share. What is my opinion is that I prefer to have it in a separate subtree only for the guest agent and that's because this cidr field, if it will appear under the interfaces it will sometime, appear there and some try sometime, it will not appear appear there, because the guest edition is on or off so someone who accessed this api will first need to check if it's there or not- and I think that's not so nice.

C

B

Also, in some cases repeats the information because the cidr includes the ip itself. So but that's my opinion, so the question is open here: do you have any thoughts about it?.

A

Well, it sounds like you answered your own question. If I understood um yeah, when we last talked about this, we had a. We had also agreed that there would not be a canonical one ip field. We would use a list of ips right yeah, that's already.

B

That's already in place yeah and yes, there was, you are talking about the one detail there is like when there is currently one ip and eyepiece the the single ip is just because of the backward compatibility.

B

So that's not. I don't think this is. The question is, if we add another field that is called cidr, should we have one or only the multiple ones, but I'm talking about something before that. Should we even have this this failure, for example,.

A

Well, I'm conflicted because, on the one hand, if we put it in a well-formed uh field, underneath the network section or excuse me the the um the ipa addresses in that same area, then uh we're implying that it's going to be well formatted, but it sounds like it can be variable uh if we put it inside the guest agent uh information, then we're basically just we're hands off and we're saying well. This is what the guest agent said. You know we're out of the loop there um and there would be no guarantees and formatting.

A

In that case, right.

B

So I think, if, if we put it in the guest agent section, there is a there is their formatting. Their format is, I think, is a json format, so we could even format it there, but I think what you just said before that about the field under the interfaces with the ip: it's not that it's not formatted, we can format it. We will say it's called cidr and then we give an ip slash the mask the mask.

B

The problem is that this field will not always appear so that this field will only appear if the guest agent is there and if the guest edge is not there, it will not appear so it's like it. You need to give it's like a logic that you need to provide to the user, that this is what is happening. That field is only there if the guest agent is there and the feed is not there if the guest is not there. So this is what I don't like about this api to put the field.

B

A

Well, I agree that I, in my opinion, it needs to be consistent, like you're saying, um and so I think your concern then is that if we're given the cidr and we throw it out so that we are consistent with just using ips, then we've lost information. We were given right. Yes, that's that's.

B

uh The main concern that.

A

B

Let me ask you this:.

A

Who's using it who, why would anybody want the cidr? I I get that it's you know it's important, but what's the use case, why do we need it.

B

So, okay, so first of all, they can get it. If we give them in the guest agent, they can get it there. But, yes, the question is valid, so the the reason that it is important, it's because it depends what they want to know about the the vm so, for example, in secondary addresses or in in cases where secondary interface or it it matters. What is the subnet? Not only the ip?

B

So if, if someone is wants to use this vmi, they may need to know in what subnet to operate in, for example, and they may need to query that in order to know what to do, maybe they configure their own pod or vm. Based on this information, I don't know that could be the case. It's yeah, for example, someone can.

B

There is even an easier one if, if the operator needs to manage or troubleshoot the the one who uses the vm, so they can use this information to understand that the user configure it wrongly and, for example, configure two two subnets that are overlapping is all wrong, subunits or stuff like that. So it is useful in some cases, but okay.

A

That's great, I don't know if.

B

Sorry, sorry, god, no I'm saying I don't know of anyone using it, I'm not even sure they use it and I'm not sure if we need to care much. But if we provide information like in a sub other guest under the guest agent, I think we are safe, so we can tell them okay, look there.

A

I think yeah, the two use cases that you came up with uh the information consumer in this case was a human being, which means that, if that's truly the the target audience is for convenience of humans, because this information is available. If you can log into the node, but it's circular, because you have to log in to be able to get the ip, um because it's humans that are consuming it. I think it's fair game to put it in an unformatted uh agent info section.

B

Okay, again, we can. Yes, we can even format that section of the guest agent, because we know the format, so we could do it. What I it's like it's up to us, I guess I don't. I don't want to do the to overwork. So it sounds to me like embedded. Json is good enough.

A

Yeah well, there's 19 people on the call. Is there anybody else that has a opinion on the matter.

C

Not really an opinion, but rather a question. I guess um so um it's a noob question, so I I don't know basically, what's the current behavior so right now, where do you? Where can you see subnet information uh and I'm asking this in the context you were asking? Okay, sometimes it will be here. Sometimes it will not be here.

C

Does this happen currently with the current without the pr in place.

B

So currently, what happened is that the there is a field called ip and ips under the vmi status, and it is the problem is that it is inconsistent. It depends if guest agent is installed or not right and based on that, you will have this you'll have the format of the ip either as a just a single ip, without the mask or as the cidr, which is ip.

C

Wood plus mask okay, then I think, uh regarding your concern, was, if we add this cidr field, sometimes it will be populated. Sometimes it will be empty or it will not be there. uh That's not too inconsistent. It would actually be consistent with what happens now right. It would.

B

C

B

No now now it's yes, so it's the field will be inconsistent, so the field will exist or not exist in some.

A

Cases at least exactly.

B

The same because you cannot, if someone reads it a program reads it, you cannot assume it's there. It needs to check if it's there and only then consume it.

C

Right the same the same as now, right sometimes but at least the difference would be that the ip field at least, would always be an ip, not a sometimes an ip, and sometimes an ip slash mask. So now that now they the.

B

The field is there, but the content can be changed right. So it's a bit different.

C

B

In terms of of data, it's the same in terms of how it looks in the api is different. One is about the content changing and the other is about the the field exists or not.

B

I hope I, I explain you clear.

C

As well yeah, I think yeah, but I think it's still an improvement right, at least with the change. The the ip field would always be there and consistently having an ip, not an ip and a mask. Yes, the ip part.

B

We agree that the current ip field, right will be always an ip without cidr will always be that's the first chain. The second.

A

B

Is the in question here? The second change says: should we put all the guest agent information in a raw format under a section of its own, not related to interfaces just as like a generic uh subtree in the status, or should we add another field under the interfaces?

B

This is uh an addition to the ip field, so it, for example it will. One field is called eyepiece and the second field will be called cidrs. That's an uh that's the case now.

A

I would pretty strongly lean towards putting it in the guest agent info and steer you that way and the reason the rationale behind that assertion is that um sometimes we get guest agent information.

A

Sometimes we don't um and it can be updated, and so if the vm is changing ips, um when we put it if we were to put it in the networking information fields, um do we know for sure we own those values when we, if, if we get an updated list of ips, for instance, from the guest agent do, does the guest agent really know that the ips in that field belong to it?

A

It can change them if we keep it underneath the guest agent section, if you will, it knows for sure and and humans know, for sure that that's where that information came from.

B

Yes, I I agree, there is another, even a stronger. We can. I can add to your point that it's there is also a case today that the eyepiece that you see under the interfaces are not really what you have inside the vm. For example, if you have the masquerade binding, the ips inside the vm are totally different from the eyepiece outside.

B

So that's a that's another example when, if we, if we always depend if the user wants to depend on the guest engine information, you will see exactly what's in the vm and we don't mask it or translate it somewhere.

A

Okay, any other thoughts before we move on to the next subject.

A

All right is there anything else that we want to talk about in the agenda notes, or should we turn it over to pep all right pep floor resourcer.

C

Right, just a quick mention that kubecon and cloudnativecon is next week and keyboard will be present a bit. There is a session on there's a link here. I think it's on friday uh check yes, friday um on high performance, give birth in action, and also um the red hat booth will organize a few office hours, and one of them will be dedicated to cubert on thursday at noon.

C

Eastern time uh this will be a one-hour slot open to anyone to come and ask questions directly to well representatives of the of cube and we'll talk about discuss, roadmap or anything that people want to talk about.

A

And I did see at one point earlier: a final call for volunteers is: is the roster full? Do we have the list of people? We need.

C

uh We have you know, let's say we have enough people and I'll get back on that threat, uh but the more the merrier I mean more people are welcome. um There is no, let's say there is no limit and because skipper has you know multiple component like right now you were talking about networking and so far there's no one lined up.

C

Who has you know who is a specialist in in networking, and you know if, if a specific question arises is about networking, we might be a bit short but anyway, so you, in other words, you're welcome to join as.

C

A

Okay, any thoughts on that any questions.

C

And especially, you know, I mean um there is no set agenda for this office hours. It's an open space to to discuss, but uh you know we can bring ideas. We would be very welcoming, um for example, questions around moving. You know uh real world scenarios uh test environments you're using it production environments you're using it, and challenges that you might be facing before moving between one and the other. This type of of conversation would be a great topic to bring to the office hours, but anything else is also welcome.

A

Thanks, pat all right any other uh topics we want to cover today before we uh conclude.

A

All right thanks, everybody see you next week.

A

Thank you bye. Thank you. Bye. Thank.

A