Kubernetes KubeBuilder Controller Runtime and Controller Tools, 8 Jan 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes KubeBuilder Meeting 20200108

Description

KubeBuilder Meeting for 2020/01/08. See https://sigs.k8s.io/kubebuilder for more details.

A

So hello, good morning, this is the queue builder and controller runtime and controller tools as well. I, don't know why controller tools is not on this list. Meeting for January 8th in 2020 started the decade as a reminder. This is being recorded and posted to YouTube publicly, so do not say anything that you would not want recorded for all time for your children to hear or for grandparents or other people all right. So ah there's only one thing on the meeting agenda for today that I can see so far and it's the ongoing plugins debate.

A

So if anybody has anything else before that, it's probably a good idea to talk about that. Briefly, if it's quick and then we can move on to that I.

B

Will bring up something that I bring up in a lot of these, which is? Has there been any discussion of bumping to cube 117 dependencies I.

A

Think so, at least for controller tools, I think there was a bump I think it's just a matter of submitting the DRV.

A

All right, anyone else have anything they'd like to talk about briefly before we jump into.

A

A

Discussion about the proposal for plugins and seal the COI package and Lana.

A

All right so basically I just wanted to take some time and see. If maybe we can, we've been going back and forth and I think there's a few avenues of different.

A

Ideas that have been thrown out and a few avenues of discussion and I want to see if we can kind of maybe talk about it a little bit and unify them a bit and maybe get a more concrete path forward.

A

All right so I'm happy to start or if Jo, if you have anything you wanted to add it, throw in since I think you submitted the PR.

A

B

A

B

Can I guess I can talk a little bit, Eric might have more to add Erica's been helping too so I. My impression is I think we have like at least a base set of agreed things like we want to have a name in the version it seems like. We are okay with the proposed, like interfaces for what a plug-in would look like in terms of the basically to support the having this help and also like having like the run thing that the Cobra can use under the hood.

B

So what I'd like this dynamic then detects things based on the project file or a flag and can use the interface implementation to to run whenever plug-in code the plug-in finds it seems like we're all good there. It seems like the the thing that we and you can graduate I'm wrong either. It seems like the thing that there's still debate about is like how do we layer different plugins? Do we want to be able to support more than one root plug-in at a time?

B

Do we want to be able to type plug-in input to output and then, if the answer to that is yes immediately right now, then it seems like there's gonna, be a lot of debate about. How do we manage? You know the configuration for those and what the compatibility between different plugins for those seem like the big question.

A

Yeah, it seems like there was also some like minor questions about like that, for the interfaces do we want to have like a here here. Is this plug-in? It has a different interface for each command or do we want to let plug-in say, like you know, tell me the command, that's being run and I will tell you whether or not I I want to work with it or like here's. My list of sub commands that I support that seems like it seems like it was another open question.

A

I did another read-through yesterday and tried to work through the current state so I? That was one of the other things I wanted to maybe see. If we could hammer out today, yeah.

B

That's a good point. Obviously you could probably tell by my proposal that I that I think I prefer the like explicit interface, definitions and driving like the CLI knows about all of the interfaces and can explicitly run them rather than to see I like to see lines discovering itself via the plugins, which seems messy, I, guess.

A

Okay, so I'm gonna, I'm, gonna I, think I will give my opinion on the first question you brought up and then that maybe influences this the opinion on this one so I think I think probably for the sake of like actually getting something done.

A

We should come up with a solution that will allow us to expand into piping, but like not tackle it now, cuz I think I I was I will say. I was initially hopeful that we could do them both together, but I I think practically it's it's making this more complicated and so I think we should like think about in a very hand wavy way like.

A

If we did this, how would we then introduce that ah yeah and then like be like okay as long as we're not painted into a corner so that, like in a in a month or two or whatever, when we decide to introduce the piping or whatever we don't go like shoot that right? There's just no way to do this.

A

So I think I think that's the case. ah I agree.

B

With that approach, that seems like a reasonable way forward. It it pretty just up to not have to think about the more complicated piping, plug-in scenario, but it also like we do need to at least consider that, when you're coming up with the current set of designs and implementations for.

A

So for the second question.

A

The only thing I I'm kind of split between the two between the explicit interfaces versus the like ask the plug-in. Does it support this series of subcommands I would lean slightly towards ask the plug-in? Does it support this series of sub commands, but simply because, like from a type perspective, I like the explicit interfaces, but from a like in the future? If we want to allow things like you know, on all create commands or all commands that generate, you know go code which, just might be like.

A

Let me see all commands that are being rotten because I want to add something in like I want to add. Docker, ignore files or I want to basil, build files or I want to. You know like stuff like that.

A

That might be a slash might be. Slash, probably is easier with the like asking the plug-in, um but I don't know if, like it's compellingly enough easier to motivate not doing the bases so.

B

I guess I guess maybe a little. You could probably helped me understand a little more so the proposals in the PFC code that exists right now. Basically, it is asking the plug-in. It's basically saying hey plug-in. Do you implement in this interface? If so go ahead and do your stuff? If not, then you don't implement the interface I'm not going to talk to you anymore, regular.

A

B

Maybe to do a hybrid approach where it's still likely I suppose an interface that has explicit commands, but maybe it's more extensible to like not being so embedded with building the CLI. Now, maybe that's like the maybe that's the one area where there's some debate I mean.

A

It was mainly just that, like with with a with a plug-in system like that, if you wanted to say, run me on every command, you have to just like copy and paste your interface implementation for every command that you want to be run on, which is like not terrible but kind.

C

Of annoying right, like where I think yeah someone's going to end up getting that and then we're gonna go back to like three controller runtime Bay is like and I think we want. We like this thing was made, so we didn't do that. So friction.

C

A

Yeah I mean it's possible to do a hybrid approach to like we could have the explicit interfaces and then like a special wildcard interface, where, if you'd implement the wild-card interface, we will we will like ask you right, like you can either say you know, run create API or you can say you can implement like do you want to run sub command and then like a slice of strength for the sub command? And then, if you implement, do you want to run, then you get asked if you want to run.

A

If you implement create API, you always get run on, create API. Do.

B

You think so the one the one problem I can see what that is like is there a way that we could still incorporate that plugins flags, help examples etc into the help absent, or would this be like a totally like you, don't see anything about this plug-in on the help output and it just runs at runtime, so.

A

I've been playing around with that I was playing around last night um I.

A

Haven't figured out a way to do it with Cobra, but I figured out a way to do it. You know I figured out a way to do it, not with Cobra in a way that still supports Cobra sub commands, I, think ah cool, but the other thing that I wanted to bring up is I was playing around with your example and I. Don't know if, like I messed, something up when I was playing around with it, but it didn't like that.

A

Initial pass on the flag, parse didn't seem to quite apply properly like it wasn't behaving like I. It was, it was not. It was not doing what it looked like. It was supposed to do like the hack, where we try to parse the initial flags to see what plugins we want and then we.

A

Yeah so I'm, I and I'm, wondering if like I, was wondering if we needed to it's unclear to me. If we're gonna need to do some things to work around Cobra anyway, with that cuz like that, I'm, not I'm sure how nicely Kover is gonna want to deal with with stuff like that.

B

The other thing that I thought about with this, so in SDK we've started. This is maybe a really minor detail that we could probably work around, but one thing we've started doing in SDK is automatically generating help. Markdown cars based on Cobra, like over I, can just spit those out, but if.

A

B

Doing this dynamic discovery of setting up the cobra commands based on file that exists in flag that he was like, you can't possibly come up with the full help for everything, that's supported by the CLI. So that's a minor problem that would be interesting to solve as well I mean.

A

I think I think you actually.

A

hmm I think I think you can, if you just basically say um like you, have a prepare. You have like a prepare phase where basically, every plugin gets to declare like a modification modifications to the help and stuff like that, and then I think you could probably just loop through the plugins and then loop through each of the commands cuz it's still fixed, even though we're like asking the plug-in what it wants to do with the given sub-command we're still, we still have a fixed set of sub commands right. We're not saying we're.

A

Accepting arbitrary, like you can't be like you could be like I, accept, create Turtles, but we're never gonna. Ask you we're. Never gonna call you with create turtles, because when you call when you type create rails on this man line, it's gonna be like that's, not it. No, it's not anything.

B

But the weekly I think the that's problem, I'm thinking of maybe maybe you're you've already figured out solution to this, and the problem thing of is like, if you say, coop CTL create they're actually qcj on this, but cou builder.

B

Depending on what prodding burden flag, you tell it you're going to get a totally separate help output. So I guess what you're saying is we just iterate over all, regardless of what whatever flag project version is were not doing that as far as generating them? The docks and we'll just generate one in it. Helped dock per project version.

A

Yeah, basically, you I think you have to write like you kind of because, like the help, for you know, create API with project type, helm is completely different, presumably from so like you kind of have to have like man queue builder and knit home and Mankiw builder in it go right anyway,.

B

That's probably a major sort of the proposal, but something I've been considering out we're doing that in SDK. Now that's.

A

That's a that's a useful thing to do, and I like I like the idea, um I think it would be cool. We should probably like this is like a eventually unless, like you have someone on your team, that, like is really bored and wants to do this right now, I would love to do something like that as part of the docs build pass and then just slurp it into the reference section in the book.

A

So you know how, like we have like references markers and we have like controller tools, just spits out all the markers it knows, and then we turn that into HTML. I would love to, like you know, same thing for queue. Builder uh I was not aware that I don't think. I was aware that Cobra did that for you so like, if we could take advantage of that, it would be really cool.

A

Yeah I, don't see why not we put in the back load or if anybody is on the call, that's new and like once an interesting way to jump in. That's definitely like would be super appreciated.

A

D

So, just just a quick note on weird talking about so I implemented the plug-in system, as the proposal for COO builder I posted that branch. In my most recent comment on the PR. So if you want to take a look at that and play around with it, the CLI has not been set up. Yet I will do that fairly soon, but yeah. If you want to take a look at how that would okay.

A

I completely missed that comment. It was I think, looking at an older, a different one: okay, I'll I'll I'll take a look at that. I was looking at the queue bill directs. That was the original one I put together ya know once ago, yeah I'll take a look at that, and I can post like this stuff. That I was playing around with the TLDR.

A

Is that before we went on break I got really frustrated with the fact that none of the flag, libraries like let you just parse the flags and like not do anything with them, and so I wrote like just like a thing for scanning and parsing out like command lines.

A

So for some of the stuff where we have to hack around Cobra. To like do an initial pass before, like do an initial pass to like figure out what the plugins flag is set to, we I think we should be able to use that, and in fact, like I have a working prototype of like doing an initial pass with that that I.

D

Wall post somewhere- oh that's, great yeah, yeah, I,.

A

Called it CL y as in, why do we need another one of these, because.

D

We always do its trail, but we never do one. One thing that came up that I noticed when implementing this system is that if you have a generic interface and you're trying to implement the generic interface on for, like you know in it and create on some struts that configures a plug-in, then you have, you might have conflicting method names like you, can't, obviously override a method with the same signature or even without the same signature just the same name ago.

D

So if you yeah, if you don't have like create in it, plug in and create create API plugin, for example, then, and instead you have two versions of creative plugin, then that won't work for a generic interface. But it will, if you have different method names for like Joe, suggested hard coded interface names. Does that make any sense? Yeah.

A

That makes sense, I thought about that. A little bit, I think I think that I, don't I'm, not sure.

A

That's too terrible, because it just encourages you to split out things into like two separate structs in some cases, which I think may be acceptable, like the I split out from the queue builder, X, I, split out the anit plug-in and the create or the anit plug-in, and they create plug-in into two separate like structs, that just got like delegated to from the main one, and it wasn't that like it was like it ended up being like run. If it's running, oh I, see what you're saying yeah.

A

Sorry operating on four hours of sleep takes a takes a bit for the progress bar to.

D

Load to sufficient yeah I, don't know if my explanation was very 16 others, so Joe wheezing, I.

B

I think I addressed this in one of the comments in the PR. Let me put it in the chat.

B

A

Can you give me like one or two minutes: I need to go grab my charger cuz, my laptop's about to die, and it's in the other room. Yeah go for it, okay, be back and like.

A

B

So for those who are here in the in the bottom of that comment, I just linked I ended up coming up with, like I think we probably need the same sort of thing. That Sully was just talking about where there's a separate implementation for each of the CLI sub-command. So this basically introduces like a separate layer of like an init plugin getter a create plugin dinner, and then you can define struck that implements the knit plug-in and create plug-in and those could be separates trucks.

D

Yeah I like this implementation, because we only have one generic sub command interface, that you can just embed in any way like plug-in interface, and then you can also add specific methods on top of that, so it gives it gives like a very similar, feel, like you said, to the generic sub command interface, while still allowing for type checking, which is really nice to have like you, don't have to ask to plug in anything.

D

It's just done through the type system. The.

A

Other thing that I wanted to ask about- actually this you've reminded me is: do we want to do? We want to have like stuff like description and examples, be methods that get called or do we want to like? We want to allow passing in like the default description, so I can I. This is like a hypothetical, which means it's probably not too important, but I can imagine plugins where you don't actually want to come up with a completely new description.

A

You just want to add an additional line or like you might not want to override the description, but you want to add additional examples, because you added new flags and so like being able to say, like here's, the current description I get to set this field or add to it or whatever might be useful, but I'm not sure, if that, how important that is, I mean.

D

Sorry well yeah, so what you just have like a description, ER and an exemplar interface, something like that. All right, I think I think basically.

A

You just have like the the like you'd have a like configured description method and it would get past the struck. That was like a pointer to a struct. That was like description examples and then, like the the configure description, would be responsible for changing that. If it wanted to set the description to something else or or modify it.

B

Okay, right, I, I think in the calling code would then just pull out after calling it via the plug. After calling that method with a plug in it would take whatever was there and make that the kobra description example yeah.

A

Exactly yeah, this is like not so important for base plugins, I, think but like for, for, if we, if such when, we eventually have like the filter plugins, it might be nice to be able to be like. Oh here's, just an additional example that just uses this new flag, I added, because it's not a replacement. It's just like I added an extra flag that turns on some new functionality, kind of thing, sure yeah.

D

I think that would be useful because you know a lot of pieces yeah. You don't really need to override the description. That's fine just having a generic one.

A

Okay, I think that was.

A

What I wanted to talk about? Oh I, don't know if this has changed since you're in the in the arocs version versus the queue builder X version, but I noticed in the queue builder X version. Individual plugins were entirely responsible for flags like there were no built-in Flags, I didn't know. If you that was intentional, like it seems, it seems to me, like some flags you, you probably want to be like every create API command, probably wants kind and and and resource and stuff like that, and so like those should be common flags. But I.

A

Don't I wanted to hear if that was.

B

So there is so that's actually a perfect use case like if we did create API with a home plug in one of the modes that right now we're supporting, is basically downloading the helm, shard and basically Auto discovering what the API version and kind is, and we have like a default like the the kind is basically the name of the chart.

B

The API version would be defaulted to something potentially just to make it like super easy for someone who has a heart to come in and create an API for it and convert it from a home chart into a operator.

B

Is that the only mode of the home one or is that we can that's true? So you can still also explicitly define like no to use this gbk instead, yeah, yes, I, guess what I'm saying is at the very least it seems like that would be an optional thing.

A

Yeah yeah, you would want to provide like the you would want to define the flags, but not mark any of them, as required. Basically yeah that also helps keeps keep the UX like similar between plugins. That's true that we don't accidentally end up with two flags that do the same thing by depending on which plug-in.

B

You're using yes, yes, I, think that makes sense, so the way that the interface works right now is you're, basically delegating to the plug-in, which gets to define its own struck to populate the flags from mm-hmm.

A

B

Guess the would we basically tell like document that plug-in should embed like a default flag, struct in their flag struct to be able to basically inherit the the base flags? Is that how you would do it or is there a better way than oh, nothing? You know I think.

A

I think there's like a few ways that I can think of on the range from like, like kind of simple to exceedingly idiotic ly, clever. It's like you know. Why did you do this, this works, but why did you do this sort of way?

A

So, like that's one, that's one method that you just suggested. Another method would be to pass in a context and basically allow like things to ask the context for previously declared configuration. So you could be, like you know, context.

A

Give me the all the context from the create API command and destructs out of the context and reflection to like dynamically just figure out how things mapped in your struct like you could you could specify additional things that would be from the base and it would reflect over to set them, which is clever but I, think overly overly clever and can.

D

A

D

Just add like flags to the flag set before passing it to bind flags uh yeah. You could also ask people to call buck up.

A

On the flag, names yeah that.

B

Is another way, that's kind of hidden? That's they could be nicer if they were more apparent exactly.

A

uh And it's it's like weirdly, like untyped safe. You have to know what type the flag is in order to cast the value and like I like.

B

The context idea that seems like that also then supports the like extension of having like multiple plugins pipe together, because the context might expand as plugins are running. Maybe one plug-in could add something to the context to inform the next plug-in of something that it did or something like that. I.

A

Was always playing around with this? Actually in my local fork last night and it was, it was going it it seemed decently, it seems to work decently. Well, it's it's kind of the pattern for context right. You have some series of things before you in the Chane that add data to the chain, but you don't like necessarily know exactly what so you pull it out of looks.

B

Like an HTTP, middleware, yeah.

A

D

Yeah I like that idea: okay,.

A

We can look at plumbing that do you want to do. You want me to set up a feature branch for us to collaborate on in the main queue builder, repo, yeah, and then people can just open PRS against that, and we can debate the code and we can merge it and then, when we're ready, we can Aires the feature branch yeah.

D

And I think that would be good to do in parallel with the proposal. Just because it'll give people an idea, a better sense of challenges during implementation and things that we need to work out. But obviously we wouldn't merge it until we're finished with the proposal.

B

Cool yeah that'd be helpful for sure that way, we're not passing around links to our own repos and branches yeah.

D

Never fun so just quickly go back to Joe's suggestion he he just posted it in the chat. When you were gone Sally. Did you get a chance to take a look at that with his generic sub-command suggestion everything sorry, you say that again in the chat there's a link to Joe's comment that suggests using a hybrid generic, non-generic plug-in system or inter interface system. Oh yeah,.

A

Was that the one where, with the extra embedded thing I, think because it was like 11:00 p.m. but I was having a hard time following the exact details of what he was suggesting but I think I get the general gist? Yes,.

B

This was so the idea that I had I think there was some discussion about, like basically the discussion we were just having we're like we're, basically implementing the exact same interface for three different plugins and the way that the current proposal says is it's basically like you're winning like 12 different methods with different method names, even though, basically or duplicating those same methods for each plug-in type like for in it versus create API versus to create webhook.

B

So, based on some of the discussion, there seemed like okay, like that makes total sense, really there's just one interface that we're talking about, which is this generic sub-command interface, but we still want to have like potentially different implementations for an it, create a PA and create whatnot. Yes,.

A

I see, what's going, seems extra.

B

Layer in between you can get the implementation and it's still basically all implementing the same interface, I.

A

I see what's going on here, yeah that that makes more sense now. Alright,.

B

And then I think slowly that kind of aligns with how you were splitting out the instruct from the create struct yeah, which makes sense to me.

A

I pasted a links you, the new branch in the thread, so we can, you can open, feel free to open PRS against that and we can just merge those semi aggressively if we want sounds good. Thank you. I, like the name may God have some fun with your names. Very true. All right was anybody taking notes. No.

D

A

Okay, well, we have a recording yeah and if anybody that has gotten more than four hours of sleep would like to remembers like what we said in more detail and wants to jot that down, that would be most appreciated.

A

Otherwise, I will maybe go over the recording a little bit later and try to jot stuff down or at least jot stuff down from memory, or we can add stuff into the PR. I will do.

D

That all in this and then I will be updating DPR based on what we talked about so I guess yeah going forward from this. It would be nice to like get some affirmative or non affirmative answers on how we want the interfaces to look like just because that's like the main that that's the meat of this proposal.

D

So does that like I guess, we should take a little bit more time after this meeting to like really think about Joe suggestion and whether we want something generic, but also does that, like from a cursory glance, look good to you and to everybody else, who's been commenting on this PR. That's in this meeting, I think.

A

I might tweet one of the names slightly but other than that, like I, think I think it looks pretty good at a cursory glance. One of the things we can do is we can write it down in the proposal and we can start collaborating on the feature branch and then, like we can say this is tentatively accepted in the proposal and then like.

A

If we have to change it because it turns out that, like on the feature branch, everything is terrible or something which I don't expect it well, but you never know like every once in a while you're like darn, this just completely doesn't work, then we can always.

D

Go back and change it. Okay, great so I will update the proposal and then update mm-hmm. What I have in my future branch then make a PR to the branch that you just made cool awesome.

A

And yeah I will I will try to remember to post the the CLI stuff so that we can make use of that for some of our tricks.

A

All right does anyone have anything else they would like to discuss.

A

All right that sounds like a no, so I will see. Y'all animals sounds good thanks a lot baby. Your boots up.

D