Kubernetes SIG CLI, 27 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG CLI 20220727

Description

Kubernetes SIG CLI bi-weekly meeting on July 27th, 2022.

Agenda and Notes: https://docs.google.com/document/d/1r0YElcXt6G5mOWxwZiXgGu_X6he3F--wKwg-9UBc29I/edit#bookmark=kix.bbpdjpaiz4tl

A

A

So hello, this is the july 27th 2022 edition of the six eli biweekly meeting, I'm sean sullivan, I'm your host. We don't have much on in the way of topics. Today we have a single one, but we'll begin with some announcements, so the most important- or at least the most topical will probably be the code freeze, which is uh within less than a week uh for 125 the real the 125 release.

A

We have a code freeze, so if you have anything to get done, then you've got a little bit less than a week um and then that release will is scheduled to eventually go out on august 23rd.

A

So I had just recently uh uh deleted this next item because I saw that this particular uh rename of the repository branch is going to be postponed until 126.. If you want to know more about that, please click on that, so that that's going to be changing the branch from master to main it'll happen in the next release.

A

So uh it seems like we just changed the golang version to 118 and now we're already moving it to 119..

A

So if you see an error saying that you need to update your uh go to 119 rc2 when you're building, then click on that link, it'll it'll, give you all the context you need. I believe that that is going to happen directly after the code freeze. So within about a week.

A

There is more context as you click through that link, and I'm not sure if we brought this up before, but there is a contributor summit this year for the north american kubecon in detroit, and that will be the monday october 24th.

A

So is there anyone else who has anything else they'd like to announce.

A

Okay, why don't we move on to introductions, and this is the part of our program where you are? uh If you would like to introduce yourself if you're new or you haven't been here for a while um and you'd like to uh to meet some of your other colleagues, uh go ahead and please introduce yourself- and this is completely voluntary. So if you're, if you don't want to, then you don't have to.

A

Is there anyone who would like to introduce themselves.

A

Okay, so why don't we move on to the topics, then um brian, would you like to to talk about this particular topic? Sure.

B

Yeah, so this this is a um the link. There is to a pr that I opened that fixes a an issue where, um if so, it's related to after server side apply, became the default and there's now a uh a field called managed for a field on yaml in the ammo that called managed fields that will show up. If you do a uh a a get with dasho yaml and then you pass show manage fields equals true you'll see all like the internal metadata that it uses to manage server side apply.

B

um What happens is if you, if you do a coupe cuddle diff by default or or not even by default? By always it's going to give you back the diff, including those managed fields, and that diff actually gets kind of ugly. So there's really two two issues here. One is: do we want to see the managed fields in the diff, because it gets it's like a lot of information that isn't really visible to the user?

B

Normally, unless they request it and then number two, the diff that's coming back is is uh messy because the the when there's multiple fields that are managed fields they get flipped around and then the diff ends up being um really really big. Looking when really it's not, and so in the pr I have a, um I have the old output and the new output, you can kind of see what in the old output what it looks like. There's, a big giant plus section, a big giant minus section when really all it was was.

B

I think the time was actually what was changed and it got flipped around.

B

um So the question is so antoine commented on the pr and said: hey. Maybe we should talk about this. I think it's helpful to see the managed fields.

B

um My pull request has the option to include the managed fields in the diff, but by default they would not be included, and so I guess this is just kind of a chance to for people to say what they think about this diff situation and talk about it. Any thoughts.

C

Yeah, I'm the one who requested like that. We talked about it at the meeting because I think oh.

B

I'm sorry about that. I forgot.

C

It's okay, um yeah cause. I thought there might be different opinions on this it I would. I would argue that, even if um showing or diffing the managed fields is generally useful, uh diff doesn't actually support that right now because of the time stamp, sorting issue that you mentioned.

C

So it's sort of like got the managed fields just by default, started showing up at some point and we never actually implemented support for the way that that they're sorted um so right now, diff doesn't actually show a useful output for managed fields, whether we have a flag or not. So from that perspective, I think adding a flag would actually be somewhat misleading, because then you know, if you enable the flag, then it does something useless.

C

So uh I would argue that if we do have the flag, we also need to find a way to fix the sorting to make the output viable.

B

No, that sounds reasonable, so one option would be don't add the flag, but go ahead and create an issue to fix the sorting and and then add the flag at the same time or go ahead and try it all here in this pr. I I don't know my I I almost didn't add the flag, because I thought well it would anybody really ever want to dip the managed fields, and so I added it because I was afraid somebody might want to but you're right. It's not really helpful.

B

Even if you see the diff, so the flag is sort of meaningless, as it is right now.

C

Yeah, so the third option is disable it because it's effectively not supported right now and then, if we get uh the feature request, that folks do in fact want to see it. Then we can actually implement it for real so that it works with the flag.

B

No, that's a good point like maybe we shouldn't automatically create the issue. We should wait for people to unless there's somebody here that says hey I want that and then I guess we could create the issue I don't know. Is there demand for that? I guess antoine seemed to think that he might like to see it. Oh here he is he's on now.

B

Hi antoine uh we're talking about the cube, cuddle, diff and the managed fields um stuff and, and we were just kind of debating whether whether um whether it makes sense to even have the flag. If we don't fix the ordering output of the managed fields.

D

Yeah hi um yeah, I don't know I am. What can we do about the ordering.

E

Can I ask a question: what is the purpose of uh sorting manage fields for things, so I think, according to the time why we are doing this.

D

So uh from the api server perspective, we need to be stable, so things need to not move and in order to keep things stable, we solve them by multiple criterias. But time is one of them um and we also sorry about that and so yeah. Unfortunately, we had to fix it, because the the sp, the spec for the api server was that the the most recent needs to be on the top and when you change something it should update the timestamp.

D

um So this is why we have the ordering- and I think the ordering is right. I guess one of the questions we could have is: can we resolve differently for div, specifically uh client side, just so that the gif is not that bad.

E

Yeah, I was exactly.

E

Suggesting this, can we do this manual reordering in this command? Maybe it solves our problem, of course, by discarding to the time fields after sorting, because time will always be different.

D

Right yeah: this is yeah, it's an option we could. We could try and think about that. That's why I want us to take the time to think it through before we disable everything forever.

C

Yeah, I don't think anyone's saying we should definitely disable it forever. It's just that. It's effectively broken right now, um so yeah.

D

Yeah, no I'm I'm concerned. If we take the position of disabling it by default and not even having a flag, it's almost it's not equivalent, but it's it's! It's pretty close to we'll, never see it again.

D

um Yeah because I think, in my opinion, by default, we should see the change in the manage fields when we, um when we do a div, I think it's pretty useful to see who is dealing what and how the ownership changes. um But again, I understand it's not useful right now.

E

C

I think it can be useful, but those are, I don't know, for the average end user- that if I had to guess that's- probably not the part they're looking at they're, probably thinking about the changes that they themselves are responsible for.

C

I can see it definitely being useful to have as a capability, but I could see the like a use case being similar to get where you want to opt-in to having uh like it's quite a large amount of information in the output um where, like the default, would be for it to be off, but there'd be a way to enable it like. We do forget.

D

Yeah, I think I mostly agree with that. The the big difference with cats is that get is completely unusable. Oh it's massively disrupted by the very long managed fields and most of which you don't care about. uh The typical use case for diff is that you have like one or two lines that are changing because of the of what you just changed, and so it's not as disruptive as it is forget.

E

C

Yeah, it depends like if you expect to see two lines and you actually see 20. That's still pretty annoying.

D

C

D

But I agree with no: I we could disable it by default and okay yeah that's supposed to be an option. We could even not have the flag yet and add the flag as we fix the bug or we could have to I'm pretty. I'm pretty convinced. Eventually we want to have the we want to have the flag, so we could probably do it right now, even if it's slightly broken.

F

I'm inclined to say that if we would remove it, we would get an issue immediately that we introduced a breaking change.

F

So for just that sake of the, I would probably introduce the black, even if it will be disabled by default, then you'll have to explicitly say: oh yeah. I want to see the vantage fields and then try to solve the uh the sorting separately.

F

um I'm still seeing that as a separate therapy. I'm.

D

Perfectly fine with that.

F

Yeah from just showing the managed fields, I'm pretty sure that the majority of the users will appreciate the fact that it is that we're not showing the managed fields by default and those that will still want to see. It uh will basically get the previous behavior by um explicitly specifying the fact. And then uh we can fix the um the shorting separately, because something tells me that that may be a little bit a little bit more uh work. That will be required.

F

I'm not opposed.

C

To that, but I I guess I still think it's pretty weird to hide like have a feature behind a flag that just doesn't work like you said it's a breaking change, but I don't know if I agree with that aspect and that you know the the output right now is is not useful. We don't. We can't stiff those fields.

F

Yeah, but that's basically the same. What we did with uh uh with the managed fields and the gas.

D

Also, I wouldn't say it's poke and it's it's it's hard to read and it's not as helpful as it could be. But I wouldn't say it spoken.

C

Okay, if, if there is some way that you can yeah that, if there's some way in which is useful, then I'm fine with the flag.

F

I'll try to review the uh the pr on you.

B

F

If there will be no bigger issues, I'll just tag it as it, we can address everything else.

C

Since code freeze is approaching, um is there anybody here who has a pr that is sort of undergoing some discussion that we should touch on today as sort of a last opportunity to discuss as a group before code freeze.

F

Or, alternatively, if you have any one of us assigned to them and we haven't looked at them, feel free to bring us on back.

F

One thing with regards to your pr brand: I'm still considering the name.

F

I'm I just look because I don't remember on top of my head, the guest is show managed field, I wonder, but somehow the show managed skills just does not apply good for for the div command.

F

um That's probably the only.

F

Concern that I have, I don't have a good idea for the name. Yes,.

D

Yeah, I would rather be consistent than perfectly correct, so I think we personally, I would vote for using the same flag. We usually get.

B

Yeah, okay yep. I kind of I went back and forth on that and I think uh your point is right: it's better to be consistent than to be like 100, accurate and rather be like 99 accurate, and I guess I got hung up on semantics. There.

F

That's literally what I was just going back and forth in my head um and going through the code and like trying to figure out whether I I personally prefer consistency as much as I could you probably messed it up the first time when you did the show managed field, you could probably name it differently or more generically, but yeah. Let's, let's keep it consistent. I don't know just easier for people to uh to find.

B

Yep will do.

A

So I I added to the agenda with some notes: does that resolution sound correct? So are we agreed that we're the the diff for the managed fields off by default and then we'll have the flag to show the diff of the managed fields? Did I get that correct?

A

Yep, okay and the flag will be the same as the one for get on show manage fields, okay,.

A

Okay, that that's actually was the only topic we had for today so far, so is there anything else that anybody else would like to bring up, since we still have about 40 minutes left.

A

Okay, um I'm gonna put out a call for stand-ups if we have uh any of those anybody interested in ace, giving a brief overview. A stand up for a particular sub project.

A

Okay, I guess we're gonna, have a short meeting and give you back plenty of your time today um and uh I'm gonna stay on the on the call um and stop the recording.

E