 Hi, my name is Maciej and today I'm going to talk to you about 6CLI intro and updates. But before jumping into further discussions, let me quickly introduce you what 6CLI is and what our mission is. So 6CLI, or Special Interest Group devoted to command line interfaces accessing Kubernetes cluster is a group of people devoted to making CLIs better. Our main project is Kube CTL, Kube Control, or Kubey Gattle. No matter how you prefer naming it, it's still our main goal to ensure that working with any Kubernetes cluster is easy and fun. Kube Control allows creating plugins and as such we provide you with libraries, CLI Runtime, and a sample CLI plugin which shows how to implement plugins. We have three sub-projects, Customize, which allows you to customize row, pre-template yams, leaving the original yam untouched and usable as is and work with Kubernetes resources. Crew, which is a plugin manager for the aforementioned CLI plugins. Crew also has a crew index where you can register your own plugins so that other consumers can easily find them. Finally, Kui, Kui is a graphical wrapper around Kubey CTL. It allows it provides sortable tables and much more graphical rich user interface than the usual Kubey CTL which you have in the command line. CLI has four people that are working on ensuring that the SIG is going in the right direction. We have two tech leads that will be Phillip Wittrock and myself. And we have three chairs, Eddie, Sean and myself. The three of us are responsible for organizational stuff for the SIG, whereas the tech leads are responsible for the technical direction of the SIG CLI. Our meetings are happening on Wednesdays, every other Wednesday at 6pm European time, at noon US Eastern and 9am Pacific time. On top of that, we have monthly box crops happening at the same time. It so happens that the next meeting, the next SIG CLI meeting is on May 19th, whereas the monthly box crop will be happening the next week, which is May 26th. You can find all of us in the SIG CLI Kubernetes Slack channel. On top of that, we also have our main linguist group, where you can reach us, ask for help or provide suggestions for improvements. Now let's jump into the main changes that happened over the past couple of months to the SIG CLI. First of all, welcome Kui, which completed the transition up to Kubernetes 6 repository. Kui was originally started by IBM folks. Big shout out goes to Paul, Nick, Mankting and Mark, who diligently spent couple of months of their work moving the Kui repository under Kubernetes 6 organization. The next important milestone that we just recently reached was upgrading Customize in the Kubernetes repository, named specifically in the KubeCuttle. So if you're familiar, couple releases back, we included Customize by default in KubeControl. It was accessible either as a sub command for KubeCuttle or it was accessible through dash K, which could flag, which could be used to many different commands in KubeCuttle. Unfortunately, due to dependencies issues in Customize, we were stuck with a very old version 2 of Customize in KubeControl for a very long time. Jeff and the entire community gather around Customize, work diligently over the past couple of months to ensure that the upgrade was possible. Finally, in March of this year, we've completed the transition and KubeCuttle ships the latest Customize available. We don't expect too many significant changes, so your preexisting Customize file should still work. The API hasn't changed between the previous version and the current version of Customize in KubeCuttle, although some of the bug fixes, technical depth, was addressed in the meantime. Most likely, the only changes that we are expecting or problems will be coming from the fact of improper usage of the past version of Customize. We do hope that a broader community will be able to provide us with feedback as well as provide some suggestions how to better improve this situation in the future. The next important development that is happening in the 6CLI community is observability. A couple months ago or even years, Phil created a proposal to send KubeCuttle commands as headers through requests. This way we would be able to identify which commands are being used the most, how people are using KubeCuttle, and on top of that ensure that the people are using the latest possible version. Sean spent a couple of weeks this year and put together a alpha implementation of this functionality. Currently, if you invoke KubeCuttle with a specific flag, with a specific environment variable, the commands that you are executing along with the flags are being passed through headers to the API server where we can then investigate what's going on and how clients or users are using KubeCuttle. We hope that this will allow us to improve KubeCuttle and the user experience in the upcoming months. The feature is still alpha so you have to explicitly up in. As I mentioned before, there's a KubeCuttle underscore command underscore headers environment variable that you need to set to true to enable this functionality. Sean will most likely will be working on this functionality over the next couple of months. If you're interested in working on this, feel free to reach out to Sean and ask him for work to be done as well as suggestions so that we can improve this situation. One last mention that I wanted to include here is a change coming from Paco who created a default container annotation. This way, the commands were the commands such as exec, logs, and similar that are working with multiple containers in a pod can pick a default container. Normally, the default container is always the first one in the YAML file, but if you want to explicitly state which default container a command should pick, you can do so by annotating your particular pod with a kube control that Kubernetes.io slash default container annotation. This way, when you invoke either logs or exec, you'll get information directly from the default container. Finally, I wanted to make a shout out to Zao and a bunch of other people that gather around a tab that we had, which was about removing generators from kube cuddle create commands. This spans several months or even releases if I'm correct. And thanks to the hard work of the community and Zao who took the leadership in driving this feature forward, we are able to say that we're about 95% there. Most of the generators have been removed and the code in kube cuddle create commands is much more tested and much more readable. So big thanks to all that are involved in this effort. At this point in time, I would like to focus on the future of kube 6 CLI. There is many things that we would like to work on, but there's only so few of us. If you're interested in working on any of the features that I'm going to talk about, feel free to reach out to us. One of such developments that we would like to undertake in the upcoming months is the return code normalization. Currently, kube control only provides two return codes in their commands. There's a zero and non-zero exit codes. If you're familiar with many of the Linux CLIs, you are aware that the commands are returning different error codes depending on what the situation was. We would like to be able, and there were many requests from the community, that the kube cuddle commands subcommands are returning further information about what went wrong, not only through a description, but also through an error code. That helps with scripting and including a kube cuddle and further automation. So Riccardo put together a enhancement. We're looking for interested contributors who will put together a proposal, walk through all the existing commands and figure out what is the possible outcomes that we could get, what are the possible return codes that we could have from the kube cuddle command. I have several suggestions. I'm pretty sure that others in the community have suggestions as well. This topic was discussed several times during our past meetings, and I know that there will be many opinions when developing this topic. If you're interested in, feel free to reach out to us, join one of our 6 CLI calls, and talk to us about your proposal. We would like to hear from you, and we would like to be able to work on this further. There is one another development that I would like to bring to your attention. Over the past couple of releases, we've been consistently trying to unify how the commands work. You probably are familiar with the option structure and the flow, which includes three methods, complete, validate, and run. If not, I recommend to you to watch our previous recordings or our meetings where we describe how those three methods provide a consistent flow across all of the commands. We've managed to get to 95, maybe 99% of the commands transformed into this flow, but we're not there yet. We're slowly addressing the remaining commands, but at this point in time, we would like to decouple the current business logic of every single kubectl command from the Cobra. Cobra library is the library that we are using for providing the entire command line interface. Unfortunately, the decision that we've taken in the past caused that the Cobra library is very tightly coupled with every single command. Like I've mentioned before, the previous efforts simplified commands and unified how they work. Currently, we want to go one step further and decouple them so that other consumers of kubectl or parts of kubectl can easily get the same behavior that the kubectl provides, especially that there was a lot of requests for moving certain kubectl functionality to the server, which is not always possible. So we're hoping that with the help of the community, we will be able again to address those issues. Sean volunteered to create a template, which basically means creating a PR showing how this should be addressed. As soon as the template is available, we are more than welcome to see PRs from other people in the community, even new contributors addressing and solving this problem. We're hoping that this will even more allow reuse of kubectl functionality across the community. This is basically all I have prepared for you today. I encourage you again to join our 6-year line bi-weekly meetings and our monthly box crops. The latter are very good for newcomers as well, because during our box crops, we go through issues and pull requests, and we allow newcomers to pick a very easy task to work on. Our bi-weekly meetings are very good place to raise issues about feature requests, plug interesting kubectl plugins, or in general about your feedback about kubectl or any of our sub-projects. We are more than happy and welcome any feedback and any suggestions, either through our 6-year line Slack channel or our mailing group. Thank you very much for your time. Have a great of the rest of the KubeCon.