 This is Carol Barrett and Dean Troyer with another episode of the Newton Design series. Dean, why don't you go ahead and start out and introduce yourself to the crowd. My name is Dean Troyer. I'm the PTL of the OpenStack Client Project and I've been around OpenStack for longer than I care to admit. We're glad to have you here today. Can you tell us a little bit about the OpenStack Client Project? OpenStack Client is an attempt to give OpenStack a consistent command line interface across all of the projects. Great. And in Austin recently, what were some of the hot topics that your team was working through? We had a we had a number of specific things but the thing that kept coming up over and over was support for specific for specific projects and Neutron is the big one that's the one we've lacked for a long time and our next real our last release just before the summit included a lot of Neutron commands. The next release hopefully this week end of May will include the bulk of the rest of the core Neutron commands. Oh that's great. So you were able to go ahead and work through what were the priorities on the support for Neutron and get resolution with the team all way in Austin. Right right and in fact and we got together with the Neutron guys a little bit and some of it was there trying to sort out what they what belonged in OpenStack Client directly and what they were going to implement as plugins and once they got that sorted out we could kind of decide where we needed to go next. Great. And can you say a few more things about what your top priorities are as you come into this cycle? One of the things that got a lot of talk in Austin also was the the load time. It turns out that we've discovered that OpenStack Client is responsible for between one to five minutes depending upon the job of the time it takes to run DevStack in our gate which is a significant amount of time and so we spent a lot of time looking at what we can do to to decrease the Python overhead that's involved in just getting every command started. The support of other APIs is big and one of the things that we're going to do is pull a chunk of OpenStack Client out into a standalone library so that it's more formally available for plugins to use. Right now plugins are using part of our code kind of informally and we want to make that a little bit more formal and the biggest thing that's going to enable is for standalone projects to be able to have standalone commands. Example of that would be ironic if you have an ironic installation that doesn't have much of the rest of OpenStack or any of it you want just the ironic commands and we'll be able to support them in creating a command that looks like OpenStack Client but just supports ironic. Well that's interesting I can see more and more conversation on the email list lately about standalone projects so it seems like an important feature to bring in around now. Yeah we've been hearing more about that. Are you familiar with the themes that we've used in the past to characterize the different capabilities that projects within the OpenStack community are putting in for the releases? Yes, yes I am. Oh great. Are there some key themes that you think will be important as you go through this next cycle for the OpenStack Client? There are a few. We don't necessarily fit in since we're a client side not a server side project with all of them but the one that stands out to me on top is user experience. That's the entire point of the project and in fact we've done a number of user experience studies. We did one in April, early April, and we did one at the summit in Austin with operators. People knowledgeable already about OpenStack to get feedback to find out what we're doing right, what we're doing wrong, that sort of thing. So that's really at the top of our list as far as the themes goes and that probably always will be at the top of our list. The other things that we focus on that fits into that pretty well is the modularity. OpenStack Client is expandable via plugins and a lot of the projects, we only support five projects in the repo directly. So everything else, for example, Trove and Ironic and everything else that's not one of the original, basically the original five, is supported via plugins and so those are the things that we're going to continue to make sure is better. Like I said, the library is going to help with the plugin support. Gotcha. And then as you look on to the Makata timeframe, it sounds like UX and modularity would continue to be high priorities? Yeah, I don't see much changing. Again, our release cycle is independent of the integrated releases. We do throw a stake in the sand saying, okay, we released Makata Metaka, excuse me, and this is what we had current at the time, but we aim to be able to support every supported release. Right now, we still support Kilo. So the things that we're looking at implementing will follow things that are new in a release. So some of the new stuff in Newton we should have ready to go, I hope, by the time we get to that release, but looking out past that, there's nothing specific to the client that we have on the radar yet. It's going to a lot be driven by the features that get implemented that we need to support. That makes sense. Alrighty. Well, thanks, Dean. I think that gives us a good sense of what you're going to focus on during the Newton and some leading edge as we start to think about Makata. So I appreciate you joining us today. You're welcome. Bye-bye.