Kubernetes KubeBuilder Controller Runtime and Controller Tools, 27 Jul 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubebuilder community meeting July 27 2023

Description

Kubebuilder community meeting July 27 2023

A

Let me start by sharing the screen just a minute.

A

Can you all see my screen.

B

That looks good to me.

A

Yeah, uh so just going over any new faces, anyone would like to introduce themselves.

A

Okay, I think we all know each other. So moving on to the next topic on the agenda, uh we have a bunch of topics for Community interests, so the first topic is by Camila. uh It's about our plans to deprecate a few of the plugins and few of the important um helpers which we have been using. So one of that would be go V2 plugin. uh We have to also figure out whether customize V5 as any breaking changes, uh because we are moving the customizes moving to a stable release.

A

So that's one thing remaining and I think Eileen. You have been working on externalizing, declarative plugin. If I'm not wrong,.

C

Yes, so I also rest a question in today's weekly, uh so um if possible, we can discuss it a bit yeah.

A

C

A

Yeah, uh do you mind if I assign this to you just so that we have.

C

Yeah, like I I, guess, there's already a draft PR regarding with this issue. So I guess it's another guy who has a son himself.

C

So, like my um my discussion, my topic for today is more like a religious question because, like I tried to track some Upstream issues and try to know more about the um context, and it seems that computer is trying to move the declarative plugin from internal to external and it seems like during this process we met some challenges as the like now, the declarative, plugin is, would be work like a external plugin, but it seems uh if it's working the chaining mode, then it would be somehow hard to get the conflict during this process.

C

So, like Camilla, raised this issue and to say that if it's possible to make the external plugin and get the config either from the project file or from the process earlier to make sure that the um declarative plugin can work. So that's based on my understanding, I'm, not quite sure.

C

If it's the case and my question here, is that I'm a little bit curious about this design test because from my understanding, like the declarative, plugins Now work like a external one and I'm wondering if it's a good practice to like directly pass the config to the external plugin, because now it's more like a like black box to computer and I'm, not quite sure like if it's something we want or if I'm missing some contacts.

A

Okay, um I: it's been long since I've looked at the declarator plugin approach, but uh do you have any links to the config struct which we are passing in uh which we are looking to externalize I just want to make sure that as a plug-in owner, I would not like to expose uh more information than what queue builder needs for scaffolding.

A

So I think that too is the initial reason behind making things as internal as possible and uh passing it uh and letting only the binary be passed or the path be passed through the external plug-in, while scaffolding, instead of the config entirely uh so I'm, not against passing the config. But it would be nice to just look at and understand of this uh anything sensitive from a plug-in author's perspective which we are passing in, which we are exposing.

C

Yeah so like I'm thinking, is it like a responsibility of computer, or is it more like the for the external plugin to like uh get twice together, config uh so like? Who would share this responsibility because I I'm not quite sure if we like for computer directly past the topic, if there would be any like security issues or something like that, yeah.

A

Yeah I'm getting scaffolding.

C

A

Now I see the issue when the initial command is running, the project file doesn't exist, a red pointing so extracting the layout won't be an option.

A

Okay, so if I'm understanding right the problem, is we don't know what plugins internally are being used uh by cubicle declarator pattern when providing it to cube Builder right.

A

Yeah, okay, uh I, don't mind exposing the config, but I would have to probably look into the code a little bit more. My understanding is but this kind of brings another problem. So, as a plug-in author, would you change the plugins or do you expect Q Builder to change the plugins? So, for example, AQ Builder declarator pattern is using go V4 and probably something else.

A

uh It should be Cube Builders responsibility to scaffold out, go V4 or any go plugin along with whatever the plugin author provides and not the plugin author's responsibility to bundle multiple plugins. It doesn't make sense.

C

Yes, I guess so um so, like from the design I'm wondering is like from the like. For the external plugging side, we can use some slack to for Turing.

C

um Add some another like blocking the plugin request to have this config So, like um actually I'm, I, I, guess I may miss some contacts and, like I, may try to read through these issues and try to understand it better yeah.

A

Yeah sure uh Tony, you had your hand released, go ahead. Yeah.

B

Yeah thanks Marsha, um so I'm, not quite familiar with external plugging or the declarative plugin, um but my concerns here is like uh for a decorative plugin. If it has some issues go with like whether they want to get the layout from Kobe, 4 or something else uh I mean. Is it necessary for us to directly say we changed external plugin, and so we have a newer release of how we work with external plugin. Then we go back to the decorator plugin.

B

You see how we can go with that, because I think if we want to talk about like if we want to talk about a change to how we communicate with the crew Builder to the executable for an external plugin, I think that'd be something different or something separate from focusing on the declarative, plugin.

B

So that's kind of my concerns, so I was thinking that there might be some cases when. So. If we talking about the external plugin, there might be some scenarios that it might be uh possible that external plugin will do some additional scaffolding on top of the behavior from the existing internal plugin. But there might be also some other scenarios say: I, don't necessarily want to know about the project. Config things I am an external plugin.

B

Then I should be able to scaffold any kinds of buyer as I want, and in that case I don't expect the computer to send the project config to me, because that's something I don't want uh so to that concert. It's like uh I'm, not sure like how we want to go with the external plugin to communicate with Google to go with that. So I think that's kind of things we need to discuss later on when we go with that part, but for this declarative, plugin, I guess so, I guess.

B

The problem here is: if we first run cook Builder and nitgo before we will have the project config and then, if we, if is that possible, if we run another command and Trigger that flow rate of plugin, and so in that way that decorative plug-in execution can load the project via right, and in that case maybe this crap. This issue might be possible to get resolved I'm, not quite sure. So that's some of my cancer yeah I'll be back to you Russia. Thank you.

A

um So, for the second one um uh Ellie, you can correct me if I'm wrong. The issue is, for example, the declarative, plugin is using, go V4 and something else uh say, probably um a custom plugin now the cube builder needs to know uh what is being used while scaffolding out the initial uh project file and the docker file during init, and at that time, Cube Builder doesn't know what uh your external plugin is using consecutively. Is it using go V4?

A

Is it using go V3 or is it using a custom, plugin version, one version two and things like that. So.

A

Which is why the external plugin needs to communicate what configuration does it have on its own? So I agree on the part that this is a change which we need to fix in Cube, Builder uh and thinking about that I'm thinking. If we could make a post render kind of function like postcard, folder kind of method where we could go and edit the docker file and the project file after the external plugin is loaded into. uh Does that make sense, yeah.

C

Yeah I can understand it. Yeah.

B

That makes sense thank.

A

You in the sense, during the init command, we don't uh populate the project and Docker file as expected, but after the init command, once we load the external plugin, then we make a change to the project file.

A

Yeah, I I'm, not sure if um this would be accepted entirely uh by uh the other folks. So what I can do is I can comment on this and is it blocking your current PR? uh Not.

C

Really like it's uh more like a bonus of my projects, so because I think I may have some extra time, so I just want to take a look on the CC I want to have. This have some discussion to see if I can help with this um yeah.

A

Sure that's really helpful for us. um I can add a comment here and then we can probably initiate a slack channel uh a slack conversation with the channel and see what other folks also think about it, so that we can fix this issue because it will be useful for other plugin authors too wow yeah yeah sounds good to me. Is that fine Tony.

B

Yeah, that sounds good yeah. Thank.

A

You and then, as you said, we can look into the workarounds also in case we don't need it to be fixed and we can go around with a another approach. As Tony mentioned, we can probably take that up instead of making some Breaking Chains and Cube Builder.

A

That's good um thanks, um Ellie for taking up this issue and helping us understand really uh appreciated.

A

So yeah I think we have um moving on to Camila's issue. We have a bunch of uh issues to pick up which me need to be uh discussed in terms of deprecation and removal.

A

One of it is being handled, the other one is verifying customize, V5 I think we have someone already working on this.

A

uh I can discuss this with Camila and we can again start a slack on bring this up in the next meeting to see uh how we can go ahead with this side of this. Any action needed, because we have both of the important ones being assigned and added.

A

Moving to the next one Tony or do you want to.

B

Yeah yeah sure thank you. uh So this is actually like a very small concern, so I was making I was meeting an issue for one or two times when I was trying to go over in some PRS and issues these days. So the issue is uh when I was trying to validate some updates on the code. I would probably run the make generates.

B

That would include the execution the Target make generates, Docs and so problem here is uh the generic stocks is using the computer in the default environment so which means that, as possibly will run the code Builder that was previously installed in the environment, not as the one that is compiled from the current source code. So I know that's like in our targets the make generates test case test data.

B

It will have like a build KB functions in the shell script, to try to compile and have an a build, an executable Builder from the current source code and try to run the code Builder based on that to see if the behavior as as expected. But when we go with generate stocks, it possibly won't, and so that leads to an issue is if we have some updates on the plugins Behavior, and we run this and we rent this um targets.

B

It won't have the updates on the code in the documentations and then it will lead some errors happens because in our CI pipeline we have the make check, docs targets executed, to see if our documentation is sync with the updates from our code.

B

So I was wondering that if ever we need to change the code in the generate stocks Target to try to compile and build a computer as how we did in the make generate test data or if we just simply want to run like uh make install as like a prerequisite before we run the make generate stocks to Value, to verif, to make sure that we have the good Builder get ready from the current source code. So that's kind of my concerns for this part.

A

Yeah I I agree on the issue which you said that the docs is not running the updated Cube, Builder version and I'm kind of leaning towards um like building the queue, Builder binary and then executing make generate talks instead of running make and stall and make generate does make install also apply something on the class. Does it depend on the cluster at all.

B

Yeah I guess the making store would like create the executable it'll, also copy it to the user's uh bing fire, and so that way, when they run the code Builder, they can use that one by default.

A

Oh okay and the test data generate test data uses.

B

Yeah, that's that's kind of the Point as like it would just literally could build, or as it assumes that the environment will provide one.

C

A

I thought we were building the binary from the stores somewhere, while generating the test data at least right. Well, scaffolding out.

B

A

Oh, that doesn't matter because we are calling the binary directly.

C

I'm not sure which one did that.

A

C

A

um I agree that this is an issue um probably would have to look into the source code to see if calling the make install makes sense or how the testing is generating. But I agree that this is an issue Tony yeah.

B

Yeah, okay, maybe we can later on have like a uh I, don't know. Maybe I can just try to create a pure to see how we can fix that and makes this discussion over there, because I'm also not quite certain like which implementation can be better to help resolve that.

A

You want me to assign this to you.

B

Yeah yeah that'd be good yeah.

A

um Does this make sense.

B

Yeah yeah, that's pretty good! Thank you. Marsha.

C

A

Do you want me to assign this to you yeah sure sure.

A

Thanks Tony, thank you. I'll also try taking a look on this. If we can figure something out, yeah.

C

B

Guess this one is like I: don't have many like quite like deep dive deep into like the scenarios from the authors that how they want you go over with that, but I I raised here is only because I know that it has been for a while and I missed some of the meetings previously so I just curious like.

B

Where are we right now and is there some plannings in Futures and how we want to go over? That part.

A

um I remember seeing a PR for this. Was it closed.

B

Yeah I guess previously. Somebody has helped with to maybe in a different PR to. uh Let me try to figure out.

A

Looks like there's a beer open to fix this, but the author had closed this. For some reason.

C

Okay, we have a piano.

A

Do we have to look into I, don't remember uh what the pr entailed so do we want to look into this again and then uh check if we can fix this or is there a particular decision we need to make in moving forward to this PR.

B

It's actually something I was wondering also because I to from my understanding to Camilla's comments on this PR, it seems like she will like to move this PR forward. That is, to apply the plural system as what it is in the kubernetes uh and then after that, if there's some follow-up say how is there? Some issues really happens for backward compatibility or if some like other repositories from different uh inside the community, but might possibly have some uh dependencies on our project, uh then we may think how we fix that.

B

So, basically, maybe I guess you may be looking forward to move this on uh I I mean I. Personally is good about that. My only comments on this is: how can we make it Backward Compatible if there are some issue spaces, but I'm totally good? If we just want to update the plural system, to make it consistent as what it is in kubernetes I'm? Definitely fine with that.

A

Yeah I think uh it would be helpful if we follow the Upstream approach, which is being followed in kubernetes and I. Think as Camila said, if there's something breaking in the apis which we are generating, which we are using, uh we can publish a go V5 plug-in uh and merge that if there's any breaking change but I think this plural generation is more related to uh the value which the user provides in the sense user does queue builder in it and then provides a custom resource string which is then converted into plural.

A

So I don't expect there would be a breaking change in the plugin itself, but yeah. If there is any, we can probably revisit this in the next release and fix it.

B

Yeah sounds good to me: yeah.

A

It's okay, yeah I've, mentioned the author to rebase it with a master so that we can again revisit and review this and see where we are yeah.

B

A

Thanks Tony for taking a look at this, uh the next issue is by uh Ellen I, think we had covered this. uh The next issue is land checking.

B

uh I can't just try to bring some like contacts with this uh so like previously Camilla has raised the idea is ever we can introduce the links tracking into our code so, for example, to use the Golan CI linked to check our scaffolding so and I guess.

B

This PR has tried to do some Explorations and practices over that and it seems like it is challenging because it can be appliable to our computer source code, but when it comes to the test data for those projects, especially for those scaffolding layouts, it might be hard because there's so many, but not so many, but there's like a number of undefined variables in the scaffolding layout as well as there's others, also some other like link checking error. That is because the code scaffolded out is not complete, because that's that's what it is.

B

It's like a template right, so I think the follow-up idea from Camilla is. She was thinking wherever we want to provide something like a plugin like a sub commands for the users, so when they use the crew Builders to scaffold the project and they have completes their developing, they can use the plugin. The proposed Plugin or sub commands to run the LinkedIn check for the uh for their project, I'm, not sure I'm, understanding correctly or not, but that's possibly something uh what we. What I understand from from the issue, from the pro request.

A

uh Can't we just fold out the golang CI lint helper in the make file in the plugin itself for the user so like uh or you know,.

A

So it in the helm operator in this repository, we in the make file, have.

A

A lint Checker already scaffolded here as a helper, so.

B

Oh I see I, see.

A

So we can just scaffold this uh in the make file of the project right through the plugin itself.

B

A

B

Think that's that's possibly like a simple Manner and and be more easy, understandable for users to go with this.

A

Yeah, instead of a sub command, you can just run me Clinton. That would fix it.

B

A

B

A

This fetch item is it in tools yeah the FED script, which basically fetches the latest version of Google? Oh.

B

A

I think we can introduce this as a command itself.

B

Yeah, this sounds a good idea to me.

A

Instead of using a separate thing, um I can add the command here.

A

I will just add it as a suggestion and then probably we can again follow up in the prf. We are fine with the suggestion of adding it as a make file helper, or do we want to separate command yeah.

B

That sounds good. Thank you. Russia.

C

C

A

I've just added this as a comment. I'll also add these issues in the next meetings agenda so that we can follow up if there is any activity which happened in the PRN issue and how we would like to proceed with it. Yeah.

B

A

Yeah um is there any other topic which we would like to discuss.

C

No more from my spine.

B

Or from myself.

C

A

Thank you so much um everyone for joining the meeting. I really appreciate it, and thanks very.

B

Appreciate Russia for leading this. Thank you so much.

C

Thank you, Russia. Thank you. Tony have a good day.

B

Yeah have a good day.