 Hello everyone. Welcome to 6CLI updates. My name is Maciej and I'm one of the co-chairs and I'll pass the mic for the rest so they can introduce themselves and they will be talking. Hi, I'm Katrina Viri. I am also a co-chair and a tech lead for 6CLI. I'm Eddie Zaneski and I'm a co-chair for 6CLI. And I'm Sean Sullivan. I'm also a co-chair for the 6CLI from Google and I'm going to actually take the first few slides. So we've already done our introductions here. And so initially, what is the 6CLI? So we establish the conventions for writing CLI commands, including POSIX compliance and improving the command line tools from a developer and DevOps user experience and usability experience or perspective. So that was a mouthful. And so what is it specifically? What are the concrete artifacts? So the first one that everybody probably knows is Coup Control, which is our standard command line tool to communicate with the clusters. And when I first joined actually, Coup Control was the only sub-project. But now that I look up here, I see that we have quite a few other artifacts and repositories. So the next one is Customize, which is a template free hydration tool for YAML configuration. And the next one is Crew, as well as the Crew index. This has to do with Coup Cuddle plugins. And after that, we have a sub-project for Cui, which is a GUI version of the Coup Cuddle client. So in addition, the CLI runtime and the CLI experimental repositories are for libraries, especially the CLI runtime. It is for libraries for building command line tools. And finally, we have the KRM functions, which is client-side functions that operate on Kubernetes declarative configurations. And that's kind of the newest of our sub-projects. And so here we have, how do you communicate with us? Well, Slack is always good, but it's not clear that you're going to get a response immediately. The mailing list is the added bonus for joining the mailing list is that it will send you an invite to our meeting, which is what I suggest is actually if you really are interested in contributing or you have a particular issue that you need to get resolved, Slack will get you a particular distance. But if you really want to talk to and make sure that your issue is going to be raised and has visibility, you're going to want to show up at our bi-weekly meeting. And here's the times for that. And as I mentioned, as soon as you join the mailing list, that will send out a calendar invite, so you'll be able to join that. And then the other meetings that we have, we have one for Customize, that aforementioned sub-project for the template-free configuration management. And we have a monthly or every four weeks, we have a bug scrub to address triage issues for coop control. So with that, I'm going to pass off the mic to Mace so that we can talk about some updates. Yeah, so a little bit of what we've been doing. And I'm not going to go through all the features that we've been doing. The slides that we will ensure that are on schedule are not yet there, but we will. You can track them and have a look through all the links and see what we've been doing. What I would like to use our spot here is to give shout-outs to all the folks that are actually working on those features. So Nikita, Arda, Laoh, Katrina, Jordan, Aram, Gianni, Daniel, and so many others who chipped a lot of the features into 124. Mark, which PRs around completions are significantly improving the completions capability of Kube-Cuttle itself. And literally yesterday I attacked his PR. Mark was very, very patient with us and put together a proposal for providing plug-in completions that merged. There's a bunch of other additions in 125. And here again, shout-out to Brian, who's sitting right over there. Philip, Laoh, again, Paco, and all the folks who are helping us with delivering those features, making Kube-Cuttle even better, more rich full. Of course, we are working on a couple of additional things in 126 release. There's a bunch of stuff that we would like to do, but there's only a handful of us. There are changes with regards to how we pick the default containers from the resources that exist through an annotation. We're pushing the Kube-Cuttle events. So if you know so far, you're probably were primarily consuming events through Kube-Cuttle get command. We're working to make the events command a little bit more smarter than just get. By default, it will be similar, but it will allow you to have a little bit more control about the filtering. So if you combine describe, describe will always show you the information with the events related to a particular resource. Get did not have that ability, and we could not embed this kind of functionality in get, because get is more generic command for every kind of resource. So that's why we started working on the Kube-Cuttle events command. The new additions that we are putting together is to improve the explain information based on open API V3 so that when you are explaining resources, you have a more complete information about what a resource can and cannot do, which fields are required, and all those additional metadata that are present and can be present in the open V3 that was not available. And we're also working on aggregated discovery, which in the long run will improve how Kube-Cuttle gets information about all the resources that exist on the cluster you're working with. There's of course a bunch of stuff like I mentioned before that we weren't able to pick up. They have been moved a little bit. There's still some work that needs to be done. If you're interested in working on any of those that are on the slides, or if you're interested in pursuing some of your own, like Sean mentioned, the 6CLI bi-weekly call is the best options or ping us on Slack, send an email to the mailing list, start the discussion, and that will be probably the best option to get the discussion rolling. And with that, I think I can pass over to Katrina. Thanks much. So this next segment is one that we did at KubeCon EU as well, so apologies to those of you who have already seen it. But the issue of declarative and imperative workflows and the distinction between those two things being misunderstood has come up a bunch of times in our SIG over the past year, and we feel like there's a really important message for the SIG members to understand and to help other end users as well understand about how these things work. So with that, what are we really talking about here? What are we talking about in terms of configuration management workflows? In the documentation, this is called object management techniques, and there are basically, if you want to have an object in your Kubernetes cluster, say you want a deployment to exist or a service to exist, there are a few different ways you can go about making that happen, and those are referred to as the object management techniques. There are two categories, imperative and declarative, and with an imperative, there are two subcategories, which I'll get to in a moment, but the message that we want to deliver is that these categories here should be considered mutually exclusive. A given Kubernetes object should be managed using only one of those techniques. If you choose one technique, can you stick to it? Otherwise, mixing and matching will result in undefined behavior. So let's go over those techniques. The first one is the imperative commands. So this is a really simple approach. If you're just experimenting, you're getting to know Kubernetes, you're doing some training, or you're messing around with a local cluster, this is an appropriate technique. It basically means that you're operating directly on live objects in the cluster, using CUBE control commands that take care of everything that you want to do. So if you're using CUBE control to create, you'd be passing it arcs and flags that describe the object that you want to create, for example. This is the lowest barrier to entry, but it's also only suitable for development projects because it doesn't give you a way to support, say, a change review process. There's no possibility of an audit trail, no source of records besides what's live, so not good for disaster recovery. You can't tell what you use to create the object in the first place, so when you want to create another one, you don't have a template to go off of. It's just really for that development exploration sort of workflows. The other imperative technique is basically the same command, so you can have create and replace and friends, but you use them with the dash f, typically argument to pass a file that describes the specification of the object that you want to create. Since you're using a file like that, you get to, say, store that file in version control, and then you get compatibility with the version control review and auditing flows that most of us want to have. So that works pretty well. It works, but it has a few limitations. For one thing, it works only on individual objects and individual files, because if you are operating across the set, you might need to do different operations for different objects, so say, maybe some don't exist yet, so you need to create others, you need to use update others, you need to perhaps delete. So you need to do them one at a time because you can only do one operation at a time with these imperative commands. The other major downside is that it this does not work very well for objects where key fields are populated by other actors in the system, say, a controller. The classic example here is a load balancer service, which has an external IPs field that's going to be populated by a controller, and if you just do keep control, create one of those services that those IPs will get populated, and if you use replace with the same file that you have before, you're going to override that field and it will get cleared, which was not what you wanted to do. So you end up with a more complicated workflow where you have to pull down all the other actors changes and include them in all of your requests, which is not really all that elegant. So this is production ready, but it is not as sophisticated as perhaps we would want. So that brings us to the crowning, basically, object management technique, the one that we really recommend everyone use in their production workflows, which is declarative object management. And that specifically means that we're using that file-based workflow to declare the objects that we want, but we're also using it with Qt Control Apply specifically. Qt Control Apply is a much more sophisticated command because it actually will figure out for you whether you need to create or update or delete the object, and that lets you work with a set of objects on which different operations might be required within the set. It has the same advantages for version control and auditing that we just discussed because you're working with files again, but it also is able to retain changes made by other writers, even if the changes are not merged back by you into the object file. This enables the final state to be collaboratively determined with the other actors in your system, with merged strategies determined on a per-field basis. It's pretty sophisticated, and this is really the workflow that we recommend that everyone use. So the point again here is that once you're familiar with the distinction between these three, it's important to remember that you should stick to one or the other for a given object because mixing them together results in undefined behavior. So when we bring this back to Qt control, for the declarative technique, it really is just Qt control apply. So when you want to create your objects, use Qt control apply. When you want to make an update to them, use Qt control apply again. If you want to roll back to a previous version, you retrieve that previous configuration that you want to roll back to, and you use apply. It's your whole workflow ends up centered around that one command. The imperative commands in contrast, there's a whole suite of them, and some of them are pretty intuitive that they wouldn't work together, like create and replace, expose, autoscale. Those one and run. Those are just a very different approach to the exact same operation, but the gotcha here that some folks find unintuitive is that other commands like Qt control rollout undo, that is also an imperative command that is going to have undefined behavior when combined with apply. Some of them, they're also a set like edit and set and patch and scale that are somewhere in the middle where they do have a somewhat predictable behavior if you understand what they do, but a lot of folks seem to expect that if you do an apply and then edit an apply, the apply is going to overwrite the changes, but from apply's perspective, edit is an external actor that it's collaborating with, so it does not actually do that. So in summary, undefined behavior means that it's going to, you have to really understand how all of these commands work and what they do to use them safely, so it's really best in most cases to just stick to the one strategy and not mix them together. This is warned about in the docs, I now have the screenshots here from the docs and there's a link at the bottom that you can follow to read more about all of these strategies and how they work and what the best practices are. And yeah, again, please use apply, that is the most mature strategy and the one that we like to support. And with that, I'll hand it off to Eddie to describe one of our exciting new guests. All right, if anyone not familiar, Kepp is a Kubernetes enhancement proposal, it's how kind of major changes have been to the project. So when we think about kube-config's, everyone has gotten a kube-config from their cloud provider when they've created a cluster, right? The problem a lot of folks run into is your kube-config is tied to a particular cluster, but you could sometimes have multiple contexts with multiple clusters. And so this gets really hard when we want to ship files around or drop it into CI system. And the issue is that kube- control is a very old tool that we can't make a lot of breaking changes to because everyone uses it in pipelines, everyone has these archaic bash scripts and it needs to keep working. So when it comes to kube-control, our hands are very much tied. And so the goals of what we're trying to accomplish are we want to maintain kube-control's strong guarantees and backwards compatibility. I want to be able to opt you into new default behaviors that would be breaking changes. And these are we want to consider as a per-client configuration, right? So if you want to set a setting on one laptop and not another or a remote workstation, not your local one. So these want to be separated from your cluster configuration, right? The thing about your cluster config is your username and password for your cluster. You don't want to have your settings in there that get blown away when you get a new kube config dropped on top of it. And so we sought out how to solve this problem and we put this kept together and we talked through some of the use cases. And so I want to be able to have delete confirmation. This is something that I've been, the soapbox I've been standing on for the past like three years is it is very easy for you to delete everything in your cluster. If you accidentally delete a namespace, you accidentally delete everything in that namespace. If you accidentally delete all namespaces, you've just blown away your entire cluster. And it will just listen, right? There's no confirmation. Are you sure you want to delete everything? So we want to add interactive confirmation that says, yo, you about to delete everything. Are you sure you want to do this? We can't do that because it is a backwards breaking change. So any CI pipeline, any script that's expecting that command to just run without asking for user input, it breaks. We talked about ways to do this. You could try to detect if you're running in a CI environment. The fun thing about CI environments are they fake being an actual interactive terminal to have pretty outputs in color for you. So this isn't a problem that we can just solve by hacking around. So we also want to be able to add colored output by default. So if you want to opt in to pretty tables and colors, we can't do that in a CI run or any sort of thing that's expecting output because it adds those magic 1-3-3-M characters that you may have seen when you copy-paste. People want to be able to define aliases for cube control commands, and some folks want to be able to define default flags. And we're looking for your use cases. So anything that you'd like us to see to add changing or breaking compatibility, that's something that users would want to opt into. There's just a giant list of things that if we were to rewrite cube control today, we would not do it the way it was done. So our hands are tied on a lot of the situation. So this is a way that we're trying to attempt to make those changes and give folks maybe more sane defaults. And so this is the config that we came up with. I don't really like it. And so we want feedback, we want thoughts on it. The solution for these command aliases, this is the first one we attempted. So if you want to opt into delete confirmation on every single delete command you run, I don't want you to have to pass a flag that says, yes, I want delete confirmation on every delete command. That doesn't help anyone because it's an accident. It's a human error where you forget to do that flag. It's a human error where you delete the wrong thing. And so the original thought we had was to take the commands that you're running and set a set of default flags that will be tacked on to that command. So that's what you can see in this example here. So the third one down, it says the flags confirm default to true. And that will match to delete command. I don't really like this. It solves the problem though. And so every time we think about how to solve this problem, we keep getting stuck on different bits, what will be usable, what's easy to modifying and configure. So we're looking for feedback. Is this something you'd like to configure? Is this how you like to opt into these behaviors? It needs to be extendable. It needs to be easy for folks to opt in and change behaviors. We don't necessarily want to have a setting file for every single flag or default command that comes in here. And there's a lot of folks that want to, they've asked for default aliases for commands before you. So the first example you can see get db prod. It would pass a set of flags or configs that you'd have on here. So save some folks for typing. Same thing with the last one here. SigAuth has the authentication plugins if you've used a cloud provider before. They want to be able to allow list only a certain set of auth plugins that your program can run on your computer because turns out this can be a security risk. These are arbitrary binaries that just get called from another config file. So we want to be able to allow lists. You only want these certain authenticators of these binaries to be ran. So these are a couple of examples that we came up with. And with that, we're going to jump into discussion and Q&A. We want to hear from y'all. We have some contributors in the crowd. Wave your hand. Wow, wave your hand. Yeah. Anyone else make a PR to Kubernetes or kube control before? I'd love to see that change a lot by the next kube con you go to. The project is deeply understaffed. And we're pretty nice and super welcoming. And if folks can commit to sticking around, we'd love to get you up to speed and do whatever it takes. I'll talk to your bosses to see if you can spend a chunk of your work time or maybe half a day or something. So yeah, we'd love to hear from you. I think we have another microphone somewhere for questions being run up. But let us know anything we talked about today. Anything you'd like to see, anything that bothers you about kube control in general, anything about the cap we just talked about. But yeah, we got plenty of time. This is a chance for us to listen to y'all. We will make sure that the slides are up. I'll personally make sure that they do. Because I can't repeat that. Sorry. So kube control is a go project. So it's strictly statically typed. It's very easy for us to marshal something like this into a struct and use that elsewhere. So that's why a lot of the kubernetes stuff is done with the ammo because we can take that marshal it into a go type. That's the same thing we did here. This is versioned and extendable. So we can have different versions. We tossed around the idea of if you were using a certain version, we would automatically opt you into default behavior. But that sounds like a gun waiting to happen. Yeah, that's the design choice for that. Yeah, the other kube config is also that way. And it's just a very common strategy across the ecosystem, including for the exact reasons Eddie mentioned, like the ability to have a kind that can verify that we're uploading the right thing and the versioning capability is super, super handy. Yeah, the question was basically about the restricting the aliases to work only on specific commands or only on specific arguments. I don't say yes, I don't say no, we don't know. We would have to double check what's possible. I don't want to over complicate the functionality and we have to weigh in the options of introducing such a such a thing. I'm actually I was when Eddie was presenting this, this file, I started wondering that instead of doing default flags like he proposed here, we could actually allow overriding the default commands with aliases. So normally if you're if you're working on on a Linux environment, and if you log in as root, it has a default default alias for RM, which always asks for confirmation. So I was actually thinking that maybe that something like that in a cube color would be better because I'm not explicitly saying, oh, this is a default flag, but I'm actually saying, oh, this is actually what the delete should be doing in my case. There are options. I just realized that when Eddie was talking about that it could be a good approach. And maybe we actually should focus more on about, oh, just provide a general aliasing mechanism and people that will give a lot of flexibility with regards to default flags and whatnot. Maybe that will also simplify the ability to, oh, this will only apply for certain use cases because we would be able to provide because limiting the scope of the API would allow us to have a little bit more flexibility at the same time, though, like I think we're very open to just hearing those use cases, right? Like if that's the way that you would want to use that command, that's the way you'd want to constrain the interactivity. Like that's very interesting for us to know, I think. So thank you. Yeah, so this is, can you blow that up maybe a little more? This is the actual struct for a cube config. So this is what your cube config gets marshaled into. And if you, you probably can't see, but there is actually a preferences field that's old and it actually, scroll down just a tiny bit, much, eh? There's a color field that most people don't know about. It doesn't actually do anything. It was a thought that it would one day. But yeah, so this is what we're trying to separate out from. Yeah, that came up. That's great feedback. It is on the, it's definitely we mentioned in the cap as a future thing to hit. We don't know how to tie that forward. So if, if you could tell us what you'd like to see, all the drafts I came up with for that were, it got really messy tying it to a context because it gets even more nested and then you have to map things to there. So if you can brainstorm and napkin that with us, we'd love to get your feedback on what you'd actually like to use for sure. Yeah, we'd love you all to join us for the meeting to help. We need help working on that. Like literally someone needs to step up and help to finish the cap, help with the implementation, help gathering the feedback and pushing the implementation through all the alpha, beta to GA stages. The sooner the more people will be interested in it and the sooner they start working on it, the better it'll be and the sooner it'll be available for everyone to use. And I'm not saying that we will solve all the use cases from, from the get go. That's not the point. That's why we're introducing versioned config files. We can iterate over those versions, but getting something out the door and then play with it, it's definitely helps rather than talking back and forth without actually hands-on approach. I'm going to put Brian on the spot here because Brian has taken ownership over that one. Yeah, so I guess I got ownership somehow. Yeah, I mean, our localization is not in a great place as far as like if you're using it in another language. And I would say like 90% of the of the output is still in English, even though you're trying to use it in another language. So I don't think we've made a decision on that yet. I mean, you're welcome to attend some of the SIG meetings and provide some feedback or we can talk about it now. So it's still kind of up in the air. I think we would like it to be better. So that's, I think it was proposed that well, if we can't do it well, maybe we should just remove it. I don't know that that's the answer, but that's certainly on the table to remove it all together or turn it off for some languages that are incomplete. What's your thoughts on? I mean, is it helpful to have Korean translations for you? No, it's really helpful to hear your thoughts on that. I think at the very least, we need to improve the mechanism that people can contribute. It's too hard to localize right now. There's, it's not easy to do and I think we need to make it easy to do and that's going to, at the very least, help improve the coverage. And I think part of it, I mean, there's a lot of ideas on some of the ideas I've thought about and haven't really got it down, but we need probably to develop some metrics around it and say, okay, well, we can look at it and see that it's not good, but how bad is it and so that we can measure it and see that it's improving and maybe we have some metrics and say we're going to turn off any language that doesn't have more than 50% of its output or something and then we won't remove it, but we'll turn it off and then, or maybe we trigger some issue to be created and say, hey, we need help improving Korean translations because it's falling below this threshold. Well, yeah, so we do have a survey in the works and I created a pull request for an issue, I guess, rather for a survey that we don't have any timetable for when that's going to be created, but it is something we want to do and I think what we want to make sure is that it's getting to the right people. So we want to hear from people who use KubeCuttle in one of the languages that are supported and then part of it is just to find out how valuable is it because it's one thing for somebody who's native language is English to look at it and say, well, this is not good, we should just remove it, but it doesn't, we need to hear from the people who actually care about that feature and so our strategy is to try to create a survey or we've created a draft survey, but I think the challenge is how do we get that out to the right people and so we're soliciting help from one of the groups in the Kubernetes organization to try to figure out how to do that. We also just had a conversation with Brendan Burns, one of the creators of Kubernetes and he mentioned he worked on the original international, internationalization, I-18-N and the thing that he recommended to us going forward is to have, because it's easy to have someone come in and do it once, but then it drifts so much, which is what happened originally. So how do we put a blocking job or a pager that goes off whenever we need someone to come back in or maybe we set up an interval if someone wants to be a language owner, they can come in every month or three months to do it, so. Yes, we definitely want to support the international community for sure. Any other questions? I think we're out of time. We'll hang around, we'll head to the booth crawl afterwards, but yeah, feel free to ask us anything and thanks so much for coming and yeah, we're nice, so talk to us please.