Kubernetes SIG Cluster Lifecycle, 9 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SIG Cluster Lifecycle - kubeadm office hours 2021-06-09

Description

https://docs.google.com/document/d/1ONcoy8bOw8SWPUwXxnKeRZST3lnUxYpUv4Y6466h9Ek/edit#

A

Hello, everybody- this is thecube adm office hours. Today is the night of june 2021.

A

It's only me for bridge on the call, but we decided to record this meeting, because we have a couple of discussion topics, but first I wanted to mention that we are pretty much on schedule for the 122 release.

A

It's we have a month to complete our remaining tasks as much as we can before code freeze, which is july 8th. That is also going to be the beta1 release of 122..

A

If you look at the schedule, let's see the docs dates as.

A

Well, okay, docs must be completely reviewed, that's almost the end of july, but the docs deadline for placeholders is july 9th. I have a couple of changes that I want to send, so I guess I'm going to try to send them before this deadline, which is one day after code.

A

Phrase, uh I don't see any blockers. uh We have a lot of time with this extended release cycle, so it's actually good for us.

A

That's all. I had for this 122 updates.

B

Yeah, thank you and, and uh also I think that this cycle we we are really uh we. We did a great, a great job so far and uh most of what we are scheduling, we have schedule that is already there and yeah. Thank you for that.

A

Okay, we can move to your topics.

B

Yeah, the the next topic is kind of related to these. So in cluster api we just yesterday we cut we want alpha for beta0 and in in cluster api. We have a mirror copy of the v1 beta3 types.

B

Before cutting the release, we we aligned the types and what I'm asking now is is as far as you know, we have additional plain additional chain changes that we want to merge before the end of the cycle.

A

I can see a couple of changes happening before we release v1 beta3, okay. I really want to do this, which is uh extract booster token, to not be inside v1 beta3. Given we have so much time, it's a backward item, but uh no it's not, but it's actually important long term.

A

uh We can do it.

B

A

uh That's actually.

B

A

A bit complicated for copy because you have to create, uh like a new group for the bootstrap token.

B

um I'm not sure, let's see, let's see how this ship out, because uh basically, what is really important for copy is this realization format of kubernetes?

B

So so I assume that this is more of a shuffle of the code, but is not going to impact the serialization format.

A

You can keep the bootstrap token in your forked v1 beta3 to remain inside the cube adm yeah.

B

But yeah, let's see uh okay, this is one, let's see how they change the shape out, but I yeah I don't expect piggy, but in copy good to know and then.

A

uh I wanted to mention something about the cluster api fork types, so imagine that soon we have the cube adm types in a repository that is makes them consumable.

A

From my understanding, the mechanism you decided on cluster api means that you still have to fork no.

B

Basically, in so in cluster api, we have two things, so one is the kuberne config types. These types now are different from the kubernetes api. They.

A

B

Are derived from the same object, but now they are different and they make you an example. For instance, in an in cluster api we are not using automatic copy of certificates, and so we don't have the certificate key things and stuff like that. So basically, cluster api types will become a subset of kubernetes that basically allows user to make only the configuration that makes sense for copy.

B

Okay, this type are copy specific. They have a kind of mapping with kubernetes, but they are different and long term. They will become more and more different, because we we want to make sure that the copy user won't be able to do invalid configuration.

B

We want to have a book, validation and and yeah, and we want also to make stable across several cuban mean versions. So this this thing is different and, and now and and.

B

And as its reason to exist, then what we have basically what we do when when we create the node, we keep this type, the kubernete config type and we serialize it into a cuban mean object. Okay, now, for doing this sterilization, we have a fork of of the v1 beta, 3 type of d1 beta2 and v1 beta1.

B

As soon as we can vendor kubern mean this fork will go away.

B

Does this make sense to you? Yes, okay, we got this issue open by you some time ago.

B

We you can consume it and you you can close it because, basically, we it was about omitted and home it mp optional, and it was- uh and we worked on this okay.

B

So I I don't remember so that let me say the goal of the issue is fix that I don't remember all the discussion down there.

A

Well, the discussion is that also no conversion, uh but now you have conversion, because you have um okay, so.

B

So we can close because part of the problem was stored when a kubernetes part was solved in custom, api.

A

Okay, let me close this one, while I'm.

A

A

A

How do I phrase this.

A

By forking them.

A

But eventually.

A

B

As soon as possible, yeah definitely.

B

A

This is for this.

A

But there's still possibility for drift and to buy the setting. You want the drift to be intentional to get users.

A

B

The drift is intentional, because really some some combat mean configuration uh can basically screw up the cluster. I make another example: if the kuben mean if the cluster api user configure a bootstrap token likely the cluster won't, the nodes in classic api won't join, and so we want to either tokens and stuff like that. So yeah.

A

But it's a food gun, you give them the power, but if they do it is their responsibility like this. uh If you have this documented the list of types, uh the list of fields that should not be modified.

B

Yeah now now it is documented and it is documented button, but not enforced, and and it happened that people just do crazy things without reading dogs. So.

B

Okay, so we want to basically to make it a little bit more robust and yeah the the this cycle we made this possible and in the future iteration we will improve the the usability around the simplicity and stuff like that. So.

A

In theory, wrapping a certain api with your version of a managed api like subset of it or a superset.

A

In theory, the drift can be very problematic if the api is big, but the kubernetes api is not big. So as long as you have the main maintainer bandwidth to do this, I think it's okay.

B

Yeah and yeah I agree: wrapping an api is never ideal, but also embedding an api as a its problem, and now it is not possible for kubernetes. So we believe that this this is that now we are in a better situation than before, because if you remember before, we were only supporting the one beta one, which now could be problematics and stuff like that. So.

A

Okay, uh I'm going to work on this. I don't know when, but there is enough time hopefully for it, uh I'm not sure about this. It had some problems. uh I don't think we should discuss it in this call no yeah. I need to get back to it. It's not yet decided uh patches. I realized that if I had patches to v1 beta 3 as a purchase directory, uh we we didn't uh have this in the cap for the patches.

A

The buses have a separate cap and we didn't announce to the release team that we are going to update it.

A

But to my knowledge, the the kept process nowadays is opt in. So I think we can technically update the cap without to beta, for example, without announcing it to the release team. I don't think I don't understand if this is correct or appropriate,.

A

But it feels appropriate to graduate the feature to better if we move it to config and we deprecate the experimental, the experimental patches flag.

B

I think that yeah- let's discuss these uh case by case, but I don't see big problem because patches and they wrote map were announced a long time ago. We announced that that we are changing the cap so that we are changing the config, so they are just consequences.

B

Next step of this works so and and yeah, of course, the the.

B

We are also adapting to the new release cycle, so, in my opinion, it makes sense to to add something that was not planned in in the.

A

Okay, so alpha better graduation, I haven't seen any bugs in the co from users about the code.

A

I haven't seen this any complaints. It has been tested.

B

A

We removed the experimental customize we can do this. I think this is. uh We should talk about this as well. The feature is not documented, but I can document it. This will potentially.

A

Maybe people are going to ask like why are you doing this, but I can explain we're graduating it's as part of another cap which is kind of strange uh and it's it can be added to to the conflict.

A

So it feels uh the time. Is this cycle.

B

Okay, make sense for me uh and yeah it. It is a nice option and.

A

Now you remember a couple of weeks ago, we discussed the the fact that we don't have configuration structures for uh upgrades.

B

A

So if we, if we say that experimental purchase is deprecated and only available in config without this patches new flag, this means that we still have to keep the patches flagged for upgrade because we don't have a config there.

A

So it's going to be kind of strange init and join, don't have the patches flag, but upgrade has must must have it so. Instead, I think we should just have the flag everywhere and think about the future, eventually uh removing it in the future, when we have maybe config for everything.

B

Yeah- let's, let's think about this uh it it seems that the only let me say, uh blocker or the the only missing point to the entire story, but everything else seems uh legit, and so, let's figure out how to make this work across upgrades and um yeah. We have to think about this.

A

I I just want to, I probably, are going to add the patches flag and other nodes that you know. Eventually, we might remove this flag uh in favor of config, but the flag is going to overwrite the value in config. For now,.

B

A

Okay, I can work on that as well.

A

Pause image, configurable dropped extracts. This is something that also I can work on or maybe ask someone to work on that. You know we have extra arcs, it's a backward item. We have extra arcs, they don't allow duplicate values, for instance, some api server flags. You can pass multiple times and all of them are usable.

A

I think it was something about authentication. I don't remember examples: okay, okay, so yeah uh you can pass multiple.

A

Keys, I don't know what this flag is doing. Yes and I okay, uh okay, yes and I, but you cannot do that in cuba, uh which means, if you look at the api, it's it's currently. The extra rx is a map of a string to string yes.

A

Now we have to change this to be something else, which means that I mean we can do the conversion, but users of cube adm that are consuming the goal. The ghost products.

A

I want, I think, it's fine to make this change since in v1 beta3, it's not fine to make it in uh within um once the version is released. We have to make it before it's released. I think yeah.

B

To be honest, I would like to see alternative solution.

A

Well, the alternative is to use patches basically.

A

You have extra arcs and you, you cannot pass them here. You should not use extracts and you should use patches and use one of the json patch formats. That just depends uh array entries at the end of the.

B

Array yeah, but are you planning to change the kubernetes api? uh You don't.

A

If you use patches no.

B

A

This is that's already a workaround for this.

B

Problem yeah, I I don't have strong idea here so maybe I will take a look again and at the issue and comment there.

A

Oh, it's a low priority. One.

B

Yeah, let's get the bootstrap token figure out for first and uh and kubernetes and and patches. I see.

A

This is a vmware, employee, yeah george. He I remember that he asked me like why. Why are we not supporting this.

A

Do you have a problem with the api change in v1 beta 3.

B

No, I I don't have problem. I.

B

I only don't remember the contest for this issue and I would like to to have time to read it.

A

Okay, uh do you want to give you the number? No, I I took note all right extra duplicates. uh I think that somebody already assigned themselves to this. I think it's paco from not mistaken, yeah. Okay.

A

This is a nice to have, I think it unblocks kind and some other users that don't want to use the hardcore policy incubation.

A

We can add something like image policy pool, never like, which means that you never prepo the images which is uh a nice ux.

B

Yeah, uh but do you want to add these in image meta or do you want so and make this configurable component by component, or do you want to add these at top 11.

A

It should be, if we add this to the config, it should be part of top level in it top level join, and we have to have a flag for upgrade.

B

Yeah: okay: let's figure out, let's comment on the issue and I'll get in the solution.

A

I'm not sure I have. I think I already commented okay, so we already, we already discussed this.

B

Yeah, I remember discussing.

A

We spoke about the note registration options.

B

Instead yeah now there is an option, because uh otherwise this is this is global.

B

This probably makes sense, so you can decide on node basis.

B

A

B

The problem is for upgrades again.

A

Yeah upgrade flags, everything is flags there uh and hcdsa. Now this is a very complicated topic, because tremendously, the united states, and basically when you release a product in the united states or something like that you have to uh ncdsa, is not something that you can use.

A

I had a discussion with uh fabio rapuzzeli and tim centcare about it a couple of years ago.

A

Basically, I don't think we can use this at least in vmware products. I don't know if users can do it, but they probably can because nobody's going to monitor what they do. uh I think there were some problems around this. So currently it's a feature gate, which means that we wanted to enable it by default in cuba, dm always and the feature gate is alpha.

A

So we are kind of blocked until further discussion, or maybe we should just make it an option. Opt-In instead of a feature gate, because the feature gate is feature gates are ephemeral and eventually you have to enable this by default.

B

Okay, so I'm not an expert here, so I I cannot say if this is something that is required is mandatory. If there are laws behind these, so I would like to get someone uh making us to understand the priority of this, also because it is not that we have so much request on this feature, so I I'm minus one for working on this and this uh ingredient with the tree.

A

Okay, let me have a quick comment.

A

A

B

Very vague, but I.

A

Be like I cannot phrase this better.

B

Yeah we are at least I'm not a security expert, so this is the best the best I can do.

A

The argument around hcdsa was that it has better protection around.

A

Modern attacks that have basically powerful machines that are used for them. So if you use a quantum computer, I don't think hca can help you, but now nowadays, there's so much computing power that basically the existing algorithms that we have is are not that great and lcdsa is better actually, but.

A

I'm going to drop it for now and we can always do it in the 1v24, eventually yeah for sure.

B

And maybe we can even ask for help from someone from security or stuff like that and to understand the relevance.

A

A

Okay, this is so I have uh against. Everything is the best effort, I'm probably going to do patches, because I've seen requests uh something about the story going back to the patches. uh Let me open this and use this as a text editor quickly.

A

My idea of the api was, uh if you have a patches structure like so, my idea was not to have a patches directory.

A

Instead, my idea was to have patches and.

A

Something like that because uh if, if we see too many requests about embedding patches, which, if we discuss that it's not a good idea in general, but it allows us to be backwards, compatible.

B

This makes sense to me: okay,.

A

So this is all about the api. Do you have any other topics about it.

B

No, I think that we already did a lot of great improvements and I'm happy because at the end of the the v1 beta 3, api is sorting out as a feature reach.

A

Version: okay, uh the next topic: you have no, no specific configuration yeah.

B

This is a a so previous discussion, uh so uh there was last week a meeting received node where, uh as you know, there was the aditi from vmware raised the the point about the starter and the future of kubernetes configuration, and so it seems that there is a general agreement, including in the insignia, to go away to go to move forward and and basically start deprecating and removing flex.

B

Okay, there is no con, create a roadmap now uh but yeah. This seemed the direction so flaggers are going to to go away and cooperate, configure. We will be the the only way to configure kubernetes, so this makes uh basically this is. This is going to force kubernetes and all the installer to start drifting away from kubernetes flag.

B

At least this is my take, and so I started to think about how we can do this, especially because, as as of today, we are using flags as a solution for allowing the user to do node specific configuration, so that's mean that we have to, and um just to make this a little bit more clear when we we do cover the mean in it. The user is allowed to specify a kubernetes configuration.

B

Kubernetes configuration will be used for all the nodes, but when doing kubernetes, the user can use node registration option, kubernetes extra args to override what is written in in the kubernetes configuration okay. So we are using this two layer, 12 law, node specific configuration, given that the second layer is is going away in the future, doesn't mean that we have to provide our user a nice way to do node specific configuration without using flex.

B

Okay, do you agree with my problem description.

A

Yes, subject that in the sig node meeting, I'm not sure I I gathered the same response as you did, because probiotic was the only thing they agreed on. Was they don't want to add more flax but the removal of flax? I didn't hear a concrete explanation or a concrete agreement on saying: hey. Yes, we are going to remove all the deprecated flags.

A

I didn't hear any of that.

B

Yeah, it was really not clear. There was themes that that discussed about removing flags in bulks, and there was a discussion, of course, that signaled was telling that they have a lot of things on their on their plate already, and this is not a priority and, and so the the the.

B

The roadmap is so the timeline is not defined yet, but what happen if they are the only uh configuration flags and then they don't add any more flags. So they are, they add a new option. Only in the kubernetes in the kubernetes configuration, but not in the flex doesn't mean that that kubernetes user won't be you capable to use this these new flags unless they they have to set the same value for the entire cluster.

A

Yes, I understand this problem. In fact, I think there are already fields in the configuration that are not present as flags, and they are also already flags that are not don't exist in the conflict yeah. I think both during the discussion.

B

uh Someone stated that they are aligned, but I I agree with you that there are some differences and uh yeah so tldr is that flags are, let me say uh when we continue to work on the two lion flags. We are kind of working on x, and so I would like to start to think an alternative.

A

B

Flux rely of flags if there is okay and so we we should start to start something an alternative uh and work on it. So basically I start in a document. I will share the document uh with you. We will- and I will add also to the meeting meeting meetings now it is still a brainstorming. So it's not shareable it's not in a good suite but yeah.

B

Basically, what what I'm thinking is that, of course, first of all, I identify this type of change like the 20 percent, so 80 percent people of people want to use a node specific configuration, and so we should keep basically the the user experience simple and nice for the other folks, I don't want change for the other forks so, and we should figure out how to make this possible, how to make it possible for user, basically to specify a an additional kubernetes configuration.

B

Let's make. Let's make an example and try to make this clear, so I have to create a cluster and I have a bunch of node that uses gpus, okay, and so I need a special kubernetes configuration for these nodes, and my idea is that: okay, let's give the user the possibility to add to the cluster, so they took about meaning in it as as of today, and then we we give the user the possibility to add a second and mean kubernetes configuration and also to specify a node selector.

B

So they they say this is the kubert configuration that should be used for all the nodes that have labeled gpu.

B

Okay, after after this uh new kubernetes with this node specific configuration is in the cluster. What what happened when we do join is that join basically will search. If there is another specific configuration for the joining node, it will use it.

B

Otherwise it will fall back in in the standard.

A

Behavior, does this make sense? Yes, do you want to be to comment sure.

A

One problem with that is, I think, with node selectors, with the node selected approaches you have to.

A

You have to label the nodes that you have to have a matching label with the node selector, which I think is fine. It's a like a contract is binding, which is tolerable.

A

And we can do that from init, but sometimes when you create a question, you don't know what additional requirements you have in the future for the the corporate uh instance specific configuration, so you might might not be able to create the node selector in advance because you don't know what the cluster will become.

B

Yeah, but you know the the water the next node will join. uh Yes,.

A

But it's you, don't you don't know uh you, you might have joining notes, but you don't know like how do you modify this setup so that imagine that I didn't create a node selector from the start and eventually I want to modify this cluster to have multiple couplet configurations.

A

Yes, the node selector, uh and this happens in a very later stage and then I want to have this. uh How do I, how do I modify the.

B

Question whenever you know that you need a non-specific configuration, you add a kubelet with the node selector and then you join new nodes or or or when you upgrade the existing nodes. They will use the the the new the non-specific configuration.

A

Yeah, I I mean it's possible. Definitely no. I was thinking about something else. We can uh actually use patches for that as well, because if you have seen the instant specific cap discussion.

A

They they were back and forth between different options and eventually what they decided, which I don't exactly agree with, but they decided that if you have a quote-unquote global corporate configuration, the way to apply instance, specific changes is to use a patch version of of this. So you basically pass a patch. uh You have another another flag and you pass a patch which overrides the global with the settings that you want. Any patch is persisted on disk.

B

B

I have some concern with this approach.

B

So, first of all, it is a solution we we have to discuss and decide. So I I'm just expressing my opinion, so I don't see basically.

B

The global versus local thing to be.

B

To be something happening soon, so the cap is stuck and I don't see it moving forward.

B

I don't think that, as as a kubot mean, we should solve this problem, because this is a component config problem.

B

uh So it it is kind of sick architecture, so let me say each action that we take in that direction is is risky.

B

Instead, I think that it is a little bit more safer if we basically delegate the user the responsibility to decide what what is uh instance configuration what is global configuration uh and, and so on.

B

The the user basically is the one responsible and uh to define a configuration object. It should not take care of of merging or or strange logic which basically be also because this strange logic, I have some side effect.

B

First of all, you there is no way to understand the current configuration of a node unless you basically redo that the math of uh everything happened. Second, these patches are not.

B

Future proof, because it is hard to upgrade them, it is- are the there is no conversion mechanism stuff like that. So I I think that the simple the simplest thing is that okay, you want a different configuration. Give me the configuration, I don't implement any sort of merger. I don't implement nothing. I just use another configuration.

B

It is simpler, cleaner to explain and probably to maintain.

B

My my first take on on this, so I don't know I don't want to go to to the the the cap of a reason. Specific configuration is there from from one year and it is not moving. I don't want to to to have the same problems.

A

Yeah sure uh I just uh I'm not exactly suggesting that we should follow what the cap suggests. It's just that we already have the mechanism in cuba dm to patch uh files, and if you look at the v1 pod object, we don't have an upgrade story for that either, which is a static pot. If we have a v2 pot eventually, which is not so unlikely to happen, eventually, we don't really have a way to migrate user patches either, but we already have a contract with the users to use patches for control, plane.

B

Yeah, but in the counter it is, it is written that we are not upgrading them.

A

Yes, but we do support the purchase combat during the upgrade so.

B

But the user has to provide a valid purchase.

A

Yeah, the same could be for the uh a kubrick patch. There is v1 beta1 or if you want beta2 is backwards compatible. The patchway still is going to work no, depending on the patch and the the same way. We are preserving the instance specific configuration on disk the same way. We are preserving user patches on disk, so we already have the mechanism.

B

I agree, I only let me say, having worked in copy, I I will say that this mechanism is hard to is not you, you don't have visibility on the result or of what this mechanism is doing is not visible. It's not tracked in an api.

B

The result is not is not visible because it is on the on the local disk.

A

Yeah, but the the copy you also correctly do not allow the user to even specify the couplet configuration during init, which means that they already don't have visibility.

B

Yeah this is this is a point, but given that we wanted to give visibility and and control, we want to give them a declarative.

B

So, at the end we want to follow the declarative approach. We wanted them to declare the final state and not and not to declare uh basically a function. That applies on top of something else, but yeah we we can discuss. We can discuss approaches.

A

Yeah, I just uh what I don't like about. I mean I appreciate your idea with the note selector. I think this makes a lot of sense, but we already we already implemented a different method of having instance specific configuration, and I don't want us to have multiple ways to do it. So it seems like patches is the way to go. From my perspective.

B

I kind of not agree because pages are only for the api, for the static ports are not for the worker mode.

A

Well, at the end of the day, you are just patching a file that contains uh some sort of a group version kind of the corporate configuration or a view on pot are both something like that.

B

Yeah but again pages are by note and, and you are, they are not visible. uh I I can then so I agree. We have a mechanism which was an exception mechanism, because we are good. We are getting to the root of the problem. The root of the problem is that we invented patches, because kuberne has only a cluster configuration that that's that's the point.

B

So patching uh patches are a workaround because we don't have know the configuration, and so I I think that we should tackle the problem instead to add a workaround on top of workarounds, okay, but.

A

B

Let's, let's discuss I, I agree with you but yeah, so the taking us a slight step back. So the idea is that.

B

Even if we are going to think about that not specific configuration, my assumption is that the user will have will mostly most of the user will have a set of nodes with the same configuration.

B

So it does not really make sense and it is a bad user experience asking the user to copy the same configuration or the same patches across all the nodes. This is why I would like to to create this kuber configuration having a knob selector, and so basically, when you create a node, the the right configuration get joined to to your uh to your node, and if you are ten nodes, equal everything happens.

B

Let me say everything is simple: uh you have only the final configuration once and once and it gets reused many times but yeah we we can discuss I. uh What is important for me is that you, you agree that that in the problem statement- and then we can discuss on the solution- and uh I will I.

A

Agree agree. I agree, there is a problem, but if we didn't go with the patches approach, is this new mechanism going to also customization of control, plate components across different nodes, decoratively.

B

I don't think so, and- and this is this is something that that we can discuss, but I don't. I think, that we have three different problems which are technically really different and and also in terms of impact, because uh configuring, having no specific configuration for control, plane problem for control, plane object, is a really different problem that the kubernetes configuration, because.

A

Technically, why is that.

B

Because uh kuber configuration apply apply to all the nodes uh cluster configuration only to the control plane nodes, because technically one is implemented in static parts. The other is implemented using config map in the cluster. So there is a lot of technicalities in different and also another possible. Point of configuration is cuba proxy.

B

But again this is different because it is using.

B

A demon set- and this makes even more difficult to have no specific configuration for kubernetes for kuber proxy, but yeah.

A

I was asked today by user. Do you want to support patches for q proxy? I said no. I q cubert was not included in the in the question, but for me the problem is the same on the very very high level, which is instant, specific configuration. We currently do not support it for the couplet, but we support it via patches for control, plane, components, quasar api. If I don't think you have a such a use case, but if somebody wants to apply a custom bind address on a particular control plane instance.

A

Kcp does not support that today, because you don't have a mechanism to patch the bin address flag.

A

I guess there is no such use case because most users just prepare the vm to be appropriately configured to have the the first interface to be the one that you want, but yeah it's a very I just want. Don't want to implement more uh solutions that it might be the right thing to do, but I just want everything to use the same mechanism. Yeah.

B

What I arguing is that patches is not the right mechanism, but let's discuss this in the in the in the document because, as I explained it patching is a workaround to the lack of node configuration of node specific configuration.

B

Okay, I I will comment if you give the dock sure.

A

B

So, let's, let's try to get this moving. Ideally we we should get a cab in the next cycle.

A

Sure, just I want to get opinions of from everybody because of.

B

A

Yeah, I really don't like to maintain multiple solutions. It's just in the end of the day, uh some of the technical depth that we have in cuba. Dm is nowadays maintained as a best effort, and if you, if you say that patches are a workaround, uh I don't know what we're going to do with it. Are we going to remove patches? Eventually? I have many questions. I will add them to the document.

B

Yeah, the the the pro the problem here logon is this one is that.

B

Kubernetes is a priority and we discussed why other components are not a priority. Now they they, they don't have the same pressure and so.

A

uh What is a priority, but in the end of the day, cube adm users are not talking about cluster api uses, cube. Adm users can stop using flags to apply customization and they can just apply a mechanism which is not great, but they could overwrite the coblet configuration on disk and restart the couplet it will.

A

They have a custom couplet. Now, okay, I mean yeah, it's not going to be easy for coaster api, but if you have a cubed air operator.

B

For instance, that can it can do it for you. I tend to disagree. So this this mechanism is a is a an ack. I I don't think that this is a. This is a valid solution, so yeah we can, we can tell you, can use phases and do whatever you want, but it is not as a first-class solution supported by me.

A

Do you think that patches from your perspective nowadays is also not a first-class solution.

B

No, no, the point here is that patches, where basically the the the the passes were defined to address our problem. So the problem is that in cuba, meaning we are exposing a limited number of flags and we want this to continue. Okay, this limited number of flags get translated into static ports. Okay, but user needs user. In some extreme cases, they need to configure everything of the static ports, not only the flags, but everything memory limits are the sidecar whatever that they they want to configure everything in static ports.

B

So patches is a really low level solution to eck. Everything is the last resource to egg control, plane components generated by by kubernetes, so it is not a second class. It is a first class, but it targets really a small set of use cases, which is I'm a super aspect. I want to act everything.

A

Unfortunate side effect is that a lot of basic use cases require patches today, so.

B

Exactly so, it's not exactly.

A

So it's not exactly an advanced use case. Everybody uses patches because we don't have an alternative.

B

Exactly I want to make this subset of common use case easy.

A

Okay, once you have the talk, uh just give me the link, I will comment we have to drop because we are over time uh thanks so much for joining and see you again.

B

A

Weeks, bye.