 Hi, this is Heidi Joy-Truthway with the OpenStack Foundation, and we're with the Mitaka design sessions where we're speaking with Dean from OpenStack Client. So please tell us about yourself. My name is Dean Troyer, and last week actually marks six years that I've been working on the project that turned into OpenStack. I started at NASA on the NOVA, the Nebula project, which spawned NOVA. I've worked for a number of companies I am now with Intel, primarily focused on the OpenStack Client and DevStack work, and other Client side things. Tell us a little bit about OpenStack Client, please. OpenStack Client was born after the frustration I had of getting a single set of environment variables and configuration options into the, at the time, only five project clients that we had so that we would have the same authentication. And it just finally occurred to me that we needed one way of talking to them. They all had different command formats. Everything was just, from the user standpoint, a mess, having to know that it was Glantz that did an image, for example. You don't have to know that. You shouldn't have to know that. So we developed a little proof of concept and then formally proposed this at the San Francisco Summit, I think that was Essex. Anyway, and so that's been four years now, we've been off and running and trying to make all of the, I like to call them, you know, the layer zero, layer one services. It's essentially the original five plus the plugins that people are adding. Look like a single entity as much as possible. Great. Well, let's talk about the hot topics that came out of the Tokyo Design Summit now just about a week ago. What were some of the discussions and some of the conclusions you reached? One of the things we talked about the most was the help output and how it should act and behave. Everybody seems to have their own idea of what should happen when you type open stack help or open stack dash H. So we've still got a lot of work to do to sort that out and clean it up. The major problem is knowing what you can do and what you can't do. You have to authenticate and we shouldn't have to authenticate to get help. And so anyway, there's just a long list of things that we need to address and we're still sorting that out. So that's one of our goals for the next cycle. The other major topic of discussion that we had was around name spacing of our commands. OpenStack Client only has the five original projects that are in the repo. All of the other projects support is done as plugins. So if you install OpenStack Client and you want to talk to heat, you install Python Heat Client and it includes the plugin that OpenStack Client will see and now magically the heat commands are all operational. Unfortunately, some of the plugins have, they want to use the same resource name. We have multiple projects that use the word flavor, for example. Compute gets it because they used it first. But if you want to do a different kind of flavor, we're having to put additional words in. The problem of disambiguating that thing when commands collide between projects. And since they're plugins, we don't have any sort of way to enforce that easily. About the best we can do is detect the collision and then disable one of them. What did you identify as some of the user needs or problems that you're going to be solving in the metaka cycle? From a user standpoint, again, it's a lot to do with making the command set consistent. I like to say that's what the CNOSC stands for is consistent. Making the command set consistent and predictable. And with a big tent and the proliferation of projects, that's become a challenge. And a user, like I had said a minute ago, a user shouldn't have to know which project implements at least a certain type of commands. If you're using heat, you probably know that you're using heat. But just smoothing out that user experience. And we do plan on doing some user experience testing with that group. I've talked with Peter about this. And I hope we can get this worked into this cycle to actually get some feedback in a controlled manner other than just hey, we want this or we want that. What can we look forward to in metaka? Maybe your top three priorities for new features or enhancements of existing features. Hopefully the most user-visible new feature will simply be the addition of more sets of commands. I mean, the glaring thing missing right now is networking. We have the NOVA networking commands that NOVA implements, that the Compute API implements. We have nothing from Neutron yet, partially because we were waiting on the OpenStack SDK to implement that. And we had hoped to have that available to us quite a while ago already. And they're still working on a 1.0 release. That actually is the second major thing that I hope we're gonna have this cycle. Switch to using the OpenStack SDK for as much as possible rather than the individual project clients like Python, NOVA clients, for example. That will not necessarily be user-visible, but any user trying to install OpenStack clients should have a much better time. Because we're gonna drastically reduce the number of dependencies required to get it installed, especially on something like Windows. Right. And one of the ways we connect the dots between the projects is we talk about themes associated with development, such as scalability, resiliency, manageability, modularity, and interoperability. So tell us more about the theme or themes that you aim to achieve in Metaca. A lot of it, like I said, is the SDK transition is going to be large. And that's going to be a large internal change for us. Hopefully not user-visible or some improvements in places. Also with the addition of the new commands that will be supported. But the other theme that, and this came up a bit at the summit too, is in performance, OpenStack client takes about two seconds just to load on an average Mac laptop that I've been timing it on. And the place we see this most as developers is in DevStack. And trying to reduce the amount of time that it takes to load just to basically make it feel a lot snappier. You should be able to type OpenStack flavor list and not have to wait four seconds to get a response. Great. Is there anything else that you want to add? You don't like every project out there. I think we would love to have some more contributors. We seem to pick up a few new ones every summit. And especially on projects that are not, the newer projects that don't have, especially that don't have the legacy client issues, we can support them much easier, quicker, cleaner, that sort of thing. So getting involved with some of those newer projects is helpful. Well, thank you so much for joining us for these Mitaka design sessions. We really appreciate it. Welcome. Thank you for having me.