Kubernetes SIG CLI, 21 Sep 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG CLI 20220921

Description

Kubernetes SIG CLI bi-weekly meeting on September 21st, 2022.

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

A

Foreign, hello today is September 21st, and this is the six CLI bi-weekly meeting for September 21st. My name is Sean Sullivan I'll be your host. Today, I'll start immediately with the announcements we don't have too many of them. Let's remember about the the new 126 release. We have an enhancement freeze in about two weeks on Friday October 7th, so we have about a couple weeks in order to get the enhancements submitted before for the 126 release.

B

Yeah, the seventh: uh if you look at the uh at the UTC calendar, the seventh is 1am in the morning.

C

B

Seventh, so I think it's better to say everyone that it's the sixth, when the uh the code that the enhancement screen starts because it's 6 pm um aesthetic so that that will be the majority of things like late in the evening.

B

Also an important date would be a week earlier, I linked the uh no 126 days and the fact an important date is week before, uh because the sick architecture does the prr reviews and they asked or there's a soft treat a week before that on Thursday 29th.

B

So uh if you're awaiting production readiness review, I would suggest getting them uh sooner than the United States, because it might be tight. There's like I said there are only two uh to people. uh That's really looking at the prr reviews.

A

Okay, yes, both of those are very helpful thanks for that, um so I've managed to get that.

A

On our notes, uh so that the production Readiness review is Frozen uh as much I said the the week before, then, the enhancement freeze, I've, updated that date to October 6th and then our code freeze, which is further down the road, uh but not too far on Wednesday November, 9th.

A

And the next item is that the steering committee election is ongoing and you are able to vote until the 30th of September that has opened and is continuing. So if you are eligible, please vote for the steering committee there's going to be four members that are going to be chosen this cycle and there looks like there's eight candidates for those four openings.

A

Does anyone else have anything else that they would like to announce to the to the sake.

A

Okay, let's move on to introductions where we get to meet our newer, the the newer 60 Liars for those who are new or who haven't been here for a while. If you would like to introduce yourself uh to better acquaint yourself with your colleagues in the Sig, uh now is the time to do it, and this is completely optional. Is there anybody who'd like to introduce themselves.

D

Yeah I'll go first since I have some items today: I'm Alex I work with Sean at Google, mostly with uh on Sig API Machinery I, haven't been around in a long time. So some of you might recognize me, but otherwise, nice to meet all of you.

A

A

Is there anyone else who would like to introduce themselves.

C

Yeah hi, um my name is Sheikh I'm working with mavnir I, have ideas of experience, I'm, CK and security certified um yeah nice to meet you all.

A

Pleasure to meet you.

A

Is there anyone else who would like to introduce themselves foreign.

C

To the fact that I've changed my name to Marley.

C

D

So I can start.

A

Yeah sorry about that I've got there's some work going on and they just started making lots of noise right now. So I apologize, um but we'll move on to the topics and Alex thanks.

D

uh Yes, so can we look.

D

Yeah, so if we can go to the files, change and yeah view, the file of read me I'll be probably easier to look at if we looked at the rendered markdown. If you press the dots in the top right and press view file.

D

D

Can you scroll down to summary um just let's just we can just look at that while I introduce the topic um so yeah me and Antoine, and some of the other six API Machinery members are here today to try to solve a pretty large issue. That's been affecting people and from blocking them from migrating from using client-side, apply to server side apply um So. Currently, the documentation directing users who are using client-side apply to begin to use.

D

Server-Side apply, uh directs them to simply just call Coupe cuddle apply with their object and the server side flag. Unfortunately, it doesn't really work like that. So simply because of the problem, that's Illustrated in these commands. So can you can you scroll a little bit more so in the First Command we are using client-side apply to just create a simple config map with two keys key and Legacy gets created successfully, and then, if we follow the instructions um from the documentation to start using server-side apply, it says it's successfully.

D

Server side applied and everything's good scroll down again a little bit more. If we choose again, if you choose now to try to remove the Legacy key using server side apply, the server accepts our patch, but when we print out the object again, the Legacy key will remain, and this is because, when you initially use that server-side flag, the API server will copy all the managed fields that are owned by client-side, applied to also be owned by server side apply.

D

So there are two owners of every field so that, when server side apply, drops the field, it's removed from the managed fields owned by the server-side applier, but it's still owned by the client-side applier. So it's not dropped from the object.

D

So the goal of this cap is to provide a migration path for people who are being blocked from adopting service I apply by this issue. um Currently, that's mostly, um you know. Large cluster operators who have a lot of objects to migrate and their current only path would be to manually patch their managed Fields themselves, so um yeah. Their goal is to provide a path for this using possibly a coupe cuddle migrate command.

D

If you can scroll down a little bit more Sean, uh if you're not really married to this idea, but generally just a an operation, users can run to migrate. Some client-side apply, manage fields to now be used by server-side, apply a one-time, irreversible patch to their managed fields that prepares them for the future of only using server side apply, especially now that it's ga um but uh yeah this. We basically just like this Sig's blessing of this kind of change, or maybe there's some other ideas for how it should surface to the user.

D

That's kind of the high level approach, if there's any comments or questions.

C

Is this just just changing the field manager or you are going to remove the last applied annotation? Why I'm asking asking this because uh I wonder this enhancements has effect on the imperative commands that does not support server cited by, for example, I'm. Seeing now an issue uh related to the chip control edits, which apparently does not support server-side apply, is.

B

There any effect.

D

um So there's currently an implementation of this migration and client go that does this like, if you give it an object, it will perform this patch on it and it does remove the last applied configurations. So client-side apply would no longer be possible on these objects. We can certainly discuss that um and make sure that your use case isn't blocked, especially could cuddle edit.

E

D

I can add a.

E

Few worlds about that yeah, if you, if you do a coupon related to other field, it's going to be preserved even with this, which I think is the is the right thing to do.

B

Why don't we want to go the path of this server side? Apply is meant to be in the future, because that's basically, what we're trying to do slowly, foreign.

B

Do the owner's migration the first time you try servers that apply and then any any subsequent client that apply would complain that oh I'm, sorry. But this object is currently managed by the server and if you try to do it with a.

C

B

Side apply, you're gonna run into problems, are you sure, run with Force and then we'll just allow it? In all other cases, server signify will just very smoothly.

B

That would be a simpler plan for migration, because, with my grade uh the fact that you're adding a new command you'll have to go through an experimental uh flow, so that means you'll add a new command.

B

uh The command will be hidden under uh Alpha sub command and also only after a little while on the necklace, we would be able to get it up to the main top level demand. So why not being explicit about the server's thought immediately when a user tries it the first time, assuming that previous invocation was, clients are or basically it wasn't? The previous wasn't the server side of a lot.

D

Off the top of my head, I like that approach, um but proposed the migrate command just to I, guess get the idea across.

E

Can I uh yeah, so I think I I agree with you in Manchester if we do apply inside of like? After all, we've done this migration step. We should definitely detect that and complain. This design doesn't prevent that from happening. So we should do both, but the thing is uh we can't detect if the migration has happened. We solid state reply because we're not supposed to get the object. First,.

E

So it's kind of tricky to detect if seller side of player has happened when we're doing a suicidal flyer.

E

Exactly thank you. Sean I mean currently it does to be honest as a bug. It's a bug that we do get the objects for ourselves at a play, even if we don't need them.

B

um Honestly, I would be fine with that book being persisted, then, for a little bit longer until we get rid of the client-side apply entirely or eventually, when we will agree that this was fully migrated, rather than fix the back of removing that Gap, because that.

C

B

At least Ensure that we're not running into trouble because client-side reply always have to do that again. So the fact that we will be adding that extra get I I, don't think it's it's that big of a deal and it is, and the benefit will be significantly higher.

B

If we inject that information in the current flow, rather than adding additional command and like I said um for my own personal experience, users will not migrate if it will require third parties uh third-party command, because they will uh either delay it as long as possible and they will still mix both so that um that warning should be there, no matter which option we will pick.

B

It should be there that um oh I I, already migrated with the server-side applied and I will not allow it if I remember correctly, uh at least for the service that apply for some bits. You were doing something like that in the past, for the server side of things where you had a table or would happen if this or that apply was picked, I would probably just copy the same method that do not allow going back uh from server backup line. You have to reply through the resource or recreate.

E

It to go back to reply. Oh that sounds good to me.

F

um I'm concerned I have about this is the fact that, uh coming back to the pruning conversation, we've had a few times in recent meetings. uh The printing functionality relies on that client side uh apply annotation being present, that's what it uses to identify its scope. So um I think that would be an unexpected side effect from an end user point of view that, when they migrate to server-side apply suddenly their their pruning doesn't work anymore or does something unexpected on the next invocation.

A

So we we should, uh we should allow pruning for whether the server-side metadata is there or the last Supply configuration. Is there. So the the reason we're checking for the last applied configuration is is because we don't want to prune um objects that uh have been created with Coupe cuddle, create or cuddle run.

F

We want essentially to identify the ones that were owned by.

A

The ones that have actually been created with apply, and so we should we check now for the last applied configuration. We should also check for the managed fields to see if it had been server-side applied.

E

That sounds good as long as you know, which manager always used to reply right.

F

That's what I was going to say on time like if um this would be a potentially a change like if you had multiple appliers, that could be sketchy, but you could have multiple players that created that last Supply configuration and before they would all have the same identity, because it's always classified configuration annotation, that's used, but in the new world that could be actually several different, um several different identities and you would still end up with a different result. After migration, foreign.

C

Or something like that.

F

For server side, printing.

B

Yeah to support Printing and the service I'd apply.

F

um Since it's a a batch like it, it has, it inherently is operating over a whole set of objects in different groups. I, don't know if that could be moved to the server side. That would be pretty fundamental change, um because the server doesn't sets right.

B

F

Making it compatible with server side apply, while still actually operating on the client side should be feasible, and that's something that we've discussed in previous meetings.

A

Yeah, it's actually I think that it's actually not that difficult to get this working for certain the pruning to work for server-side, apply. I! Think it's just checking if there are managed fields.

A

In so that we know that it has been created by apply. That's all we really care about. Has this been created by apply a client-side or server side and not Coop, cuddle create or Coupe cuddle run? That's all we care about.

C

F

You mean like that it has any fields that are owned by the server-side apply field manager that we are currently using.

A

That yeah, that doesn't matter at all those are so so there's two separate Concepts that may be conflated here, which is pruning fields, which is what the last applied configuration. Annotation is necessary for for pruning a field, but for pruning an entire object. When we're applying sets of of objects, then it not. Those considerations are much simpler. It's just whether or not it has been created by apply versus a different creation command.

F

Right but my point is that, like there's, no singular apply at Antoine has in the chat there like. Maybe we need to provide a list of managers to consider because there's no singular apply operation and server-side apply.

A

So so, um okay, so for for a pruning operation, let's say we. We do the use the minus prune flag, minus mice prune flag, and then we also use a uh a label to describe what the previously applied set was.

A

So none of that has anything to do with how that previous set had been applied or how the current set is being applied, whether it's client-side or server side.

A

So when we're just about to delete an object for pruning, if it's in the set difference- and we determined that we are we're going to delete it for the prune, because we just have the prune command, then we check the last applied configuration annotation before we delete it to make sure we're not deleting something that had been created with a different command to make sure that it is something that was applied so again, I I think it doesn't matter whether they were applied or are being applied, server-side or client-side.

A

We just have to determine whether they were by either checking that the managed field exists. Saying okay. Now we know that it was server-side applied and we don't care who that owner or that manager was or the last Supply configuration, knowing that it was client-side applied by somebody.

F

A

C

A

F

Give an example of where I think this could apply, and you can tell me whether wrong about this being a thing.

F

um My understanding is that, like you, could have a controller in your cluster that uses server side apply right um and then that would also cause there to be managed fields that are owned by that controller, hopefully with a distinct identity, uh field manager, identity and then, but that's not who I am in this operation. I'm I'm, like the deployed the CI pipeline, a CD pipeline rather um and I, have a different field manager, so I should not then look for objects that were server-side applied by a random controller.

F

That has nothing to do with me. I.

A

Don't wanna I don't want to scope those in.

F

And prune them.

A

F

A

F

Don't I don't think so because that that would not have been scoped in in the past because they wouldn't have been using client-side apply from their.

F

um That would be a behavior change as soon as they did the upgrade.

A

Okay, that is, that is a good point and and what it points to more than anything is that the current prune is broken um so, but.

A

ah Okay, let's see what let's see where you're going with that: okay, let's I put that there's uh some pruning considerations. Let's make sure that we address those in the cap.

C

F

Think it's a discussion on the cap.

A

Okay, that is a good point.

D

All right, yeah thanks guys, sounds like for this. This one there's, you know generally support for the you know, idea that we need to fix this problem just need to surface in a different way and figure out some of these uh dependencies on the last applied configuration there's also Kube cuddle uh edit. That was mentioned um yeah uh thanks, guys, I'll be off for this one.

A

Okay, I'll bring up the next one.

C

C

D

Okay, so yeah this is. This is also my uh item. Can you scroll down to the summary Sean.

D

So this is a little bit uh I guess less grave, um but still very important. We'd like to upgrade uh Coupe cuddle, explains data source from using open, API V2 to using open API V3.

D

um If, like, can you scroll down a little bit more? So you can see the motivation uh yeah. The reasons for that I guess are twofold: open API V3 has way more useful data. um I only listed a couple of them, because I think that they're motivating enough nullable in default. Being too uh ones I'd like to highlight that users have been requesting to see inside of their explains, so you can see like what would be the default value of a field or if the field is nullable. Things like that.

D

The other motivation for this change was is that currently crds specify their schemas in open, API, V3 format and the server does a lot of kind of hokey things to convert that V3 format into V2 and and the conversion is very lossy and there's probably no way that we can have a good, accurate experience using that information.

D

um So what how that's manifested with clients using Coupe cuddle explained is that if there's a nullable field, for example, it would just have no no data and explain just be just say object, but you actually I should include that in a cup here, but um the server will just elide any information that uses open, API V3 features, rather than represent them inaccurately.

D

So to so as more and more users are adopting these open, API V3 features in their crd, schemas they're. Finding that Coupe cuddle explain is not as useful for them uh so yeah this.

D

My primary goal with this cup uh today is to get some backing from the Sig for doing this change and get some advice for how we should um gate the feature and you know, promote it through different stages: open API, v3s right now, in beta, as of 124.

D

um And also, as part of this cup, we thought uh we were taking a look at how the printing can you scroll down a little bit Sean, um so why we're uh yeah down to so you scroll up a little bit to goals.

D

While we were looking into how we would implement this, we noticed that a lot of the current explain implementation is not very maintainable, pretty much like compared to F formatting, and you know loops and things like that. So it's not very easy for people to maintainer. You know add, updates that we're trying to do so.

D

We thought this would be a good opportunity to replace it with a text template implementation um and since they would be using text template, maybe it'd be possible for users to specify their own templates, but that's definitely not a primary goal of this cap, but something to discuss.

C

B

Yeah, are you planning? Are you planning to maintain both V3 and V2 implementations such that? If a cluster serves, we will go with that by default, um because it has a richer information about the fields or for whatever reason, either. If it's an older uh cluster or the V3 is not enabled, we will fall back into the V2 as a backup and I'm perfectly fine.

B

If that will be even up to the point where we have two separate um files under the explain: command wants just for maintenance, maintainability or one will be handling the V3 Printing and the other one rv2 printing, because I would assume that you set its beta in 125.

D

B

24., okay, so, even if, if we would assume only the official supporters of plus minus one school foreign, which we try to honestly keep to even longer, that would probably be the best option.

B

um I would prefer we do it smoothly for users, because they will not lose information. It will be actually providing more um more information if the cluster allows that so the best option will be transparent. Please do it for the users not.

D

Sure right, yeah yeah, absolutely agree with uh trying to see. If V3 is available, then we can use the new richer features for that and otherwise fall back to the old printer. uh If V2 is the only thing that's available.

B

Additionally, we can print that information somewhere for now until we uh we would GA that oh you're across or it does not support V3 so we'll we are falling back to B2 to just let people know why they are seeing different output if they invoke the same command on two different clusters, but something along those lines. Yeah I'm, definitely supporter.

C

D

If there are no more comments, I think I guess uh our questions were answered for today. For um you know, general, you know Sig backing and such. If do you have any more ideas or comments? Please leave them on the cup and we can continue our discussion. There.

E

Yeah Alex, can you talk about the templates.

D

I talked about about them a little bit. Is there something you want me to add.

E

I think I think that's a question in the cap about what types of template to we are low that you haven't mentioned.

D

um Right so some of our thinking with the templating and possible user customization uh would have been to so. We have right now. Cube cuddle explain, has a human, readable output, so we would provide a template that basically maps to the human readable output that you see today.

D

We are also thinking of providing internally, maybe a markdown template that can be rendered using a markdown generator or possibly users might want to provide their own template using a you know: minus minus template flag curious what this sig thinks about custom templates versus only allowing built-in templates that we support like there's a lot of implications with allowing um yeah custom templates. As far as you know, you have to now support the interface to the template and make sure that they don't break across kubernetes and open API versions, and things like that.

F

Are we talking go templates similar to what we support and get yeah.

D

Text go text template from the standard Library.

E

So one of the reason we are doing that is because I think those various tools in the community function item documentation, file types and uh none of the tools seems to be great.

E

This is pretty convenient if you have like you, can have your own HTML template and generate the whole documentation for your types in your own cluster, uh directly from control with like a one way to do that, it's like it would be the official way of generating documentation for types.

E

Even though people could have their custom templates and we could come up with like even internally, how could it could curl a HTML template so that we have a default way of generating documentation for types, but people could customize them for their own cloud provider or whatnot, um and we would have only one way of generating these from the good thing is, since it's coming from the open API from the cluster. It's it's a pretty common way to get the types.

F

I think I agree. That sounds pretty useful.

B

I, don't have any strong objections or support for the template. I I'm, I'm, honestly fine with the default, but if we maintain a default as is and I wonder if we could somehow split the cap into two I'm sure, if two caps will be needed actually but maybe write it as one and then try to migrate, both uh the flag can be, it will be, we will call it experimental initially and then we can play with it. It will be delivered in 126 or a little bit later.

B

B

Overall yeah sure, but I'm just trying, maybe I, don't know too loud. Those two have separate lies lives, something like that.

B

Then, let's show two separate tests, because that would be trade just to cover two rather smallish items into separate pets. Thank you, especially that they are touching the same command.

G

One of the things that would have been useful for kui when I was working on the explain style from a while back was a dash of Jason kind of variant where I would wouldn't have to worry about any of the details of how to to talk to the API. I could just use cucaro for that, but I would still be able to extract um the schematic level of information and then I can pass it to whatever formatter I want.

G

Based on the Json structure.

E

Yeah, that's also an option. We could have a template named raw that just gives you the Json technically but yeah it's equivalent to doing a good girl proxy and then getting the open, API directory. So I this the value is low, but uh yeah I. Guess we could do that and at least then we don't have to think too much about providing the template mechanism.

G

Yeah, that was my thought that that was sort of an escape valve people can use and use whatever formatter. They want.

F

Foreign at that point, this is just like a dash o, it's very similar to what we have another commands.

C

D

All right, if there are no other comments, I'd like to thank everyone, who's talked so far about it. Please leave any other ideas or comments. You have on the two PRS they're linked inside of the agenda for today. Oh give it back to Sean.

A

A

So we we put uh this next item on to revisit the coupe cuddle internationalization that we started talking about on the last meeting.

A

And so I'm gonna ask is, is Brian's here? Is there anything else uh that we've learned that we'd like to uh to update this? This item.

H

um I haven't had a chance to really spend a lot of time looking at it. um What I wanted to do was kind of try to get a scope of what the problem was, and maybe do some analysis to see like how prevalent are um missing translations and I didn't know if there was like some automated way that we could just like query all the um the um i18 in calls in the code and then and then try to see how many of them don't match up um for a recap.

H

This problem is basically because we all the I-18n keys, are essentially the English descriptions of things and when we change that, um then all the translations get broken, and so the result is we end up with language translations that are like 90 English and ten percent uh Japanese, or something and it's just like not a great translation experience or foreign language experience, so um so I guess is.

H

Is there um you know my my plan was to try to find some way to automatically generate um some sort of report or something maybe maybe a script on in the in the hack directory or something that people can run. That will just kind of say: um you know, hey, there's uh something you did just caused a translation to uh not exist anymore and I.

H

I, don't know, if is that even actionable I mean I, don't really I, don't think a lot of people really think about the I-18n uh ramifications of changing help text or something like that for a command and I guess. There's a bigger question of what is our commitment level to doing that or, as Sean mentioned, there's uh some cncf resources or Sig docs resources, Maybe, uh and maybe we have some way that we can drop something into a queue for them and say: hey. We just changed this.

H

Can you please uh translate it so so yeah, no real update but I'm curious to know if anybody has any thoughts on on this.

B

um We have an option to send tweets. um Kubernetes deaf uh Twitter accounts um to contradict at that option. I, don't know where, where that lives I think you just created for request and after as large as we can tweet whatever the message would be, how about a wee or in a parallel, maybe on several places. How about we create a poll?

B

Do you care about internationalization in Chicago or not, and that seems like the best starting option for us to at least know, because if, uh if the general answer will be that nobody cares, maybe we could start the deprecation entirely is. If there will be users, then we can start thinking about what can be done about it.

B

I mean from my personal experience being non-native, English uh speaker, none of it that I'm using are in my native language, um most often than not. They aren't the uh the translations are not accurate enough, so I rarely use them at all it, and it's just easier for me to um to work with uh with the English translations and whatever. Well.

B

The latest text, rather than translation um I've, approved multiple translation PRS over the past years, but there weren't that many and I've always relied on someone from Ledger geographical area to know and to task to have the final attack of the pr.

B

um The only ones that I actually reviewed supposedly were the Polish one all directions.

B

I I left it to someone else, so the question is where we will be looking for uh owners for those either is fine, but I would probably start with yeah, with some kind of a poll that overthinking what to do with the uh with that. Are you interested in it at all.

F

I missed where you'd send that full much are you thinking like.

B

We could probably send it on multiple channels. uh We could send it to Kate Dev Kate users um announced it on on cornetti's death. Official Twitter Channel, um maybe reach out to six uh country, backs, maybe put together some kind of a blog post that that would lay out the options that we currently have that we're considering and Link it from there.

B

And then we can also mention this topic during the uh the 60i session that we'll be holding in in Detroit in over a month and then just start talking about it outside of only our internal circles and learn what people are actually doing or whether they care about that bit.

H

Do we have any channels that don't primarily communicate in English, because.

C

It might skew like the kind of people who are going to respond to it.

B

That's a good point: I have no idea. That will be something that will be a quite a good question for contravex.

B

F

Time last time we discussed this, somebody brought up. There's a docs localization channel in in the kubernetes slack. I was wondering if anyone followed up on that or not.

H

C

Interested so rifle yeah I just want to add. If you decide to keep the internationalization uh like, we have the scripts, uh there uh called update translations and we are using gnu get text uh like uh commands, so maybe we could actually um uh like update the script, so it gives us a warning and the translations change and which need to be updated. So it should. If we decide to have it, it should not be that hard foreign.

G

I was curious. What what's the desire? um This is going to be a naive question, but for the extent of the translations, are we thinking about translating names of resources like pod, namespace or think about translating metadata spec, or is it more the surrounding help framework of the coming CLI.

H

Well, I mean this is really only addressing the things that are already um that already have i18n support, which are things like the short and long description of the commands. um Some of the flag, some of the flags or most of the flags I, think, are wrapped in the function call for i18n but you're right. There are things like the resource names, the things that are just really Dynamic, there's also things like error messages and other things that we don't necessarily.

H

We haven't necessarily wrapped all those in internationalization calls, so it's incomplete, as it is right now um so I think. That's all the more reason to to um follow. Mache's suggestion of polling the community and say: okay, if we're going to do this, we should do it, do it well, but first before we we spend the resources and time to do it. Let's find out if it how how important it is.

G

Makes sense we actually got a feedback with um a red hat team and um there was one of their QA folks noticed that an element of the UI said mainspace and they said oh well, it actually needs to be translated and they open up a defect and they I said well, that's we're just that's just the name of a resource kind, it's and so anyway, just there's a there's, definitely desire. At least at that level there was the QA people see strings that are in English and it seems strange.

G

It looks strange in the UI UI. That's completely Chinese, for example, and they have this weird English phrases so definitely would would help. But that's that's a that's a much bigger challenge and it's not. As you said, it's not a contained, closed problem.

A

So we could. uh We could revisit this uh in every single future meeting just to see where how we're doing on this, um but that would probably be more successful if we had specific action items which I don't know that there are specific action items.

A

um Is anybody willing to take on specific action items that we can uh check up on in future meetings.

H

What would the action items be? I know we have one with the with well. So let's I guess, let's identify them. uh The poll is one a block, maybe do if we decide we want to do a blog post in conjunction with that, um the the I-18n channel was mentioned in uh was mentioned again. It was mentioned last week as well thanks, Katrina and then um I guess there would be just us asking the question um getting there getting their feedback on whether.

H

I, don't know what what would we ask them? What whether we should uh attempt translations and if so, which translations Which languages, is that what what we would ask them.

H

And language and well and then also like us from a more like, um like Logistics standpoint like how do we? How do we keep uh the all the translations synchronized and that's yeah if they have any tips on how to do that because they just get out of date so easily.

A

So so, maybe a better way to manage this would be through uh through issues through some bugs. Does that sound better than trying to manage this through some AIS here in the agenda foreign.

A

Specific things that we're trying to fix and or to to solve the the problems being tried to solve which yeah it seemed like I said, like you said um this, it feels a little mushy and that there's it's not exactly clear where we're going and what's the.

B

Problem, maybe we could start with uh draft of the blog post, describing what the current state is. What the problems are, what the challenges are and outlining the option that we have, and once we have that in place, we can.

B

uh That will basically allow us to change.

B

And out of that, because creating the blog post is literally as easy as um adding a pull request in our website and then just sync, the docs folks, and that will be up and ready whenever we set those. So let's start the simplest possible way that and then try to promote it across as many channels as possible. Ideally we would have it ready the blog post before kubecon. We would also announce that during coupon and then we would ensure that the blog post has the link to the poll eventually.

B

Yeah, because we roughly know where we are, what the options are, which isn't someone who will sits down and write it down and write it into it, and we can discuss uh the final shape once we have the.

F

Yeah I, like that, like we could use the draft as an anchor for the conversation with like docs. If we wanted to do that before actually publishing foreign.

H

G

We have the capability to vet translations from the community.

C

H

Want to end up in a Scottish translation of Wikipedia scenario, I guess.

G

One thing we could go: let's say we could we if it's Noble, when we don't have a translation, for example in Slovak or whatever for mache, then we could it made it appear. You know to Senator. You know, please submit your translation suggestions here. You know, give them a PR link and send it, but then the security. Well, then, people could submit whatever yeah who's going to vet Slovak translations.

F

Polish, uh if we I I, think we don't, we don't really have that in place and that should definitely be described as part of the blog post uh overview.

F

um My experience with it personally is like I I, think much of a references as well I've been tagged on PRS for languages that I absolutely can't read and understand, um and at this point the process is I. Don't know like try to go. Try to find somebody um through the syntax localization uh channels to see if we can, if we can get a Community member who's.

F

You know already a group member trusted org member to to vet these for us, but we end up blindly approving essentially on the faith that they they review this correctly, because we have no idea.

F

And ideally I think mucho said this earlier, like we would have ownership by people who actually speak the language instead of um necessarily us for these translation files.

A

So if I understand the consensus, we we think we should start with the blog post um and with the blog post, uh we can move on to a poll to get feedback from the community. Does that sound correct? And if so, is there? Somebody who would like to raise their hand for the blog post.

H

I can do the blog post, I I'm, not um I'm, not really familiar with the mechanics of how how the translations actually work so I have to kind of learn that a little bit if anybody is familiar with it, uh maybe I could pick your brain on it. Yeah.

B

I, don't think it's familiar with the mechanism, but I'll definitely help you with the reviews and comments on the blog.

H

B

A

Thanks yeah um I understand my understanding. Is it's not all that involved it's where we have the text which is surrounded by the I-18 uh I? Guess it's a function or macro or whatever it is, and then there's a separate script in a separate directory that takes these translations for each particular uh language, That We're, translating, and if there is a match for that particular uh item, then it will switch it out. It's it's not that involved, but it's it's in a different area. It's not under a coupe control.

A

It's under like yeah I, don't even remember off the top of my head. Anyway. That's.

H

H

So, okay, so you can put my you can put my name there if you want to put somebody on that action item, unless somebody feels strongly about this and wants to take it.

A

Thanks for that, Brian appreciate that.

A

Okay, we'll we'll start there and we can just kind of revisit it as a stand-up to see what kind of progress we're making. If that sounds, okay.

H

A

Okay, so uh looks like we are over uh mache Arda. Is it okay? If we move this to the next one, or do you want to spend uh two quick minutes on the shadowing.

B

I'll go with the two quick minutes because that uh that actually might require a cap, and if, if I need to go with one, then I would like to start sooner than later. So uh when we did the two kind of plugins, we purposely said that we will not allow shadowing the building commands, um because that was the easiest option for us to start with, uh but we knew that there will be some options. Some commands where people would want to have the ability of the Shadows uh to build the internet.

B

One such example is specific, with create, especially that, with uh with so many uh crds being created on a daily basis, a lot of people are creating their own um have crds and they would like to have an option to overwrite or at let's say two color create my fancy, crd uh or if you are, and the question is what people feel about that option of adding uh searches for that I would be very selective about allowing certain commands, for example, I would not allow for starters, nothing more than just creates, given that for create.

B

We have good examples where this would be useful, uh but still disallow overriding. The built-in, except for the for Creator now, but we would always- uh and there will be the need in the long run. We would be uh always revisiting that uh that decision and eventually adding additional uh self-commands, which would be taken off the uh of that forbidden list.

B

Yeah, especially that a lot of people is acting like, are they just right? A lot of people is asking about create subcommands, and we are very frequently saying: oh, we don't want to allow additional, uh create supplements because they're very simple, and we don't want to maintain them uh if we would allow that people would be able to uh create their own, create sub Commandments, uh taking some of the burden off of us to maintain that in the cubicle.

B

So if you have some options, some, like the objections, um I'll post the cap once I, have it up in the 60i. 10 uh probably will send it over to uh to our main language.

B

I think I fit in two minutes.

A

Okay, so we we can revisit this as well in the next meeting. Does that sound, reasonable mache.

B

B

Because if I remember correctly, our next meeting will be on the fifth. Oh, that's still like close to the uh kept deadline.

A

Okay, it looks like we're about five minutes over anybody have any last uh last thoughts, yeah.

F

I have a quick one for for customers. uh We have this on Long running um docs migration, project, docs, consolidation, project really um and I think it would be awesome if we could sort of do a big push on that ahead of kubecon and and launch the new site then, but I would need a bunch of volunteers. You could to take the granular tasks uh so I without the information I'm, not sure if it's doable.

F

So if that sounds uh fun and exciting to you to try to get that goal, and you would like to help out, please ping me on slack and we'll figure out if we can coordinate it in time.

A

A

Big part of this there's a big push before kubecon for customized for I'm. Sorry, for what was that Katrina.

F

The docs consolidation project, docs.

A

F

I want to know if there's interest in doing a big push, if I can, if there would be bandwidth among the volunteers interested in the project, so I would really like to get it done and I think this could be a cool way to have a have a Target together um for launch um but yeah. This is a project where I'm, relying on on community volunteers, foreign.

A

Okay, great okay, we're quite a few minutes over I apologize for that. um Thanks for joining us- and uh we will see you in two weeks.