 Hi, this is Carol Barrett and Dean Troyer with another episode of the Newton Design series. Dean, why don't we go ahead and start out and introduce yourself to the crowd. My name's 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 number of specific things, but the thing that kept coming up over and over was support for specific projects. And Neutron is the big one. That's the one we've lacked for a long time and 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 to resolution with the team, Hawaii and 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 belonged in OpenStack Client directly and what they were gonna 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 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 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 wanna 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've been seeing 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 Ocata 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 Metaka, excuse me. 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 Okada. So I appreciate you joining us today. You're welcome. Bye-bye.