 Hello there, I'm Nick Mitchell from IBM Research. I'm going to tell you today about Kui. Kui is a part of the SIG CLI, as you can see in the lower right. It's open source, about for a few years. That's part of the SIG CLI. As you can maybe imagine, the goal of Kui is to bring enhancements to the terminal experience, to the CLI center of experience. So the premise of Kui is that we all love CLIs. In fact, as we get more and more expert, I think, as we all find with Kubernetes, we tend to gravitate away from the console experiences and towards the awesome Kui-Kau CLI. There's a lot of reasons to love it. All the reasons are CLIs generally. You can reverse ICERD, you can copy and paste commands and share them with colleagues very easily. You can script things, you can make parametric scripts that sort of encapsulate complex logic, arbitrarily complex logic. There's a lot of good reasons to love it. You can pipe together CLIs in really interesting ways. A lot of really cool stuff you can do with CLIs. But at the same time, they're pretty much stuck in the 70s. The ASCII art can be quite cool, but it's pretty much limited to a control character that was designed many decades ago. So that was a challenge that we were addressing with Kui. Can we bring those two worlds together, the world of design and graphics in the modern age, but without really spoiling the core essence and the reason why people love CLIs? So the basic Kui approach is that targets a number of aspects, I'll tell you about four today, of CLIs. You can make targeted enhancements, really focus enhancements to the CLI-based experience with the hopes by being so focused that we're not really spoiling. It's really a CLI centric, but focused with focus enhancement. So the first kind of enhancement we can provide is when you have a command, Kukut will get pods returned. Instead of just seeing an ASCII art table, we can present a graphical table with sortable columns and fun graphics in every row. Maybe I can have a delete button, for example. We can go crazy with all the kind of graphics we can do as long as we have a framework that lets us do that kind of interaction. Exit a command, get back a graphical table. So that's the first kind of targeted enhancement we can do with Kui. The second, a really important part of the Kugunata experience is managing context. Recently, these days, we have lots and lots of namespaces, maybe hundreds that we're managing. And as nice as things like OMI-ZSH are for providing us insight into the current context, we can make that better graphically by giving a richer wave of assembling and presenting those hundreds and hundreds of namespaces in a graphical, well-designed fashion. But once we have that graphical component, then I can click on one of the namespaces and have Kubernetes magic just switch the namespace for me without having to remember the long, complex commands. And that brings us to the next topic, this notion of powered-up hyperlinks. The notion of clicking in a terminal is pretty limited, right? I think terminals these days can recognize that you have a URL that was emitted by this CLI, and it can turn it into a clickable link. We'd like to generalize that so that instead of just being limited to URLs, and also instead of being limited to just having the click open up a web browser, we'd like to generalize both so I can click on a much more arbitrary set of things like you would in a browser, but also make it so that the clicks can do more than just opening up tabs, which is also the limitation that browsers have. So we can hopefully generalize both aspects of that. A good example of that is what I've covered in the fourth topic, this notion of really enriching the notion and fully integrating the notion of terminal splitting into the experience. So most terminals you can split the terminal. You can go to VS Code and click a little split button, and nice you can split your terminal into two or three separate side-by-side views. So you can do, you can get side-by-side views. You can see concurrent activity all simultaneously. You can do a lot of really cool stuff with splits. But there's no integration between the command execution and the splits, right? They're two separate concepts. And I think we'll show you in a second some examples of how we can bring those two together in a powerful way. So the agenda today, I'm going to sort of try to cover Kui in three different ways. The first is I'll give you a demo of how you can use Kui today, just to really make some of these abstract points more real. And Kui's been offered a few years. You can brew install Kui and use it right away. And so I'll give you a demo of that first. The second, I'd like to show you how that tool is based on a core framework for enhancing CLIs. The hope being that we can get a much more broad base of imaginative insight to bring it to bear for this really important task of enhancing CLIs. The last I'll cover briefly at the end is a really important and increasingly important part of the developer experience. And that's sharing, communication, repeatability. And terminals as nice as they are, I can copy and paste a command and share with somebody. But generally speaking, the units I need to transmit and communicate and make repeatable are not just these individual commands. In a normal terminal, the only way you can do that is by making a script. But I think as Python notebooks have shown us, there's a much better way, I think, much more modern way of communicating and sharing. I'll show you how we can, with a few minor changes to the core CLI experience, we can have notebooks at notebook like experience for communicating and sharing. Okay, first, let's get to the demo of Kui. So here's Kui, I did the brew install already, save you from that hassle. And I'm going to show you two ways to use Kui. The first is from a terminal replacement. So I downloaded Kui, your brew installed it, I got a double clickable application. Double click got it, and this came up. It has an icon, Kui it got down there in the dock. It's a normal macOS application, rather than Windows and Linux as well. So it's, but it's a terminal that does graphical stuff. So I do LS, I get instead of just plain old LS output, like I would here, I get, notice there's nothing clickable here. There's some color coding, which is cool. But it's not really, the hyperlinks are pretty limited. So you can see here, I can click. In this case, the LS controller and Kui decides to implant clicks as an LS of that sub directory. And I can, I can turn browsing around, I can click around on lots of different interesting things. I can click on some of the source files and I can get a source preview of the content of that file and so on. So that's the, that's sort of a simple way that we can enhance, we can enhance the experience of clicking around, different navigation of a directory hierarchy. We can do the same kinds of things for Kubernetes resources. So I did a K get pods, I can do a up arrow because I can wooden a terminal and K get deployed. Something unlike a terminal because now we have graphics, we can make these things a little richer. I can just edit the previous command and get namespaces or get my, I spelled it, or get my replica sets. I can go back to the question. So you can see in both cases and all these cases, I'm getting back a tabular response. Kui has a heuristic whether if their, if the number of table rows is small, defaults are presenting it as a, as a normal table. If the number of rows is high, the defaults are showing it as a, this kind of dense grid view. But I can also just choose to swap back to a normal table view if I want or swap back to grid. So this is the, the, the first stage, right? I've chosen a sub command, Kui got to get pods or Kui got to get deployments and we get a graphical table or graphical grid as a result. Second thing are the context management. So kind of like an Omi CSH, we get some indication of the current context and the current name space. But we can do these, we can have a graphical enhancement, a very selective graphical enhancement. So here's a popover where I can get a list of all my, all my namespaces. I can have some heuristics for distinguishing system from username spaces. You can use this component to do type at find open, open, shift, you know, and the component manage all this for us. I can switch between namespaces at a click of a button and switch back to default. And I can do the same thing for context. I can switch to another totally different cluster and I can do a K get pods there. And you can see I have a different set of pods, switch back to my first context, first cluster. We actually that command and I'm back to that first set of pods that I had previously. So that's the context management. I'm just doing kind of a world one tour of the Kui features. So now let's think about the more the richer hyperlinks, which are clicking and richer navigation navigations are really important part of managing Kubernetes resources. You're kind of doing a lot of wild goose chasing town town problems, for example. We've color coded these notice and if one of them are red, for example, because the pod was failing, it was a red square instead of a green square. The gray ones are for jobs that are already completed. So I can click on any one of these to drill down. And notice what happened to Kui split the terminal into automatically. So this integrated split sort of management is to come into play. And maybe I click on the wrong one. So I need to cycle through to do a little bit of a search, right? Find the right one. So notice what I'm doing. I'm clicking through a set of pods and every time I click, I get a new pod on the right. But I still get the second normal terminal. I get history of each one of those. Also notice that Kui does it makes the best effort to not hide the details of the underlying CLI commands. So while it's decorating it with this nice multi-tab view, kind of like what you might see in a graphical browser console, an OpenShift or Google Cloud or Amazon. We also see the underlying command. And I can change this command. Like I was changing commands previously. I want to change the name space or change the output to be something else. I can do all that. Because the command line is right there. So we're trying to keep the command line as integral to the experience as possible. So each one of these pods, now I can look at the details of it. So maybe I want to see the raw YAML. I can do that. Maybe I want to delete it. I can click on the button. I can delete the resource with a prompt. So we can do those kinds of enhancements. We can get a kukal exec into the pod. Like we would in a graphical console, but I'm doing this, you know, simultaneously. Unlike in a console where they've made a choice to have this kind of very modal experience. I can be logging into a bunch of pods simultaneously. So you can see I have some logs showing up. I have a terminal and into the pod. We have some primitive filtering capability to do row based filtering. And so that's the experience of drilling down from a table to a pod. But once I'm there, I'm drilling down from the pod to the logs or SSHing into the pod. I can also see related resources. Every pod runs in a node. So with a click of a button, I can see the node on which it's running. There's the node. I can look at the nodes YAML and so on. Pardon. Notice these logs have some ANSI coloring. So Kui takes care of that for free. I can also drill down to the replica set that manages that deployment. I can view to click down, drill down to the deployment that manages the replica set. And I can also see the events for any of these resources. I think these resources are all pretty old. So the events of all timed out, but you would see a table of events as well. This is Kui as a terminal replacement. All the same thing holds. If I wanted to use Kui as a Kukutl plugin. So I can do Kukutl, Kui get deploy or get pod and you do that to start with. And instead of ASCII, I get back a pop-up window in this case. You may see, notice the similarity to what we were seeing previously. It's just Kui. But instead of running in a full terminal replacement, it's running in this more pop-up kind of mode. But it has all the same features. I can click and navigate and drill down, get into the logs and so on. Because it's treated more as a pop-up, it's kind of run and done. When I'm done with this graphical exercise, I close the window and return. You don't want to look at deployments now. And just as a contrast to show what the ASCII art reminds you, what it might look like. This is the ASCII art for pods. So that's a pop-up mode. So that's Kui as a tool as it exists today. So underlying all that magic is a framework for enhancing CLI's in a much more general way. So I'll give you some insight into that now. The basic idea behind Kui is that it has these three main ways that we've already seen for extending. The first is you can listen for execution of sub-commands like Kui Kato Get Pods and completely override what that particular command returns to the user. I'll give you some examples of the kinds of options. You've seen some of them in tables, but there's a couple others. The second is more of a decorator pattern. So if you wanted, for example, add a tab to that multi-tab view that was showing for pods, maybe you want to have a custom log viewer. And Kui lets you specify a decorator. You don't have to override the command entirely. You just want to add a tab to the existing response. And Kui, you can do that. And you can be very selective. You can say, I want for any Kubernetes resource, I want just for pods, or I want just for pods with a certain label, for example. So you can be very selective about what kinds of resources you're decorating. And you can choose what the content of that tab is going to be. I'm in the very same kind of way. You could choose pretty flexibly what the command handler should return. And lastly, of course, you can have these context widgets to the experience. So the basic idea is that you would go to our template repository, click on the generate and get your clone, start the webpack watchers, run npm on open, you'll see a window like that. So we just show you quick examples of what that might be like. So I've already cloned and generated the template for you. Let's do the npm run open. There's the window that I promised. So a couple of things that we did here. First you can see on the bottom there we have a little cat and dog thing. So there's a context widget. It's very easy to do fun down there. Click on that. It executes a command. That's another command that we added there. We have hello dog, hello cat. And these are examples of simple commands that listen for a particular subtree execution. So hello cat, hello dog. And in this case, we're going to ask you. But of course, you can have a lot of other sophisticated options for, for returning fancy graphics. You can return a tabular model and get views like the grid I showed you previously or a sequence diagram. If your tabular data has a well-defined notion of start and end time for every row, you can get source links. I'll show you an example of that later. If I, for example, if I do a quick little apply dash F, it'd be nice to show the user the content of that source file so that they can, they can look at it without having to find that download, you know, go to the website. If you're doing a dash F on an HTTP source, you can return source code. They get syntax colored like a shot on the lower right. And of course you can turn that multi tab view. And all these cases, you can choose to have the content of the tab or the response for your command. And there'll just be a totally raw react component that's to be bespoke of your own design. So let me, let me give you a quick sense of, of going back to here of how we might do the decorator pattern then. So what I've done in this is I've done a decoration of pods. So I've added a cat tab. And as some, some gamma on it. I've also added a little dog button. When I click on the dog button, it actually exceeds the command. And you can see I've added a little badge there as well. So it's very easy with three lots of code. You can be adding these enhancements, these decorations for existing Kubernetes resources. The pod cat tab is pretty, the code is very, very straightforward. You write a little filter. You say when do, when should this, this decoration apply? We have a convenience method is pod that you can leverage. It's deploy is kubri source and so on. And then you specify what the content of that tab should be. In this case, we're using a utility routine that converts the JSON into YAML, the YAML text. And then that's what shows up here. So that's the decorator, the framework. Very quickly at the end, I want to talk through about how we can sort of bring Kui beyond being just a way to execute commands and have it as a way of capturing our experiences and communicating them in a much more notebook like fashion. So here's some screenshots of the kinds of notebooks that are, that we have in Kui. I think it looks pretty cool. We can see in all cases it's, it's all, it's all, it's a CLA-centric experience. You can have kukutl commands. Let me show you some of those in action. The real insight that, that we had for notebooks is that you only really need one or two things beyond what I've got in a notebook. First is you need some sort of commentary. So I can, I can mark down to the command X to copy that and I paste it up at the top. So now I have some introduction to this, to this notebook. Second is I need to save it to a file. And then you're done. Now you have a notebook. I'll show you some of our pre-recorded notebooks. So here's one of the ones I was showing you a screenshot of. You can see that Kui notices that when you, when you're replaying pre-recorded output, and tries to make clear to the user, this is not your kukutl get pod. This is pre-recorded output. You can see it's a little different with an errored out pod. But it's, it's, it's all other than that, it's just Kui. I'm running out of pre-recorded fashion. So that's Kui. I, yeah. So we welcome your, your contributions and welcome your questions.