Kubernetes SIG CLI, 16 Dec 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Deep Dive: CLI SIG - Maciej Szulik & Juan Vallejo, Red Hat

Description

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects

Deep Dive: CLI SIG - Maciej Szulik & Juan Vallejo, Red Hat

The "deep dive" session will focus on the vision and strategy for the "kubectl" project. There have been multiple efforts to evolve "kubectl" to be more de-coupled and maintainable. We will report the progress of these efforts. We will leave some of the time for Q&A.

To learn more: https://sched.co/Grek

A

Welcome everyone. My name is machi Schulich I'm, together with Shawn over there chairs for the sick, CLI I'm, also holding the role of the six CLI technical lead along with Phil, with truck and.

B

I'm, a part of the six Eli and I'm here with nacho, to talk to you about plugins now to get started really quickly. How many of you have written a plug-in in the past? There we go. We have three, maybe four, how many of you have written plugins before cube Codel at 112. I am so sorry, we've broken you with current updates, but hopefully we'll get to introduce to you. The new mechanism briefly talk about what's new and what's better and hopefully get you all indoctrinated into writing, plugins and there's this new powerful mechanism.

A

Okay, so to quickly bring us on the same page. What are plugins well plugins are nothing else like an extent, nothing more than just an extension to the cube. Cto we've seen that the entire kubernetes ecosystem is growing rapidly. We are able to extend any part of kubernetes to come up with the same options in the cube CTL. We created the plugins mechanism and the plugins mechanism. Actually, the initial one was created back in the spring of 2016 by a colleague of mine from Red Hat, Fabiano France.

A

Unfortunately, the initial version introduced in 1.7 kubernetes 1.7, was very simple and at the same time, it required plugin authors to write a Yama file describing how the plugin will be executed. What is its description and a lot of boilerplate? That was unnecessarily from our point of view as the cube CTL maintainer x'. It required us to have additional logic in place to be actually a to execute the plugin. That's why, over the couple next releases, we re-evaluated the same mechanism. We looked at the plugin mechanism available in git.

A

We looked at helm and couple other places and we figured out that we are going to change the mechanism. We are very sorry to all the authors that wrote plugins predating the new mechanism, because the majority of them will be in some way broken, but if they were a regular binary applications, there is a great chance that they will keep working the only good thing. Well, the probably the, but one of the good things of having the new plugin mechanism is the yama files, describing your plugins in the new architecture is not any more necessary.

A

So, like I said, we looked at different solutions. We looked at what other programs are using for applicability and we come up and focus on three major areas. One of them was usability. We wanted to have something that will be simple both for us to execute, as from the cube, CTO standpoint of view, as well as for the plugin authors, to easily create the plugins and eventually help them with with actually writing those plugins. We focus on discoverable discoverability, although that, initially the ideas that we had was mostly around the discoverability on the machine.

A

We also spent some time just recently, working on plugin index, plugin management and thanks to awesome work by augment and a couple folks from from Google team around managing plugins. There is one thing that I put a huge question mark next to which is extending or overriding the built-in commands.

A

This is a one of the discussions that our keep having around the possibility, whether we wanna support the ability to override the built-in commands to what extent how much we want to allow people to to change the built-in behavior. So if you're interested in come join us, we are more than happy to hear your opinions around the topic. So, like I said in 112, we introduced the new Mac new plug-in mechanism and just in 113 this mechanism, thanks to your all, wonderful support and feedback that we gathered.

A

We all agree that the man, the plug-in Mac, the new plug-in mechanism, is mature enough and we've graduated it to beta, so how to write a plug-in these days, it's actually very simple, literally any binary that will be living in a in your path, which prefix will be cube. Ctl dash is a plug-in for your for cube CTL.

A

We we got this idea from the gate subsystems it's working very well for them, there are some twerks and one we'll be talking about the naming conventions, because we diverged a little bit from what the original get-get mechanism has, but that's a separate thing.

A

Additionally, we introduced a library, so over the past couple months, we've spent a decent amount of time going through the entire cube CTL code base and we've extracted several components that we found useful and extracted them as a separate library which exists in the Cates repo, which is CLI runtime, the CLM runtime library provides functionalities to obtaining and managing restclient for reading configuration, for it also provides a set of calm common functions that we also use in the cube CTL itself, like I, said over the curse of the entire refactoring.

A

We've also managed to unify the experience across all of the commands that includes, for example, printing stacks before hand. There were some discrepancies between commands, meaning that different commands would be printing objects, kubernetes resources in non consistent way, while refactoring and extracting the functionality into a separate library. We actually went through all of their commands and ensured that every single commands works the exact same way along the way. We also extracted a set of helpers that we think might be useful for potential cube, CTL, plugin authors and too duck foot what we created.

A

We are actually the first consumers of the CLI runtime we as a cube CTL itself. So that's a very important thing: ok, ok,.

B

So we'll begin with the proposal which introduced the new design behind the plugin mechanism feel free to take a picture or we'll make a slide deck available, and you will be able to access that proposal. It details what we aim to do and what we aim to stray away from behind well behind the introduction of the new design.

B

So, as far as the naming structure goes for the new design, we essentially treat your plugin executable as basically through its file name. We, we assume that you know your plugin will implement its path based on the the file name of its executable. So what we mean by that is that, as you can see, with an executable in your path named coop cuddle food bar that executable will essentially be called by coop cuddle whenever the Caudle fubar command is executed in the command line for plugins that wish to implement commands with dashes in their names.

B

We've added the ability to essentially interpret underscores in the file name to map to dashes in a command line, command and yeah. Essentially, we hope that by having a simple naming structure and no other configuration files that writing plug-ins would be a breeze.

B

So the path is something we pretty much intensely look at when determining which executable will be called when a command is is executed in the command line. So, for example, given two executables in the command line, one called Codel foo and another called critical. True that exists somewhere else in the path we will disambiguate, which executable will be called based on whichever one appears first on your path.

B

So if the first location appears first, then that one will always take precedence and we will tell you which one takes precedence as well via a command that we've introduced as well called coop, Codel plug-in list, and it is available as of 1:12.

B

So what about executables that overshadow essentially other executables with shorter names? So, let's say, for example, you have two executables one's called coop Codel food dash bar and another called cuddle foo. Well in this case, which one would be called first, not really. We would probably think whichever one comes first, but in order to allow us to you know, provide plugin authors, the ability to implement commentary's using different plug-in executables.

B

We've made it so that we essentially in a greedy manner, always choose the longest filename first, so in in in this sense, coop Caudill whoo bar will always be executed and will always like precedence over cook caudal foo, even if coddled foo comes first in the command line. This also allows us to provide you with the ability in the future as much as said before, to potentially override or even extend existing coop coddled commands. We welcome your discussion in this topic.

B

We are actually currently having and will begin having future discussions on this matter as well, but we figured that having this design extensibility right right now would prove powerful in the future.

B

So some code examples, as you can see, we've taken this code snippet from a sample CLI plug-in available under the kubernetes org right now, so you go to kubernetes slash sample Eli plugin. It is a repo containing sample code that you can compile and run right now and use as a plug-in with coop cuddle. It's a simple.

B

As you know, a few lines of code, essentially the gist behind this whole, is we wish for the new plugin mechanism to promote any plugins and clients that are written to behave and feel the same way as existing coop cuddle commands.

B

So a few key imports that we see in the sample, sale, I plug-in if you inspect that repo are some client go tools such as client CMD, which allows you to manipulate our users cube config file. We see clients in the slash API, which provides API types that you can use to represent in this case could config information and we have some generic CLI options which are provided as part of the CLI runtime repo, which you can think of as a mini SDK.

B

To assist you in your plugins as much I mentioned, we aim to honor, essentially the the same, so the same structure and the same set of tools in NC L at runtime that we ourselves will use in coop cuddle. So if we're broken you're broken and vice-versa, so we am to keep this healthy at all times.

B

So the the main design pattern we've chosen for the CL Arrington repo consists of a simple struct containing a few fields which determine which flags are specific to, for example, in this case configuration so given a configuration struct of flags you're able to call a an add, Flags method which binds specific flags.

B

It essentially binds those flag values to its fields, and then you know once command line flags are parsed and the user has provided the flag values. You are then able to in your program ask of specific functionality from this flags struct. So in this case, you're able to once flags are bound.

B

As for raw coop config file data, and with that data you're able to manipulate it, you're able to save it right back, you're able to use it in your program and essentially you're able to do it in the same manner that we ourselves do in coop, cuddle.

A

Ok, the future I'm not gonna, focus only on the sick on the plugin mechanism, although probably you've noticed that one of the main discussions that we are having at the moment- and that is probably one of the ones that we want to have resolved by the time who will promote the plugin mechanism to a stable feature, is figuring out how much of the built-in commands, which built-in commands and to what point we want to allow plug-in authors to override there are so many concerns. There are so many discussions that we're having in our bi-weekly meetings.

A

If you're having your own opinion feel free to join us finance on slack, there will be a slack channel in the next slide. You can also find us during cube con and talk to us. Give us your opinions, we're very open to listening what people think what they want to do with cube CTO if you're having some problems, ideas, it's about the cube CTL itself feel free to either find me who, on there's Phil in the back. Actually he joined Sean is right over there.

A

We are spending a lot of effort currently to actually extract cube CTO so that that it's release cycles are not tied to the kubernetes cycles, so that we can actually move faster with the development cycles of the cube CTL shown as this close of actually extracting cube CTL.

A

If everything goes well, we will have cube CTL in a staging repo, which is like a mid step until we get to the separate repo within 114, and hopefully, 115 will be the first release where we will be working from the cube CTL repo, the current contents, that's the thing that we also need to solve if you're, using the current contents of the cube city. The repo talk to us find us we're very interested in why you're using it.

A

We need to have a closer look whatever currently exists within the cube CTL repo, because we need to figure out what to do with the functionality. There is whether the functionality that we currently have, either through CLI runtime or within the cube CTL itself, is able to fulfill your needs and so that we can almost entirely drop the functionality that is currently in the cube, CTO repo that exists these days other than that there's a lot of refactoring going on so I'm. Already.

A

Very sorry if you will be struggling with some of the refactorings over the next couple weeks, like I've mentioned before, we've gone through a major refactoring in the cube CTL repo for the past releases.

A

One of the reasons was we wanted to extract the cube CTL repo to a separate two separate repo we've managed to extract the CLI runtime to support not only us but also plugin authors. So all these smallest, which are somehow very, very big from one point of view, because we're touching literally every single pot file within the cube see tail tree. There are aiming to simplify both the user experience, as well as the developer experience.

A

If you go through any of the commands, these days, you'll probably notice that a lot of them are following a certain pattern where we like one said, we have a structure that maps to flax at the command desk and every single command follows a certain pattern where we complete the structure, validate the structure and run the actual command, we're very open to to folks helping us with this afford.

A

If you have some time, if you're interested in in participating in six CLI and actually making your hands hands dirty and working with it, we're very happy to have you have your own board and help us with these with these efforts. So that's probably most of it. Like I mentioned, we are on the kubernetes 6u light slack channel. If you want to find us all of us, are there you can either if you're? If you're very shy, you can directly find me under under Soltis ones.

A

Under his regular name, Sean is Sean as Philip is under regular F, P, wet rock I think I'm, the only one hiding behind the some cryptic name you can also yeah. Also also, we have a Google group.

A

The the volume of the emails is very low on that group, so you don't have to be afraid that it will be spamming. You a lot if you have any questions at this point in time, we're more than happy to answer you. If you're shy, I'll be I'll, be outside of the room in a couple of minutes. You can just talk to us. Thank you. Thank.

B