Add a meeting Rate this page

A

Hello and welcome to the q builder controller, runtime and controller tools meeting for thursday november 5th 2020.. As a reminder, this meeting is being recorded and will be uploaded to youtube. Eventually, uh so don't say anything you don't want recorded for all posterity.

A

All right, so it looks like we have a few items on the agenda, looks like the first is from joe about server side apply. So why don't you get started with that? Joe.

B

Okay sounds good. um I have a couple visual aids, I'm going to just share my screen, really quick. um It's not like a presentation or anything, but uh hopefully can everybody see that.

B

Okay hold on, let me fix that. That's not what I intend to do, let's just um let's just do this- is that better um I'll, try and pretend okay.

B

All right so, uh what's going on is we want to add: support for server side apply in kubernetes client go implementation which really doesn't have apply right now. The only way that you can call apply right now is, if you use the untyped client and you provide a byte array of whatever you want to apply.

B

So that's not a great experience for controllers, which typically want like a type safe programmatic way of doing this.

B

So what I'm going to be doing is discussing some options on how to how we would support that uh just for reference, that's what plain old ghost trucks look like. I think we're all pretty familiar with that on the left. You have what the structs would look like for, like a kubernetes native type on the right is the corresponding yaml I'll, be showing some other slides of other examples in the same format.

B

So why can't? We just use the ghost structures they exist today. So there's a key problem which is in apply. You only send the fields that you want to own, so ghost trucks don't work for that because they have non-optional like non-pointer field values. That will that go will zero value in. If you don't provide anything uh they're, actually not that uncommon. I did a little audit there's a ton of required boolean fields all over the place that cause problems.

B

um So it looks like this would almost work and it would kind of seem to work, but then, if you actually get into the nitty-gritty and start using it for real for real stuff you're going to run into really weird corner cases where you accidentally took ownership of fields that you didn't intend to and maybe even set them to values that you didn't want to. So it's it's a little dangerous to go down that path.

B

um I'm going to describe two alternatives of doing this um and both have problems so bear with me as we go through them. One of them is to use functions, and this is basically the builder pattern. You may have seen this in other programming languages.

B

Basically, what you do is you say: I'm going to create a deployment type by calling a deployment function, and then you just chain calls to set various values for that. It still corresponds the line by line one to one with what we had in the go struct but you're using functions to do everything um if peop people have probably seen this in other programming languages, it's pretty. It looks very java like because of all the set calls.

B

Another alternative would be to use pointers everywhere.

B

This also has some really nasty quirks, so this one it actually works, not so bad when you're, when you're referencing other structs, you just have to put an ampersand in front of all of them now, um but with primitive literals go is not quite as nice, and so, if you don't get any utility support, you would have to like define the strings elsewhere, and actually I did this wrong. Then you'd have to put ampersands in front of each of them, so you would actually have to have one of these everywhere.

B

That's why you can't just put the string in line, and uh you could give yourself like a utility where you had like some pointer library that was, like you know, new in 32 pointer, and you just did that you did that function, call inline as well, and that kind of allows you to at least not have to define those um string literals in a separate section up above, um but it still it still dirties up the code quite a bit.

B

um I am currently favoring the builder's approach. I am not in love with either of these approaches, but um I will at least make an argument for it. So um I think I think, having to construct the pointers for pretty mobile literals is actually really inconvenient um and there's one advantage to the builders which is functions can be part of an interface um and because we're defining a new representation of our types.

B

We're now going to have two representations of those types. So there is actually potential usefulness to having an interface that they both share, and you could do that right. You could have a ghost truck that also implements the set function. There's nothing preventing you from doing that, and then you could have an interface that both these apply types have and that the um that the the usual structs that you typically use for, update and create and so forth, um also use. um So there are there is that potential upside now on the kubernetes go client.

B

We would then have a typesafe apply function, which would look like this.

B

It's pretty basic, there's not a lot to say about this, I'm just showing it so people will know this would be new, and we don't have this today right now. You can't call apply on the type to go client. You can only do it on the, um though I think it's called dynamic, the one that's untyped and it just takes a bite array.

B

So that's the end of my visual aids, um the only big open question I have um on this um on on the proposal. I have at least the direction I'm heading is. Do I really need to prefix everything with set um and there's the one main argument for doing that?

B

I really don't like having to prefix everything with that by the way um is that if we ever did take our existing ghost trucks and want to have them implement the interface, we can't do that if we name the function, the same name as the field because go won't, allow us to have both a field and a receiver function with the same name.

B

So that's kind of the constraint that encouraged me to consider putting the sets in front of there. I don't really like it. I think it looks a lot nicer in the example with the builders. If you take the set away, it actually starts. Looking like pretty straightforward, the main things I was looking for, um I can go full screen again um and the reason I brought it to this group one is this: is since it's a controller runtime group- and this really is all about controllers.

B

I think it's very important that this group know about what we're thinking about doing and get to see the design before we finalize anything right. I've gone back and forth on what the best solutions are, and I've considered a bunch of others that are in the design dock, there's a link in the agenda and at the top of this presentation too, if you want to see the whole design doc and comment on it, I'd really like to get feedback on that. I'm also very interested in anybody who wants to try this out.

B

um I have a generator it works. I have running examples. I can actually show one of those briefly here's a test in a pr of kubernetes where I construct an entire deployment. um I actually construct the same thing in the go types just to so I have something to compare against.

B

We send the apply call right here. um So that's this actually works and then right, everything's together. It's all working um no surprises. We have a bunch of like fuss-based round-trip testing, um so it's kind of all together, um but you know the generator could be changed to generate something differently right now, but yeah very interested in any volunteers. So if you are interested in trying this out, you could contact me on slack. I would be totally interested in any help I can get trying it out.

B

I can help to get the generator working with anybody that needs it working as long as you know, I can have reasonable. um You know guidance or some access to where we're putting the generator it's also available in the pr. So it might be that some people are just able to kind of make sense of it and use it, um but it's there and that's it. I will open up for questions.

C

Yeah, can you sorry go ahead? Zoe.

A

No joke go ahead hard. Who is that actually.

C

Is eric.

A

um

C

Sorry can you uh re-explain why a different um type scheme is necessary for this.

B

Yeah, so the problem is that when we define our ghost trucks, we don't make all the fields optional, um because some of them are required and that's really convenient, because then it means. When you do reference into a field, you can say something about something something if it's required. You know it's going to be there right. It'll get zero valued in by go um you're, not going to get a nil pointer exception doing that if it's a required field, you're guaranteed it's not possible.

B

um If we, so that's the way that we use ghost trucks today, we do that, both in coop builder and in kubernetes types. So that's how go that's types? How types exist?

B

um It's because there's not a there's a lot of things in our pointer types, so some fields are just some just some struct, but it's not a pointer and what that means is when you serialize those um and there's a bunch of cases, there's there are some cases where, if something is the zero value that we do omit empty and we don't put it on the wire, but that's not always the case, there's a whole bunch of cases where we still put it on the wire. So basically what happens?

B

Is you have these fields that are always included whenever you series an object, you're going to get a certain amount of things in there, and it might be only if you add, like some substanza to the object, but once you add that, then a bunch of fields get pre-populated, that's not compatible with apply because apply. You should only include the fields that you really have an opinion about and want to say what their value is, because when you apply that you're going to take ownership of those fields.

D

I've seen this be a problem when the struct has a boolean and when you try to do the apply, the zero value is false, but you don't want to change it so when it gets serialized, it's sending false and then you end up changing your true back to false and the only way to do it is make it a pointer and that's your second solution and that's annoying yeah.

B

Yeah, um the booleans are by far the most common. We actually wanted to see how much of a real problem this was before we fixed it, and what I found was it was the required boolean fields were by far the most likely thing you were to hit yeah. It's it's an annoying problem. It would be great if the ghost wrecks just worked.

B

um Changing them to work, unfortunately also comes with a pretty heavy penalty, so I I kind of uh and in the kubernetes types I can't change them right like they are part of the api. They are forever um for my for my design purposes. So I have to assume that they're not going to be able to be changed, um so I have to introduce something new which.

A

Means interact with the existing.

B

Types is a consideration.

A

uh So I think what I was going to say earlier is, I think, the the quickest, like the easiest way to make this uh test this out, with existing controllers too or might be existing.

A

I should say existing controller runtime controllers might be just to make sure that um so our our patch function on our client has support for like pluggable patch types that can be implemented like either entering controller runtime or out of tree. So if you wanted, I I can't. I guess I can't speak for the other folks here, but like probably the easiest thing to do. If you want folks with controller runtime controllers, to try it out would just be to provide a plugable patch type.

A

uh Okay, that you could use with our apply function like as a snippet of code or in a library somewhere, and then you know all right. We could just drop it in an existing controller and call call client.patch with.

B

It that sounds great yeah. Let me follow up on that and then once we have something available I can I can recirculate it with the group. I think that's a good idea.

E

Okay, quick question.

E

Sorry, um when you said like it's annoying to work with the I mean, I agree, it's annoying to work with the pointers to fundamental types. But what are exactly is the friction you're worried about. Are you more worried about when you're reading them? Are you more worried about when you're trying to define like a structured literal with with these pointers,.

B

With apply, we are more concerned, apply is right. Mostly it's a right muscle. Use case you write applies a lot more than you read them. We think there will be some read use cases. The truth is reading them. No matter what you do, all the fields are optional. There's no getting around the fact. You're gonna have to check for the presence of things if you want to safely de-reference into it. um So that's actually not so much a disadvantage with the pointers. That's just a problem with apply.

B

um I I think I think the thing that was, I mean the two things that the two things that were biasing me towards the builders were one go, doesn't really make it easier to inline um literal pointers, it you can't just say: ampersand quote string right like logically, we know what you would be intending to do that, but go just doesn't allow you to write that you have to you, have to assign a variable to the string somewhere else and then reference.

E

It so I I put a thing in a chat, which is what I always do, which is I just have these helper functions that they take like they take the bull and they return a point.

D

To that.

E

Bull and that all works like it knows how to throw that into the heap, and um it's that's having a few of those actually makes it not that bad to define.

B

Yeah, I think that helps I think if we did the pointer approach, we would definitely want something like that and we would have to somehow educate people to know that that's available to use it, um which is a little tricky right. People might not necessarily know that.

E

But I.

B

Mean.

F

It sounds like there's an education either.

E

Way you go because you're gonna teach them this whole thing or you have to tell you know, show them examples with that. I recognize the front. That's the truth.

B

Yeah and then the other advantage of the builders is that you get since now we're introducing a second representation of types. There are some advantages to thinking about. Well, are we going to want interfaces that both types can share and so like? If we're going to do that, maybe we should just start with the interfaces, which is basically what the builders do you build? It base everything around functions and you can define interfaces for all that um and then other types can also implement those interfaces.

B

It's it's all about this mirror.

A

It's also just so visually distinct that you don't you potentially don't make accidentally make a mistake right, like you, don't there's! No there's! No! Like! Oh. I accidentally passed uh like a concrete struck here versus a pointer only structure whatever, like.

B

Yeah, that's actually that's actually an upside.

D

The one downside.

G

I see.

D

With the builder, is your end up with one method for every I guess attribute, whereas with the pointers you end up with a fixed number of helper functions, one for boolean, one for string, one for ant those, so you have less, it seems almost less intrusive.

D

It's not just nice yeah. I think the builders are easier to read, but.

B

Yeah, it depends on how you're, looking at, if you're, in an ide and you're, like you know, you've got some utility. That shows you what options you have you're, either going to get a list of functions, you're going to get a list of fields and they're going to be more or less one-to-one.

F

One drawback of the pointer approach- I think, is also that you could accidentally set a field in the substrate, that's nil and then cause a panic.

F

Because all the types are composed right so.

H

Having a little.

F

That has a pot spec and the pot spec has, I don't know the image attribute. You set the image but forgot to set the pots back. Then your code will panic.

E

Right, but not in a literal, if you're doing literally, you have to have the full path down there.

F

Yeah yeah, but in the point I thought we would need to have everything be a point of view right.

B

Yeah I mean the one thing to notice about the pointer approach is actually any problem you're going to have with it you're going to have today with the go types, because we do make a bunch of stuff optional and they are pointers.

B

So we already have some pointers. It just would be going from some pointer to all pointers, so we wouldn't be introducing any new problems, but if you, if you have had a problem with pointers on the ghost truck types, that same type of problem would apply here,.

I

Do you have um acceptance criteria defined for this? Is this going to be fairly subjective and just kind of a poll, and is there a time frame associated with.

B

uh There's a couple main things that we want to achieve. One is that we want to show success with at least one kubernetes built-in controller that it works.

B

We had a bunch of testing criteria to make sure that it's actually sound right, like the soundness of this is really important, um but I I think the like the the usability of this is really key, and so I want to do more than than meet like like yeah, I kind of basically I want. I want there to be a requirement where, like peop enough, people have tried this out and said like this works.

B

For me like um like it's like it's agronomic enough, like I didn't like whatever rough edges we found, we we looked at, we considered, we did the best we could like. I don't want it to go out with like unnecessarily rough edges um after working on it for like a couple months like I don't know how to get around some of the rough edges, but I would like us to try as hard as we can, um and I think that there's probably some left so I think, having people bang on it. Try the alternatives.

B

It might be that, like we actually generate the pointer structs at some point for people, if, if somebody's is very curious, what the alternatives feel like when they actually do development um yeah. I would really like to get like a couple: successful use cases where people tried this out were able to do what they wanted to do um and gave some really good feedback.

H

um I got a couple questions is: are these options mutually exclusive like could you have the points trucks but then also have the builders that build the corner trucks.

B

They're, not in fact right now. The way I have it implemented is. I have an unexposed um um struct that with everything optional behind the builders- and I could just expose that right and like then you would have both um it's it's unclear to me. If it's a good to be that unopinionated about this, to start with, because I double my api surface area um pretty early on in the project I mean we could always add that later.

B

um But if we add it now and it becomes part of the api, we can never remove it. So I'm biasing towards trying to figure out which one of these two works the best as soon as I can um and then move forward from there and maybe in the future, at both or maybe it's the result of feedback from people they do say like actually having both is okay and I'm. Okay with that. If I got a bunch of feedback like that, we would definitely like reconsider it and just expose it because it might be.

B

It might be that like for everything, but the primitive types um just using the fields is fine right and if somebody, if somebody showed me some use case and said like, I actually like my pattern in usage- was to do x and it worked really good for me. Then that would be pretty motivating.

H

Yes, so that maybe the related question I have is have you thought about the case of unmarshaling into a struct like let's say I have a yaml file? That is the patch, and I want to unmarshal that and apply it. Does that work with the builder pattern.

B

Yeah, so right now the builder I have, um I have a compatibility matrix, so you can take either ghostrect or yaml, or this thing called unstructured, which is how we do a bunch of dynamic, stuff and kubernetes. You can get those into into the apply structs and out of the apply structs, so you can move it around.

B

So you could do something like start with. A yaml like a load of yaml in to apply builders, make a couple hand changes with the builders to fields that are dynamic or that you're templating with and then finish it out right, I'm not sure, that's the best way to template, but um you you it's. It supports that right, that's possible!

B

Okay or you could.

J

Throw.

B

Yeah or you could start with a ghost tract and then like do something that's a little sketchier because, like you, might accidentally default something in from zero values, but you could do things like that. Is there.

H

So if the, if the actual underlying structs are unexported, does that cause problems with wanting to pass um those things around between functions.

B

um No, uh the the the the way yeah you, you don't even know they're there. Basically, you have like these. These apply configuration types that represent everything and you compose everything on those got it: okay, yeah um now, if we did expose the structs we'd have to work out like what types we represent, but, for example, one thing that we do is in the apply function that I generate where you can actually call apply. So the server side applies run by the server.

B

I only take an apply configuration so right now you can't pass in a ghost draft and that's very deliberate right. I don't want people to accidentally think that they can just pass in the normal kubernetes go struct, because they can shoot themselves in the foot doing that, for the reasons we discussed earlier, um so you it right now. The two types are very distinct.

E

um So the question: have you looked at how much all this generated code affects binary size.

B

um I can check I actually expect it will have fairly negative size because of go right like a go, is only going to include into the build like your binary what you actually used. So I I expect that it's going to be pretty moderate, but we can check that.

I

I know this was introduced and probably appropriately so with a go focus, but there are other clients. Is there any consideration at all on alignment to other languages and it seems like the builder pattern, would align, probably better than than.

B

Yeah, I did think about it a little bit. I um I wanted to get one language right as a reference to start with, and that's typically bingo, I'm very interested in going and making sure that we do other things in the other languages, so any design feedback that people have that also applies to other languages would be really interesting because I would like I would like the next language implementation to be easier, because we have like all the thoughts that we put into this one.

B

So hopefully we can. Hopefully we can be a little bit successful in there. I don't know if we can provide super con free grinders for all languages yet, but I I think whatever we do here would guide a lot of type safe languages pretty well and then, hopefully, um hopefully, for more dynamic languages. We could, you know, start getting some warnings too.

A

I I I'd probably just briefly point out that a lot of modern type, safe languages don't have the edges. The rough edges around the optional fields that go has so like. If you look at rust, for instance, you have like a concrete option type which makes it easier to define optional values, inline um and then, if you're, looking at like dynamic languages like python right, you you, you have support for like making any field, none um potentially so like yeah that that is like.

A

I think I have a suspicion that there's better better idiomatic patterns in in many other languages, um but that's that's just a hunch.

B

Yeah- and I wouldn't want to prescribe something under the other languages that wouldn't be a good fit idiomatically for them right. So I maybe some of the best feedback is why why you need to make sure that apply is doing what you think it's going to do in your language? Why? You can't just assume that your existing types work?

B

Maybe they do, but maybe some of that guidance, and then there might be some languages where it's a little bit a bit of a fit, but like any language that has an option type I think like it should probably use it and use it appropriately.

E

Two two other questions, so is this gonna be prescriptive? This would be the only interface to to apply.

B

This well at least for right now, there's zero, so I'm going from zero to one, uh at least in in kubernetes itself, um so for client go um well.

B

I'm going from you have the option of passing in the byte array of yaml or json to having that or this, and I would I'm hoping I'm hoping that we come up with an approach that would also work well with whatever we do in coup builder and controller runtime, which is part of the motivation coming to this group, like I've gone a little bit back and forth on what the best approaches are, but I'm hoping that we can reach agreement on where the trade-offs you know what what is best given the trade-offs that we have so that whatever we do in cube builder for apply in this space is very similar.

B

um I I don't like right now, I'm just like. I have a very specific implementation that uses like go gen, which has certain constraints, um so you might not be using the same generator, but you know if the approach makes sense, then presumably we would kind of follow the same pattern.

E

But when you were talking earlier about the the shared interfaces, like is the intent to be passing around these builders and doing like a late, build or because that's not necessarily how I'd think about traditional builders. You kind of like build them and then pass around the concrete types.

B

uh Yeah, so basically the way the builder works is it it? It's not actually called a builder when you call the types it's called like an applied configuration types. You have like a deployment applied configuration and you just call set on it and sets just happen to return that same object again, so you can chain them, but you end up with an object, and that object is the representation of that thing, so you don't actually have to call like a dot build at the end. That's the way I'm imagining this.

B

uh Does that answer the question.

E

I think so and so okay, you would you'd be expected to pass this around, like I'm really interested.

D

In.

E

Interoperability and how prescriptive this is. I think that there's gonna be a lot of subjectiveness around I like to use structs because that's go right like and yeah.

D

So.

E

I wonder how and I look at this and it's like oh, this looks like java. No thank you. So I think there's. I wonder if there's room to leave choice to the actual users.

B

uh Probably the best way to leave choice would be to expose the fields and take that trade off I am we could yeah. I think I think the two are either we. We would agree that pointers are actually the way to go and we're going to take that hit um or we expose both um like we expose both the setters and the fields and let people pick or those would probably be the two that would go that route.

E

And that's what protobuf does right.

B

I think it does does it do both. I think it does yeah. um So I would be very curious in fact, what we might want to do. If we do a controller, runtime experiment would be to expose both and let people try and then have them come back and tell me like. I tried both and I ended up using this one and here's why that might actually be a better experiment than just like giving them one.

I

I think what might be slightly different, um the example that I remember you showing was kind of um from greenfield right, you're, creating a deployment. um You know from a controller standpoint. What I would expect is I'm pulling something out of a cache and when making a copy and then making some modifications- and I my thoughts currently are around- you know how to what would that look like.

A

Oh sorry, yes, no! No go ahead! uh That's that's! Actually an anti-pattern with server side apply. If you read the existing object, you're gonna, take ownership of um fields that you didn't intend to um with server side apply. You always want to specify from scratch.

A

By by and large.

I

So it sounds like it sounds.

B

Yeah, you don't really need to do a read, modify right, you just you just you just figure out what the state of the fields you care about are and write them unconditionally. Usually.

A

um You, like I, I to your point. Maybe I I I realize I interrupted you a bit there um like there may be a few fields where you're setting them based on other things, but a lot. I a lot of the stuff I've seen like you end up constructing most of the object like wholesale.

I

Yeah, a lot of my experience hasn't hasn't been upgraded to the server side of play. Yet so I'm a little bit behind, but I appreciate it. It's great stuff.

B

Awesome well, I've got a bunch of useful feedback. Thank you, everybody. I will follow up um and I will probably circle back with um in you know the next meeting just to let people know where we're at what's available.

A

All right, thanks for presenting joe and sharing with us and stuff, um definitely look forward to seeing what happens there and give being able to give feedback and stuff um looks like the next thing on our agenda is from zeus. Yes,.

D

Yes, I added a uh agenda for the wondering when we, when 0.7 is slated for release for controller runtime, um we're we're trying to plan for kubernetes, 120 and kind of figuring out the timeline, because I we assume that zero seven needs to come out before we can start doing any 120 work. And um so I just wanted to check where we were with that.

A

uh Yeah events- I I don't want to put you on the spot too much, but um I think I think you probably have you you and camilla. um I think, and gabby probably has some of the best knowledge of like the state of things. um I think there was at least one thing that we wanted to tackle. That might be a breaking change that we might want to tweak before 0.7.

A

um But do you all remember anything else.

J

um So I guess like most of the for controller runtime, specifically most of it is actually ready. uh Apart from the web box v1 right now, we still speak v1 beta1 admission review um and that required some changes as well in control of tools.

J

There was a whole conversation with jordan leggett um in terms of timeline. I honestly don't know, uh given that we I mean I don't know, I haven't been able to concentrate this week that much, but um we can set like a specific date. I don't know, maybe two weeks from now um so the 19th 20th.

J

We can probably really zero seven zero, uh but tags are available for alpha if you want to check check it out and we can use those um for 0 20 well, the for 120 like if we want to update dependencies and like cut 0 eight right after we got zero. Seven, I'm also. Okay with that.

H

um Are there are there breaking or other blockers? I know you mentioned like the admission web hook stuff. Is that a blocker for zero seven being released, or is that nice to have.

J

I would I don't have time to do it right now, but like there is, um I would like to fix it before we release, uh because that caused me and others. Like a lot of confusion and like I, I like to pretend that I know a bit about controller runtime. So if it got, is this causing trouble to me like it? Probably it's gonna cause trouble to others, um and we need to document all the breaking changes as well, which is that I would consider a release blocking thing.

H

Yeah, I guess my follow-up question that is related to that um there's going to be a bunch of breaking changes in zero, seven that impact how we, I think they impact how we scaffold projects um correct me if I'm wrong. So if that happens, then we also need to block acute builder release.

H

Well, we can keep releasing q builder to be using zero six, but when we go to zero seven, we will need a basically a brand new plug-in uh because we're gonna make a bunch of breaking changes in scaffolding. So I assume what we're probably gonna do unless people disagree with this is to hold the v3 go plug-in. That's currently, like you know the next one up wait for that: to wait for zero, seven to be releasing controller runtime and then update that to use zero seven. Is that what we think the plan is?

H

That seems reasonable to me. Otherwise, we'd have to go like almost immediately to v4, which seems like a bad experience for people.

G

Yeah.

C

I've got an issue open in the queue builder repo that details what we need to do right now. It's just up update uh kubler, declarative pattern, which I have a pr4.

K

I'm just.

C

Just.

K

Sorry.

C

Yeah, just for v3.

H

Are there other? Are there other user facing braking changes or cue builder, facing braking changes that we want to make that are not in uh master yet or not slated for zero seven? Yet, because that would that would basically again necessitate when we go out with zero eight. That would mean a v4 cubicle plug-in. So I'm wondering like do we want to try to get all the braking changes in now so that, when we bump to zero, eight q builder doesn't have to have a new plug-in.

A

I think that.

K

Was.

A

Oh go ahead: quinoa.

K

No jesse, I would like to understand because, for example, if we in my mind, suggest it to clarify, if we release cool builder now we have a 3.00. We have the v2 plugging as the phone that you can cannot have the brake chains and all brake chains. King is still going to between alpha, but when we make ev3 alpha stable thing, we cannot say so longer working with it breaking things on that thing, you need to do the v4 or anyone about that. Yes,.

H

Yeah, sorry, I'm talking about v3, I'm talking about the v3 alpha plug-in.

K

So I think, in my mind, would be very safe. We do a release now with ev3 alpha, but after we need another release. When we build with, we be stable, you know, and they did a full one.

K

Probably.

H

Three releases.

K

I was in mind.

H

So I think like let me let me step back in jesus if you have anything else to add, go for it, but I think what we're really getting at here is zero. 19 is like we're on track to get control of supporting 019 about the time that we're one 119 about the time that 120 is gonna be coming out.

H

I think I know maybe it'll be like a month early, um but I think what I'm suggesting and I'm hoping we can start driving towards us having control of runtime much more closely aligned with the upstream kubernetes version such that when 120 goes, ga we're you know, maybe no more than a week later we have a version of controller runtime and a version of q builder that supports the latest. Ga, maybe that's a pipe dream, but we that's kind of what I'm hoping we can do.

A

We have done that in the past. It varies from release to release. Sometimes we have a release out real, quick um and sometimes we're real slow with things just for whatever, like that's, not a judgment, that's just a like, for whatever reason.

H

Yeah- and some of that I think, is definitely understandable, like like we had the 118, where a whole ton of stuff broke with client go that might have taken a little longer.

H

In this case, we have a whole bunch of breaking changes on zero, seven that are going to necessitate some changes to queue builder, that's going to take a little longer, so I guess I'm hoping like we're if we're far enough in advance of 120, now that if we can talk about all the things that need to go in in what order, then we might be able to make 120 faster. That's what I'm hoping for.

J

Yeah, I think I think that that makes sense to me um in terms of timeline is, can we just say, like maybe um the 19th at one year like a week or before control run time so before thanksgiving.

J

Should we.

A

What day is the next uh of these meetings? Should we sync next meeting and like try to get try to make sure like in the interim two weeks we're good and like we get all the features in and we do all the review and then like do a sink next meeting, make sure there's nothing final, that's about to explode or like we realized that we left a pizza in the oven and it's about to burn or something um and and if we're good next meeting, then we just release that day.

J

Yeah, it should line up it's. The 19th is pointed out in check.

A

Okay, um anybody have any concerns with that plan.

H

That seems good to me. Do we have like do. People know that there's work to do and that we expect them to do it.

A

We, let's, let's send out an email on the mailing list and um on the on the slack channel and we'll just say, like hey two weeks till this happens. If there's anything we need to get in.

A

Let's do that now: okay,.

H

Yeah, I'm obviously happy to volunteer to help out with that. Is it? Are we just looking at the v07.x milestone and, like that's.

A

The list, I think so um in case any unless anyone raises any last minute changes: okay,.

A

um Yeah joe, if you, if you could send out that email that would be awesome yep, I can do that.

K

Has one thing that maybe someone here could help has cheap peaceful requests uh that I put in the set? uh If someone fuji review in japan, I believe it will be helpful for we try to update the their free alpha.

A

All right, yeah.

K

I don't have a degree.

C

Yeah, I I think, that's my pr, so I can follow up with uh justin. I guess who's assigned to that pr in the kubernetes slack.

D

Thanks folks, that answers my question.

A

All right, uh the camilla was the next one, just a request for someone to do the push.

K

Yeah, I have a two things. uh Yes, the push. I need to help you with that already being boring, but yeah. I don't have the permissions so.

A

Yeah was this just uh um the I guess.

A

We're we're expecting upstream next release to to actually be part of core kubernetes right.

K

I spoke with the the help owner. He told you that he would keep him in the loop, but you didn't start the process to donate besides the intention, so I don't know how long.

A

Can we just get like a cloud build script for our purposes, then so that, like we, don't have to ping someone with permission to to push directly um every time sure because, like I there's very few people on the hot path right now that have permissions to push to to push directly to that registry, um which I think is like probably a good thing like we don't want too many people with direct write. Permissions we'd rather have automation and ci doing the push.

A

I I would prefer to have it be similar to the way we do our release, tools and stuff like that, where it's just like, we have cloud build and we we tag. We tag a tag on a branch and it just pushes um I I would prefer to have something set up like that. Instead of just having to have people manually tag and push.

K

Sure, like.

A

Things I.

K

I I don't know: how long can you take the donation process so yeah.

A

Yeah, that's that's my thought, um yeah and I I also apologize for being real, like unresponsive.

K

No, I know you, I know that you have too much in your plate. uh Nowhere until the other thing about we did it is in sdk.

K

We need to immigrate to evis, because because the person has the information in the issue, I also was thinking. Why not see we replace the travis by getting her actions. If nobody has objections to that.

A

Yeah we already have a bunch of stuff on actions anyway um and I never finished pushing it, because if you has some rough edges, but I'm I can, I can push it. I had some code actually that I worked on that takes the results of our um a lot of our test, runs and and pipes them into github actions in a way that we see like inline code annotations for the um individual test runs in addition to like the lints and stuff, um which means, like you know, nicer, test output.

A

You can just like view them as comments on the code or check run. Annotations is the technical term, um so I would be in favor of doing that. Assuming there's no like serious performance, implementations or like budget like assuming, we don't accidentally burn through like org budget for github actions or something, but I think we're probably good there. um So I'm. I would be good with that.

K

Really, nice, you know, and if a scientist you ending today, I think it's possible, we probably migrate. Should we get to the actions but see if I see that we are not able to achieve the goal uh in the timeline io. Thank you uh just to migrate. I believe it joel's gtt thing was easy. I don't think I have the permissions just because that I need some. We need someone who that has affirmations to do.

A

Okay, yeah yeah ping ping me and I I can I can do a switch over. I seem to recall last time we had to do a switch over like that with travis. It was pretty straightforward, so.

K

Yeah but let's try to remove it for getting attractions. I think you'll be nice. We didn't, I see we think.

L

I agree cool awesome.

A

All right uh and then I think the last one was kevin.

G

Yeah, um so just real quick, uh a few meetings ago, we discussed a proposal for enabling greater control over the controller lifecycle, uh specifically by making it possible to shut down individual informers.

G

One of the big open questions is whether we could get upstream support from client go and sig api machinery to make it possible for shared informers to shut themselves down under certain conditions, such as when the crd it's watching, is uninstalled from the cluster and also seeing if we could get greater support on um on tracking the event handlers that are installed on on the on the informers so being able to remove them, or you know, count the number of event handlers, and so um I put together a proposal and a and a work in progress implementation for how we would do that upstream and brought it up with uh sig api machinery yesterday at their uh bi-weekly meeting and um so far everyone seemed pretty on board.

G

So we got the green light there and that's kind of the next steps for, for this is just to push forward the uh the upstream changes with sig pa machinery and then um circle back and, and um you know, update, update the controller runtime stuff along the way. And um that's just that's just the update there.

A

Awesome uh does anybody else have anything that they would like to discuss on that point or anything else, that's not on the agenda that um what they want to discuss.

E

What are the next steps with, with uh with them.

G

So is that what are the next step with with this.

E

With uh the changes in api machinery.

G

Yeah, um so I've got a work in progress, implementation up now, and uh basically just just uh continuing on that pr and uh there's uh right now: it's in a state where it works for our use case and for the uh like the resource quota controller.

G

So one of the big things is that um you know we wanted a solution that both works for us and also works for uh the current issue that that uh controller manager is seeing where um the inability to shut down informers kind of creates log spam in garbage, collector and and resource quota, and so um resource quota is working. But the garbage collector is a bit more a bit more nuanced or has a bit more complexity to it.

G

So I think uh going to have to work through how it's going to work there, but I think it's just pushing pushing that pr forward and hopefully landing it in in api machinery sometime in the in the next few weeks or so um is kind of the next steps. There.

G

Cool.

A

All right, um if nobody else has anything they'd like to discuss, we are almost at the hour, so perfect timing, I'll see y'all in a couple weeks.

G

Thanks see.

A

Ya.

C

Bye.
youtube image
From YouTube: Kubernetes KubeBuilder Meeting 20201105

Description

KubeBuilder Meeting for 2020/11/05. See https://sigs.k8s.io/kubebuilder for more details.