 So what is the problem that we're trying to solve? We heard pretty loudly from the community that the CLI confines users to basically the feature sets that we decided to deliver. And we heard that that confinement didn't sit well with people. Basically, we tried to expose the APIs, expose functionality of the APIs in commands. So there's a lot of things you can do with the CLI that were just out of scope for what our teams truttered to deliver. So we came up with plugins. The main thing that we wanted to make sure we did is make the command line extensible. If we didn't do that, we pretty much failed. There'd be no reason for plugins. The second thing we wanted to do is make sure that plugins acted and interacted exactly like core CLI commands do today. So that there was a seamless interaction between the two. And then the third thing we wanted to make sure that we did was make plugins discoverable and installable natively within the CLI. So as we were going through that conversation amongst ourselves, what it is that we wanted to do, I remembered that we incepted on plugins. We had an epic in our tracker. And in that, we took notes about our inception. The goals and the scope are an interesting thing to revisit. The goals we had internally, those are the things for the team. You guys don't care that we wanted to have a shippable MVP for November 1. But the scope is really interesting. It's the thing that we call the four things. It's kind of the mantra for plugins. The first one is that plugins are executed by typing CF, space, and then the command name, the plugin name. It's exactly the way that the core CLI works today. The second one is that a plugin author or developer could write help. And that help, help. That's good. Did I do that with a clicker or is that you guys? Anyway, that you could write help and that it would interact with the existing help structure for the CLI so that when you type CF help, help about plugins comes up as well as help about the existing CLI. The third thing is that plugins didn't exist in a vacuum on their own. That they could call core commands. And that core commands could be then a part of the functionality that plugin delivers. And then the last thing is that they can take arguments and flags exactly like the core commands do. So Jonathan? OK. So I'm going to talk briefly about the use cases for plugins. This is sort of the expected uses we were thinking of when we began developing them. So Greg mentioned that we're from disparate companies. We're an open source team. All the projects we work on are open source. So that was really what we personally had in mind when we began developing these. Now that's not to say that we didn't take into account private use cases. We also, every step of the way, as we were developing the architecture and infrastructure that we're using for plugins, we made sure to keep an eye to make these usable for enterprise cases. So if you want to provide functionality to your customers, you can use plugins to do that. Our main goal, as Greg mentioned, was to extend the CLI command set through a common API. So what this means is we're really looking to create functionality for the CLI beyond what the three people standing in front of you can do in our day jobs. The CLI, as it continues to grow, as Cloud Foundry continues to grow, the things people are going to need the CLI to do for them is going to grow and grow and grow. And the three of us cannot really keep up with that need. So the hope is that by allowing users to extend the CLI beyond the pre-existing API, that not only will they create things for their own uses, but that the community will collaborate amongst themselves and continue to grow, rather than just collaborating sort of with us, the mainline CLI team that work together. No? OK, so just some brief examples of the sort of plug-ins we've seen in the community so far. The first use case is sort of something we've labeled sort of ephemeral plug-ins under our own work on the CLI team itself. We've encountered numerous things which are use cases that are sort of timeboxed explicitly. For instance, Diego Beta, so for those of you who aren't familiar with what Diego is, Diego is the next generation back-end for Cloud Foundry. It's currently being in development. It's not quite ready for primetime just yet. But it's under work. You can go and download it and use it today. And so there are certain features that Diego supports that the mainline back-end to Cloud Foundry currently doesn't. And some of our users expressed a desire to be able to use the CLI to interact with Diego. That's great. There's a couple problems with that though. We didn't want to include Diego commands in the regular CLI because they might get confused users who don't know what Diego is. If they use them targeting a normal Cloud Foundry, strange things might happen, and confuse their users. So this was a perfect use case for us to write a plug-in because now we have a plug-in called Diego Beta. It contains all of the subsets of features that are unique to Diego at this point in time. And if you want, you can go download it in one place, just one plug-in. And it comes with roughly a dozen commands at this point. And it's all neatly contained nicely in one place. And then when Diego becomes the de facto back-end for Cloud Foundry, we can just merge that functionality into the mainline CLI. CF AppStackChanger. So about a month ago now Ubuntu, or canonical I should say, Sunset support for Ubuntu Lucid. And many of the back-ends on Cloud Foundry, the DEAs, were using Lucid. And so we had a need to migrate all of these back-ends to the trustee so that security features and such still get updated. So this is the sort of thing that someone's only ever going to need to do this once. Once it's upgraded to trustee, they're not going to do it ever again. So this was, again, something that was very integral to our users needed to do this. It's a pretty serious security issue. But they're only ever going to need to do this once. So we wrote a plug-in that does it. Now the plug-in, run it once, uninstall it, forget about it. And then novel functionality. So this is sort of a different area. This is something that maybe is some area of functionality that the CLI isn't directly concerned with. But it's still useful to a user as a quality of life improvement or a use case like interacting with an app or a service directly, which we don't really concern ourselves with. So CLI recorder and opener too that Simon's actually going to show you. CLI recorder is actually written by our very own Simon Leong. It's a thing to record and replay macros so you can have subsets of commands that you can execute quickly in the CLI itself. Open is just a simple, you type cfopen in your app name, and it opens up a browser that goes directly to your app so you can see what's running on Cloud Foundry. And then I'm going to pass it to Simon, who's going to demo some plugins for you all. So when we, is that volume again here? So when we first set out to design the plugin architecture, we envision the plugins to allow a wide range of functionality enabled for the CLI. And some of the functionality might be easier to use, and some of them might be harder for the user to use. So it was our goal that a user should be able to get plugin commands help easily. So today, all the plugins command, they are listed in the CF help alongside with all the native command. And if we need additional help for any given command, all you have to do is to give the help track. For example, so can you guys see the font clearly? I can enlarge it a little bit. Bigger. Bigger. Good? Yep, OK. So this is a CF help menu. And all the install local, all the plugins that's installed locally is under this category right here. And if you want to look at any additional help for a particular command, for example, record, all you have to do is CF record and the help track. That's going to show you the detail usage and options for a command. And so looking at this, getting help for a plugin command is basically the same as getting help from a native command. And that's good for the user, because that's really not a new for you to learn. And going to the second goal, at the plugin design, we want user to be able to run a plugin just like running a native command. And let me show you what I mean. So let's start by listing what kind of local plugins I have installed in the system. So CF plugins will give you a list of plugins installed. And I've CI recorder, live stats, and open. So the recorder will record a set of CLI command, which you can play back in a later time. And the live stats, it shows you a live usage stats of any application in a browser. It's pretty neat, and I will show you in a bit. The open, like Jonathan said, is a very simple plugin. It's one of those plugins that made your life a little bit easier. It opens the application in the browser for you, so you don't have to manually type in the URL. To use it, it's simply just CF and then a command, and then application you want to open. I have an application in my environment called plugins. It returns a list of community shared plugins. And I'm going to use that as a sample. Plug in. So to use the CF, open plugins. And what it does, it opens a default route to my application in the browser. But in my case, my application actually has two routes bounded to it. So it just asks me which one to open. So I'll just pick the first one. And the browser opened the application, and I don't have to do anything that's pretty neat. This is a list of the available plugins in the community. And we have CR recorder here, and we have live stats. Live stats monitor the CPU and memory usage in a browser. And to use it, let me show you how to use it. Use the CF live stats, and then the application you want to monitor. And since we have plugin open in the browser, let's use that. Plugins. So what the plugin does is it runs a local server, which you can access in the browser. So let's copy the URL and open the browser to access a page. And that opens up a page with two graphs. The upper graphs show you the usage of the CPU, and the lower one shows you the usage of memory. So if I access application by reloading the page once, twice, I should see a spike in the CPU. So you see there's three lines. Actually, that's probably how other people are using it too. That's a good thing. So you see there's actually three lines in the graph, and that's only because the plugins is actually running on three different instances. So each line represents a single instance. So this is very neat. And as you can see, the plugin can give you functionality that native CLI can never give you. And the plugin developers, they can advantage of that. You can see there's more and more plugins coming available every single day. But all these plugin developers, they usually face one problem, a common problem they usually have to solve is how to get all these plugins to the end user. And that's the reason we make CLI repository. So with CLI plugin repository, it's a CLI server that the CLI can interact directly to browse and to install plugins. If you have a recent CLI version installed, you can go to the help of the CLI. So let's stop this, pull up the Help menu. And you can see under this category that there are commands that you can interact with the plugin server directly that you can add and remove plugin repo. And you can list what's locally installed on your computer. And if you want to look at what plugins are available in the plugin server, you can use the repo plugin commands. So let's look at what plugin repos are on my local system right now available. We can use the list plugin repo command, CF. As you can see, we have only a single repo called CF on my local computer. And this is actually the official CLI repo hosted by the CLI team. It contains all the repository. It contains all the plugins shared by the community. And all these plugins are open source. And if I choose to, I can add another repository to my local system. And to do that, I use the CF add plugin repo command. And this is usage. To use that, you have to supply the repo name and the URL. The repo name is pretty much anything you want to name it. It's pretty much for your own memory. And the URL is the web address to the repository. And I just happened to have a local development server, a creeper server that's running on my system. So I can use that as demonstration. So CF add repo. And then a name I would just call it local as a local server. And then the web address, which is my local computer. And I know it's running on port 3000. So it's added. And to verify, we can just use the list command to make sure it's already added. So now I have CF repo and I've local repo. And if I want to see what's available within these two I use the CF repo plugin command. So as you can see here, there's a long list of available plugins for the community repo. And in my local repo, there's only a single sample plugin. And if I want to install one of these plugins, I can use the install command CF install plugin. And with the install plugin command, you have a few options what to do. The first one, you can install with a plugin binary that you get from the plugin author. And another option is you can install the plugin by you can install with a URL to the plugin binary. And the third option is to install the plugin that is in our plugin repository. So to do that, I can just do CF install plugin and then the name of the plugin in the repository. For example, if I want to install targets, I will do a CF install plugin targets and then the name of the repository, which is CF. So what the CLI does right now is trying to determine what kind of operating system you're running and you will figure out which binary you should download and install in your local system. This process should be pretty fast because the plugin is actually not that big in size, but it really depends on our internet connection speed. So it should be anytime now. I think the binary is around in mac in size. If your process configured correctly, yes, it will. Oh, with the CLI one. No, currently this install process, it just go directly to URL. So it needs access to the URL directly. All right, I'll get to that. All right. So here I show that like the interaction between CLI and the repository. And the second goal of Cripper is it's ready to use. So Cripper is an open source project. And so if anyone, they just currently repository, it's ready to use out of the box. You can run it as a standalone executable or if you have a CF environment, Cripper is actually CF ready so you can just push to any environment that you have. With that, like CLI team, you can use Cripper to host plugins for the community so they can share all the open source community with each other. Or if you're an organization, you can probably use Cripper to host plugins that's specific to your environment and you can share all these plugins with your clients or customer. And other than being a production ready, Cripper is also an architectural reference. Cripper is both a number of REST API interface to interact with CLI. So anyone can easily implement your own version of Cripper by implementing the correct CLI signature. And with that, you can easily extend the Cripper's functionality, such as user authentication or any functionality that you wish to make. So here, I have showed the CLI interaction, the plugin usage and the distribution model. And here, I would like to pass back to Jonathan and he's gonna bring you through the rest of the topics. Okay, I would like to briefly mention what exactly is the CLI plugin. So we've shown what you can do with them and I would like to briefly touch on what exactly you have to write if you actually wanna make one. So currently, we only support one language for our plugins, which is Golang. That's what the CLI itself is written in. Just to keep things sort of simple as well, to take advantage of the particular strengths that Golang offers us. So for those not familiar with Golang, it's a language developed by Google in the past couple years that's sort of, it's target audiences thing, concurrent environments. We actually use it for a couple other things, such as the cross-compiled binary feature. So regardless of what OS or architecture that you develop on, Golang has the capability to produce binaries for any of the disparate architectures that CLI supports, which is currently 32 and 64-bit Windows, 32 and 64-bit Linux, as well as Darwin. So regardless of what you're writing your plugin on, you can distribute it to users on any of those five operating systems. The single executable file is another nice feature. So you've written your plugin, you've compiled it the end result rather than being a tar ball of stuff that your user has to download and put in the right places and then you have to have dependency set up. Is a single executable file that will execute anywhere regardless of if they don't have Go installed as long as you are running it on the right environment. So this kind of combines to create a highly portable, it's easy to distribute, it's easy to install. So the future, where are we going with plugins? We are currently working on a selection of new features, which we hope to get out in the near future. A couple of things we're working on, we're working on making the plugin API simpler to use so that it's easier to write plugins, it's easier to interact with the cod foundry from within your plugin. We're also working on instituting version checking within the CLI itself. So if your plugins depends on features that were more recently introduced, you can say I require at least CLI version X so that your user will see that they need to upgrade the CLI in order to use your plugin instead of the CLI exploding or something like that. I'm gonna briefly pass it off to Greg. He's gonna sort of wrap this up. I didn't remember that I was gonna wrap this up. So it says closing up, so I'm closing up. I guess we have a few minutes for questions. Are there any questions? Yes. Ah, that's a great question. The question is, where is a good place to go to get developer documentation? So the best way to do it is go to our CLI to help repository. And let me just show you that. And in here, if you go down, you will see plugin development. There's a link down there. I forgot what it's for development. All right here. So in a developing session, there's a link for developing guide on writing the CLI plugins here. So here you will find a link and also examples for plugins. The architecture, how to write a plugin. And also there's a link for you to go to the CLI plugin repository. There's examples too. Yeah, there's examples. So if you want to look at examples of the plugin, you go to... So all these are actually samples. You have basic plugin, how to make an interactive plugin, how to make a plugin with multi-pokemants. And if you want to do TDD, and that's a sample of how to develop using our fake CLI connection. And all the samples are here. Sorry, I've actually found that. So that's a work in progress. We are having, we're having this version of it now. Yeah, the thing is it's currently in develop, like rapid development, we're currently working on it. So it's expected to change in the next week. Oh, a month? Yeah. So that'll be coming and we will make sure we post a link in the repository. Good. Other questions? So the hope is that if you are writing something that's a subset of existing CLI commands that you would write as a plugin rather than a script. Now, if you're writing as a script just for your own personal use, that's probably fine. But the problem with scripts is that they're dependent on the architecture of the shell you're running it in. Maybe things you have set up local to your own environment. So if it's something that you're hoping to provide to someone other than yourself, they could be running on a Mac instead of Linux. They could, things could be wildly different. So the hope is that one of the main strengths of plug-ins, one of the main reasons you'd wanna use them is that they're extremely portable. That you know that when you give it to another person it's gonna execute the same way it does in your machine. And another thing for me at ESI, if you want to make sure your plugins that better put a user as a plugin you can take advantage of the plugin repository and you cannot use it with a script. Okay. Yeah. To avoid what? I'm sorry. Oh, sure. Namespace collision issues. So one thing that you can not do is name a plugin the same name as an existing core command. It simply will error out in creating that plugin. Other than that though, well I mean anytime that you try to create a plugin it checks against a pre-existing name whether it's a core command or another plugin. So it's almost first come, first serve but you definitely cannot override a core command. But yeah, beyond that we don't have or enforce any real guidelines. Yeah. In the back. I think it's Chris up there. Yeah. Put me in. Yeah. Sure, sure. That makes perfect sense. There'd be a point in time when we would definitely look at taking something into the core. Actually we saw the open plugin. There were stories in the backlog for that very exact same feature. We just got written as a plugin before we got to it, before we got it prioritized into the backlog. So I think there's a point in time and it would definitely be community driven, right? Something we could talk about in PMC. Something that can be talked about in the next generation of VCAP Dev. Is that CF Dev I think now? And I'm happy to entertain that. That just makes perfect sense. Michael? Yeah. I'm excited to keep it forward. Yeah. The notion of breaking out admin commands is definitely something that we're looking at right now in refactoring help, which gets us a little bit far for our field of plugins, but helps difficult because you traverse through so many commands that are for admin, and only if you're not admin, it's not very helpful. So that notion could extend itself definitely into some kind of decomposition. I'd love to find out what more people think about that and what is meaningful for various kinds of users. I think we're in our last minute. So we have probably time for one more question. Is that a good answer? Okay. Yeah. A plan to integrate with VC, VCO? Yeah, I don't know of a plan to tell you the truth. Let's talk about that offline and see what that would mean. Good? See, we're gonna probably have to wrap this up here. I would like to mention that not today, but tomorrow in the afternoon, we actually have open office hours. If you have questions about plugins or anything else to do with the CLI, feel free to drop by and we can have a chat. Yeah. Thank you guys. Thank you. Okay.