We're jumping on the steam that was a ride sap it in buddy Hi Okay, that wasn't funny. I don't know what that is I have no idea what that is Okay, he's just healed ETC Yeah, this music is actually in the game for a cigar. Yeah, it happens No worries guys. No worries. It happens It happens And what's funny is that in the beginning you're like this fight's easy We just have to do this this of this and it's the only one we wiped off DC It's fun to be the easiest one It's the only one we wiped off. That's funny He's saying metal not none He's saying metal It's like almost a metal. They're saying all the things you should do with the metal protect the metal cherish the metal Somebody tell me how many times I have to do the singularity reactor. I did it three times Singularity reactor. I'm not sure why you would have to do that more than once Made a homeboy in the back when I got on my PC leather chat. All right, man Be back when I get back on my PC. Okay. I just had to read that again Man, what a fight. I mean if I put this up on YouTube or something should I just do like one big I Mean should I break it out? Some of them are kind of short I'm thinking about making one big video of all of them and putting like bookmarks so people can skip to different parts It's called the full Alexander run break them out in the tears Let's get that there Parts one two and three Was it Midas the first one was called something in the second one is called Midas Yes, I got there break it out in those parts Gordius Midas creator. Okay We feel even ratcheting clank with these freaking rails. I love it I guess I need to go in the exhaust vent Whoo, Alexander sound tries to give me such an F zero feel. I just kind of have that feel to it. I like it. I really do It fits the atmosphere The biggest buff comes with the ones with the multiple triangles.  Oh Okay, if you mark you with a tether and run away Didn't even know I died Big Ross Ray. Whoa. Welcome everybody to the stream Sorry, I was engulfed with the the Alex Thanks big Ross for the love.  Appreciate it Welcome everybody to the stream. Glad to see everybody here.  I'm doing it blind It's right. Oh, okay. Don't stand. Okay. Let's let's just not do that. Let's just not do that Let's just not do that Welcome man. Good luck. We channel. Thank you so much man. Appreciate it. That was that was pretty bad That was pretty bad Towards the end there man, I lost my concentration and just ran into every possible thing That was terrible man Okay, there's a wait Okay, that's that's something that really hurts that is something that really hurts I thought these were trash.  It's got a perfect specs and storage Hey It's an American company too. Hey What's this an airship? Crashing in snap The deuce what the deuce are you? Coming in a lot of transformers gun them transformer man. Voltron Power Rangers Captain Platton simple. I made it.   All right That's a lot of things I'll try my best to remember all that okay. I completely Okay This is completely messed that one up. I thought I was in the safe zone, but I wasn't Okay What what do oh? My gosh Did we just wipe? Okay, what's this? Oh really game Now the mud relax come on Okay, I won't be here anyway. Oh, that's that's he almost got it off He almost got it off Almost got the limit break off. All right. I kind of have a better idea what to do I'm sorry guys if I if I'm ruining this Man, I was I I gotta look look for the ability that he has I'm on Leviathan. I'm really liking this fight I'm liking the difficulty of it.  So I'm sorry for my reading chat here Focus mode engage now you go all the way to the edge Not just in the area where there's no color Oh Crap. Oh, that's not the ability. I just saw I'm confused We skipped. I don't even know what that means, but okay. No Mommy Thanks for the host I shouldn't have looked over there That are not allowed to look at chat to build this fight A little bit. Okay. No Okay, okay It wasn't fair what just happened. That wasn't fair I went to hide and then they put lasers everywhere And did I left again and then it was a boom on the right and then it was lasers on the left And I tried to go to the right side and then it was lasers on the left side and I couldn't do anything Oh, man That wasn't even fair man The healers are back up. So that's good Oh, man No This fight man That was just mean That was mean man That was mean Oh my gosh Okay, so we went through the time portal now And we followed this thing back It's alexander Within alexander I think we've got some exception going on here. We must go deeper. Let's all this Get mark move away from group if unmarked Stack on bosses, but Get the corners of bit White aoe lines. All right. I see a bunch of stuff that had nothing to do with the fight. All right. Let's go big white Big white aoe lines get to the corners of them So if you're not marked stack on his butt Y'all mark run away The deuce man I'm not marked That's the mark That's big alexander inside of alexander with baby alexander He's a sonic boom He's got wings alexander prime has wings Be froze All right, when he does that again, I'm moving out of the way. Are you supposed to know that's coming? Knights down Almost ran right into it. I forgot he was gonna do that. I just said I was gonna remember when he does that I didn't remember when he does that Okay, I don't know what this is. Oh Okay, um What am I supposed to do?    Alex doesn't like me guys Alex does not like the borna Oh my goodness.   What is going on man? It's just one death after the other I'm okay. I got I got marked again. He marked me again Why is he marked me every time? I don't do this. I'm doing it. I don't care At least I was trying to do it Didn't do anything Okay I just man Was just that was just that was that was a prime example of just always being in the wrong place at the wrong time Just always And not knowing the fight too. I just didn't know the fight That was crazy


Good afternoon. Good morning. Hopefully you're all awake, more than I am. My name's Dean Troyer. I'm a senior cloud software developer at Intel, and I'm responsible for this mess we call OpenStack Client. I'm Steve Martinelli. I'm currently the Keystone PTO and an OpenStack Client core. One of those things happened before the other. And I started to work on OpenStack Client just kind of in my spare time and just been working on it ever since 2012-ish. So a little bit pinch more about us. I'm a senior software developer at IBM, Keystone PTO, and been working on this since 2012, circa Grizzly. And Dean, same thing. Like I said, I started this. And one of your predecessors at Keystone is actually, I've told this story before, responsible for me pursuing this thing in the first place. I could get to blame Dolph for taking the plunge. And you're actually being a bit humble because you've been working on OpenStack since day 0 before it was called OpenStack. So that's pretty cool. Nova. Yeah. Yeah. Nova like 0, version 0. So the agenda for today is we're going to give a quick overview about OpenStack Client, the scope of what we handle, what's new in the newest 3.0 release, a few UX Commandments that we like to follow, the parity that OSC has with the other legacy clients, as I call them. Who is using it? How you can contribute to future clients. So do you want to do the quick hands experiment in this room? There's not many hands. We can count those. Yeah. Sure. All right. So who's actually heard of OSC or uses it? Oh, that's. We have a lot of experience in the room. Good deal. All right. A lot of people who hate us. No. But we don't have to explain what it is. That's true. So you guys all know that it is a command line client for OpenStack that provides a uniform set of commands for computer identity, image, network object storage, and block storage. Read the silly thing. Yeah. Basically, in simpler terms, we just, you know, there was a whole bunch of fragmented legacy CLIs. We just wanted to create a single one. So the scope of it, Dean? The stuff that's in the OSC repo is essentially what existed at the time I started. And then we added networking, quantum, neutron, when that became a thing. Although it's only been with the last release. We'll talk about this a little later. It's only been with the last release that we've got any substantial support for network API. I'm trying to think of how long it was. Almost two years ago, maybe, we added support for plug-ins to allow the other clients to tap into the OSC shell and be a part of it. And all you really need to do is install that plug-in, and OSC will pick it up and include it as if it was built in. So basically, when we talk about our ecosystem, you can picture it as this. Come on, there we go. I kind of picture it like that. So in the box is the blue box, no relation to the IBM product. So in the blue box, it's what you get when you install OSC. So you know, pip install OSC, you're going to get compute identity, volume, image, network, and object. And then if you want some of the other stuff, you can install the plug-ins. This is just the way we decided to architect it because the OSC team doesn't scale. There's only a few of us, and we can't all add support for all the existing commands. So we allowed each project team to be able to maintain their own commands in their own repos. That's actually a pretty good point because there's a little bit of history with that too. One of the reasons this didn't become an official thing a lot sooner was at the time the projects weren't willing to. They didn't want to let go of control of their client. And they were all doing things differently, which of course is part of the reason we're here. So maintaining the plug-ins in this way lets each client, and in addition to the scaling, it lets them control it. That also leads us to some of the plug-in clients having command structures that are different in subtle ways than the core projects. But if you want to install them, it's actually indicated on the previous step. So you install the client first, and then you'd install the other client. But we got some feedback on that. We're thinking about changing the way we install them. So look for that in the near future. So what's new in the 3.0? We just did the 3.0 release in August. I spent the summer rewriting the authentication flow. There's a, is that on here? It is. OCC is on here. There's a thing that exists now called OSClientConfig that manages a Clouds.yaml file for common clients. The Shade SDK uses it. I know some of the other info things use it. I don't know who else has picked it up. But it puts all of the Cloud authentication configuration things into a single file. The addition of that led to some nasty duplication and timing problems. And so we've totally rewritten that section of it.  Because the plugins were using OSC as a library to avoid having to rewrite some things. I mean, it totally makes sense. And so we pulled it out. And those two things together led to some significant restructuring internally. Hopefully none of that is user-visible. If it is, it's a bug. So the second and third bullets are not really user-visible, but they were a large restructuring of things under the hood that needed to happen. Just for making auth easier and allowing the plugins to be more scalable as well. But the first and the last point are actually some of the big user-facing items that we had. And the first one being networking commands. We never really had many networking commands, I think, just generically create network, which would create a Nova network for you. But Rich Tice over at IBM and a few other folks, along with the Neutron team, did a lot of work for this release. And there's a ton of fantastic networking support now for agents, network RBAC, port, subnet, fix and floating IPs and routers. It's just really great stuff. And it's actually really slick. It will still work if you have Neutron or NovaNet. It's kind of agnostic. It'll figure it out which one you're running. And it'll still create it depending on what you're running under the hood, Neutron or NovaNet. So really cool stuff there. For the things that both of them can do. Yeah, for the things that both of them can do. It'll obviously fail in things that NovaNet doesn't do. Yeah, if NovaNet doesn't do it, it'll fail. But with a nice proper error message saying, hey, running NovaNet, you can't do this. And for a bunch of the commands we've now support bulk deletion, we'll actually get more into that in a minute. So some of the command opens that UX Commandments. I thought this was a good one. I like that you added this. This is pretty slick. Yeah, I thought it was a good one. We need to formalize it a little more. Go for it. Number one, I shall always provide a multi-delete option. So whenever a new command comes in now, we now force the person contributing the command, if they're doing delete command, always provide multi-delete options. So if you think of all the legacy clients, they're always, you know, delete a single resource. But I don't know, I'm kind of lazy. I don't want to type that many things, that many different commands over and over. So just keep appending, appending, appending, and it'll delete. We should note that this does not do, and I don't think we want to do things like wildcards, which are serious footgun sorts of things. We're trying to be a little bit safe about it. Right. Yeah, and obviously for some things, it's a little bit different. I mean, for deleting many objects in a, or for deleting objects in a container, I think we have some particulars around there, even some of the identity stuff. It's going to assume you're gonna stain the same domain, not gonna delete different objects from different domains. But yeah, we thought it was pretty good, and we added it to a few commands, and then I saw someone on Twitter say, hey, why is this not in all the commands? And I'm like, oh well, I didn't know you liked it, but thanks, and we'll add it now. So we did it. Yeah, Twitter, great feedback mechanism, rather than filing bugs, of course. Yeah, number two, they'll show all those group operations logically, not by API. So just because a certain API set, you know, you have five different APIs available, doesn't mean you need to represent it to the user as five different things. So in this example over here, you'll see, you know, you can update a volume. So you give the volume that you want to update the name or ID, and then from there, you can update it with the name, description, whether it's bootable or not, bunch of the metadata properties, the state and the size. The Cinder CLI, I guess they like to follow what's done, you know, this kind of logical developer mindset is to do one CLI for every API. You know, I'm gonna set a bootable on my volume, I'm gonna set the metadata on my volume, Cinder Extend, Cinder Reset State, Cinder, I don't know what it was, the changed name, I actually couldn't find it. But, you know, it's just, why not one command? Well, and this is a little bit even more general than that, just the idea that we're trying to service the user, we're trying to make things easy for users to do, not do what the API did, what the REST API did, and it's been amazingly hard, hard to get developers writing commands here to buy into that. They tend to, once they see it and see how it works out in the end, they tend to do that. We still get a little bit of pushback here and there, because they feel like we should be representing the REST API directly. This is also probably the biggest point of... Contention? Not contention, but difficulty in migrating. If you want, like when we migrated DevStack, you know, to use OSC, it did things, and we had to actually think through some changes, not just do a, you know, we can't write a tool to do a search and replace to migrate. That's true. And this isn't picking on the sender team. I just use them as the example here, because we're literally migrating some of the sender commands over. Yeah, this is a recent example. What's next? Commandment number three, provide meaningful error messages. So I got a few there. Let's say the set option there. Many of the, so when you're doing a lot of set options like that, the previous one there, you want to provide which one actually failed, and which operation failed, how many of them failed. A lot of things are just providing the text of either the REST error message, the body, or a generic exception type thing. And this is still a work in progress. We're not done with this by any means, and a lot of it has to do with translating what we get back from the Python libraries. Yeah, and it's just a matter of, you know. But this is important, and that's why it's up here, is to put it in front of everybody, and developer-wise, and remind them this is important. Number four, down with pretty table, long live cliff. Sounds kind of weird. Well, pretty table was the tool that, you know, prints out the nice little well-structured table when you do a user list or a user show or user create. But oftentimes, you can see this in the old DevStack setup scripts there. What you were doing was, if you can see at the bottom there, what folks were doing were... Oh yeah, the parsing. Trying to parse pretty table output. You would do a grep, and then a get field number two, and get field was actually a function in DevStack that actually did a whole lot of more funkiness. Or, you know, you can see there was ock, slash, and then the name, slash print, slash dollar two, and kept going like that. Instead, you know, we built in native support for this in Cliff. I think Doug did that one, Hellman. Yeah. And that's right, that's... So all you have to do is say, all right, give me the column name, so you can see, in the first example there, say, hey, give me the ID, if you do dash f value, just print out the value there. So, when you're running that command, it's literally just, all right, user ID equals that command, and that's how you get your value instead of that mess down there at the bottom. This is one of the newer formats of machine parsable output that we have. We've had CSV, we've had from the start. We do JSON now. I don't know if it does YAML yet. It's actually excellent. But the value is just to get the single value thing. Yeah, so you were talking about JSON. Yes. So, rather than just pretty table, you can print things out into various formatters. So, if you specify dash f JSON, that should all be on one line. You'll see that it gets printed out as a list. Each element is in a ID and name. You're gonna get the keys, the column headers as the keys, and then the content as values. And you can do it as YAML or CSV. I wanna jump in here because we have a problem that we can't do with pretty table well. We do it badly right now. In things that have, it's basically highly structured output. You do a show, I don't know, let's pick show server that has multiple address values, or where you have a list inside of a list, above a list, nested things like that. Doing that in CSV or pretty much anything else, other than JSON and YAML is terrible. As Sean would say, it leads to a trail of tears. And so, we haven't fully finished doing this with JSON and YAML yet to allow you to actually get the data structure that's underlying, get the full thing, and be able to use it. Right now, we're doing some basic list formatting, and in some cases, I don't think we even try yet. This is one area that I would like to get some feedback on, regarding letting the pretty table output and the JSON output be different in that regard. Not just formatted different, but actually give you different information because of the limitations of the other formats. So, maybe later today or whatever in our session, I wanted to raise that as something to see, if people think the output should always be the same, then we need to figure out how to do the nested structures. Commandment number six is support both ID and name. A lot of the old legacy clients, you'll see that they always want an ID, or for the most part, ID is preferred. But in OSD, one of the first fundamental principles was always support ID and name where possible. And we have a generic find resource method, which we call every time we try to find any resource, and it tries to look it up by name, by ID, by something else, because each API is different. But yeah, generally, it should support, you know, when you're implementing a new command in OSD, it should support both name and ID lookup, where it can. I mean, sometimes I can have- As you said, it breaks down when you have things where name is not unique. Yeah, so for instance, in Cinder, you can have a volume foo and another volume foo, and it doesn't care, because the IDs are different.  We're not gonna guess in that case. Yeah, we don't bother guessing. I think we'll just return whatever the API returns. And if the API says, you know, be more specific, we'll return that. Oh no, the API sometimes will give you more than one.  Yeah, yeah. So if the service actually returns more, returns one, or the first one it finds, we'll return that. If it returns an error message, we'll return that too. And number seven, above all, be consistent with your terminology. So... I say this every time. That's what the C in OSC stands for. It's consistent. So again, use the term project, not tenant, since that's where all of OpenStack is going, because Keystone went that way initially. Use real words not for resources. Don't abbreviate. Don't put hyphens or underscores in there. Don't put CG group, or CG snapshot, or CG group. We have some places where this is still, we still use IP. Yeah. For address, which I think is acceptable. There are places, network is using QOS, rather than spelling it out. We've made the exception to that, in places where it's a very clear, I think everybody would be mad if we didn't, kind of case. There's other security group, we don't use SG. For example. Yeah, but yeah, you get a good point there. I don't really want to type out OpenStack, internet protocol. No, I don't. Create. Although we did put those in the right order now, it's fixed IP instead of IP fixed. And use properties, don't use metadata. That's a long history. I don't know if I want to go into that one, but various services, some call them properties, some call them metadata. We stuck with one, stuck with properties, and we're sticking to that. And we're still getting grief over that. Yeah. There's one other thing about the consistency that's not on here, probably because it doesn't boil down to a bullet point very well. But the consistency in command structure, and in what actually is a top level resource and what isn't. And this also kind of fits in with where we don't pair at the APIs directly. Some APIs present something as a resource as an object when a user will think of it as an attribute to another resource. And so we're actually breaking with the API to that extent at times to enforce that idea. That if it's really just a state of a resource, then we're gonna treat it that way rather than do exactly what the API does. They built the API because it has its own database table and it's a thing, it's a row and a database. Users don't care about that. Do you have an example? Volume transfer. And I don't think it's been released yet, but it's in master. Volume transfer request is a top level thing. I haven't told you this yet, but I had a discussion with thingy about that and he gave me the argument of why that's not consistent. And that's my great is the status of a volume and transfer should be the status of a volume. And so anyway, so I think that's gonna change. But that's the current example. That's actually the example we used in the user interface study that we did on Tuesday. I think that's it for the command. Okay, so parody with the legacy CLIs. We get this question a lot. It's like, hey, you know, I hear from the users, I wanna use OSC, but is everything there? For the most part, we'll try and recap that here. So for compute stuff, we're pretty good. There's some items that are listed as contrived items in Nova Client, but we don't include those yet just because extensions are automatically always there. But otherwise, I think for compute, we're pretty good. A lot of server actions are there and various other things. I think we're good. For identity, we have to be there because there's no more keys don't see a lie. I removed it. For image, pretty good for V1, for V2. We're still lacking. We're lacking. We don't do a V2 upload yet, a V2 create. Right. It's there, but it's because Glance is rewriting all that. We don't implement any of that. This is partially because the Glance team is going through their own issues. And if we tried to do everything logically in a random order, wouldn't work out well. So we always try and go after the big fish first. Go after the high value targets that a lot of people are gonna use. The commands that you use, 80% of the time, 90% of the time, not the other 10%. So we just haven't had feedback saying, hey, we have to have this image command. People really want networking commands, so that's what we focused on. No one's been screaming for V2 image CLI support yet. And sometimes that's a measure of how people are using it, even though image V2 has been around for a couple of years already. I know something about changing versions. A lot of people aren't using it. And that's, right, changing versions is hard. And OpenStack as a whole is learning that. I mean, Nova learned that lesson a while back and they've gone to the micro version route after trying to do V3. He's done V3, so. Yeah, and that's taken a long time, too. So I think that's part of the same problem with Glance. We're gonna be playing catch-up. The other thing that we're going to be doing with the catch-up is even in the cases of plugins where the project team is maintaining the command set and they're gonna be implementing kind of at the same time, new feature in the server, new feature in the CLI. It's still gonna lag a bit just because of the release cycle. Yeah, although actually that's not necessarily true. We may get it before a release. If something's implemented by Milestone 2 and it's in our master, since we don't release and you know what, we need to keep mentioning that too. We don't release based upon the, on the primary six-month release cycle. Whenever we feel like it. We have to pick a release to be the, you know, the Newton release is, what, 302? I don't remember. I think it's 302. 302, it didn't match up exactly. But you know, if we need to do a version four in December, we will. We're not planning that. Yeah, but otherwise we try and release, I think, one new version a month. I think we're already up to 330. Yes. So. Yes, we're trying to get back to, we did that for a while and then the summer, the rewrite over the summer just really, really messed that up. I don't see a reason why I wouldn't go back to that though. So, look for 340 soon. Anyway, go back to here. So networking commands. Kudos to Rich Tyson and the Neutron team for adding a whole bunch of that. Networking commands and he gave me some numbers here and say we're about 56% transitioned out of the 128 core commands. Have support for about 77 or so with work in progress patches for another 30. And of course, missing support for some of the more advanced stuff. So VPN as a service, load balancer as a service, firewall as a service. We should mention those are gonna be done as plugins. Yes. With Neutron, the line is roughly what is core Neutron API is what's gonna go into the box in OSC. The advanced services, everything else will be, excuse me, will be done as plugins. And object support, this is the basic support. Again, it's just been based on user feedback. No one's been hammering us for, hey, you need to add support for large objects. In general, just the user feedback's not there. So we're just gonna concentrate on other things. And one of the other things was, hey, you need to add volume support there. And we've actually done a pretty good job of that. Credit to the two guys in the front row over there who've been doing a bulk of the volume work. And so I think we're about 80% over to V1 and about less than that for V2. But as soon as we fill up the gap for V1, we'll be up to about 80 plus percent for V2. By the time they deprecate V1. All right, so who's using OSC? So which, aside from users, we hope users are using them. But otherwise, so Puppet uses OSC when bootstrapping and doing a whole bunch of other things. I know Bluebox, a lot of the guys at Bluebox were using it.   They were using the previously using the old legacy CLI. I think over a year ago, we moved them all over and then Triple O via Puppet, because Triple O uses Puppet, so as a result, Triple O also uses OSC. So there are some actual real projects out there using it and just some users using it now. Here are the glowing reviews. And this is from Zego, Thomas Gorman. Hope I'm saying that last thing correctly. For those of you who know Zego, for him to give glowing reviews like this, it's a pretty high praise. Egan's read there, there's a little link there at the bottom. Basically, he really loves the CSV output and it just makes life a whole lot easier. Another one was Boris42. Another guy who's very hard to please. And he left it very cryptic, the subject line over there. Part of that opens that client. I tried it and, amazing UX, great job everyone involved. Keep it up. This is the kind of stuff that the folks implementing it. You want to see it. You want to see the bug reports and you want to see this too. How can you contribute to opens that client? I've been talking a lot. Well, talk to us. I mean, the things, it's easy to say that the way to get involved is to start implementing commands, but there's more to it. And like most projects, we also have the documentation problem. The documentation, we're trying to require for everything new. We're trying to require at least a minimal reference documentation. Here's what the options are and here's what they do. And that's still very cryptic. It's not very user helpful. And in the study that we did this week, again, the most amount of typing in the comments from the participants was about help. The fact that some of it was there's too much help. I can't find what I want in that pipe, in that fire hose. And there's not enough help because I couldn't find what I was looking for. You know, that's always gonna happen. But the idea that some of the stuff just isn't there. We need to get a little bit more verbose and we need to have some more things like use cases, examples. And having real world stuff is definitely more useful than things that we're gonna make up. I mean, you know, I've spent more than, more years than I care to admit as an essay. And that's one of the reasons why this is a big deal for me is I have seen far too many bad CLIs.  We sit in those studies and I watch people do something and I never would have thought of doing it that way. You know, so it's always very eye-opening and for those who don't want to code, don't care about it, but still, you know, want to do something, that kind of stuff, even if it's not finished product level, it's, man, this example would have really helped me send it to us. We'll massage it and get it in. I think right now that's one of the biggest areas that we want help in, that we haven't been doing. I mean, we've known help was a problem for a long time. It's not just the built-in help, it's the documentation that goes with it. And the dev docs that we have, especially like with the networking commands. If you're not a networking person, you're not gonna know that to get a server on the internet, you have to have a port, you have to have a network, you have to have a subnet, it's Monty's rant about get me a network, which we can build that together, but there's still pieces to plug together. And we can fill in some of that gap by at least helping you connect some of those pieces. And just a point that I wanted to put out there was, if you're a PTL of a project, especially one of the core projects over there, NOAA Neutron Syndrome Lance, you know, just enforce the rule that if someone's adding a new CLI to the legacy CLI, make the contributor also propose it to OSC. This will help us from perpetually playing catch up. Even if they just propose the initial patch, it at least gives us a heads up. Hey, you know, there's this new thing in Cinder and you guys need to do it too. Here's the initial patch and then we can run with it. We can massage it as necessary. We can re-implement, just massage it in general and get it in. But if we don't even get that first patch or even a heads up about a new client, we're seeing it for the first time when we type in Cinder help and hey, what, there's new command there. Ah man, another one to catch up on. So- Yeah, there's far too many repos for us to go cruising through looking for new things. And yeah, I'm not gonna follow that. If we could just get a heads up and as a PTLA notice. And I've gotta say, this was more of a problem a year or two, even that recently than it has been now. We're getting the involvement, as you saw, just the list of plug-ins. People are aware of it and I think teams are getting that kind of feedback. How come this isn't supported in your plug-in yet? Yeah. And that's always helpful. To one extent, actually the users have been going to legacy CLI folks saying like, hey, why isn't this in OSC? I wanna use that one only. Why do I have to go back to the old one? Yeah, we do hear that a lot. That's how we find our gaps. Matt, read him in with the Nova PTL was actually the first one to actually enforce that rule of if you're doing a new Nova CLI command, has to be done in both spots. Nova CLI and OSC. If we could just have that, that'd help us out so much. Future plans. Yeah, future plans. One of the big things that's come up with the plug-ins is the inability of them to, I hesitate to use the word extend, but the inability of them to have any involvement with built-in commands. And the example Steve's got up here is quota. That one's gotten the most press. The quota command is not API specific, or the set of commands like quota show. It looks at the three, right? There's just three compute and volume network, right? The three that are built in that have quota support. But if I've got, I don't remember who was it that brought this up. There's a- Barbican. Barbican maybe? No, I wasn't Barbican. Anyway, for any plugin that has a quota to be able to hook into that like it should to make a consistent command set, we don't have that support yet. And so one of the things that's next high on my list anyway is to extend the plugin support to add hooks so that you can hook in and add quota support for another API and make it seamless to the user. The other one we got was handle more business logic. You know, if you're familiar, there's an open stack operator kind of group mailing list channel, all these things. Someone from the ops group actually made a command. It just does one thing. It's called OS purge. OS purge, you specify a tenant or a project, deletes everything about that project. All the networks related to it, all the volumes related to it, all the servers related to it. It recursively goes through looking for and deleting it. Yeah, it nukes everything. And they actually came to us and they're like, hey, can you put this in open stack client? Cause we're tired of maintaining our own thing. We want, you know, we want, we want to just use open stack line. That's it. And we said, sure, sounds like a good idea. Well, I said sure. I don't think you were sure. Oh no, I'm sure. I didn't know it existed until, I think it was only a couple of months ago. So, I didn't, I mean, I've been familiar with the idea. I didn't know somebody had done it. So that was good news and it's a nice contribution. We do have to talk about what the command's gonna look like though. Because there's no resource. Yeah. Project Verge I think. That's a good one. I've mentioned help, needing help. It's been on our list since at least Tokyo, to restructure how the help works. When you type, you know, open stack dash dash help, that's a fire hose of stuff and the commands listed may or may not be applicable to you because it doesn't authenticate to get a service catalog to find out if it's Novenette or Neutron or what you have permissions to do. And so it's, or the versions of the API supported, you're gonna get the default versions. What we wanna do is dash dash help should provide a summary of how to get to what you're looking for.  Or even a partial command. And so on, or the global options or whatever. We need to break that down and make it a little bit more accessible. That's finally floated near the top of the priority chart. And I should also say that we're gonna be talking about these priorities and stuff at our session at, what is it, 11-15? Yeah, the design sessions today and tomorrow. You wanna talk about the tokens? Yeah, just local caching of tokens. So, you know, it's, we can't really just use the session caching because, you know, it's a command, right? Yeah, at the beginning of the command, we authenticate you and we start the session and once the command exits, that's it. The context is lost.  There's no real need for this sort of repetition. You can catch the tokens. Yeah, for some amount of time. I mean, the token has an expiration time. It does. We know how long it's gonna live. And otherwise, there's also key ring integration, which Jamie and you keep bringing up. Those kind of fit together. Yeah, exactly. That's how you're gonna store the tokens in the key ring. The OSC live stuff. We did a first cut of what went into it and I think we're gonna think about some additional things to go in and move up the stack a little bit. Stuff that went there is the base level of, you know, the client manager and some of the common functions that all commands or most commands, you know, want available. It's the stuff that the plug-ins were really looking to use. We're thinking about a little bit higher up in the command stack. Some of the business logic, maybe some of the pieces of purge will go into OS plug-in if it turns out like looping over a series of things. Region name has been a topic in the last couple of weeks. I need to loop over all of the regions that I have and there's client caching issues with that right now. But some of that stuff may move into it and things a little bit higher up in the command chain in the structure. And the output column naming is also relatively new. We found a problem, we found the problem in the gate in DevStack where the column names that you get in a list command and I think it was one of the IP commands are different between Novenet and Neutron. And we've never had a really hard contract with output. We've been kind of loose with it and the column names may or may not be the same thing and of course we were bragging about our JSON and CSV and so on support. You need to be able to name those fields reliably to do that. And so this has now become another one of the things we're gonna talk about and flesh out a little bit more because I don't think you and I have talked about it much. We're going to do, we're going to need to think about how to map column names to keep them consistent and across as APIs change but also do the same thing we did with tenant and project. There are things, the same thing is named different things in different places like some resources have a display name, they don't have a name, things like that. So that's what that's all about. So I guess now main presentation is over and we'll take some questions and hopefully provide some answers if possible. Yeah, sure. Does anybody have a question? Anybody need some caffeine? Yes. Okay. So for me as a user, it's always difficult which CLI version matches best to the OpenStack version I'm using. So you're like versioning differently. You're using differently. I want to make sure I understand. Our releases versus the OpenStack release. Those versions, okay. Or is it API versions? You're at the current review. I go to GitHub release in Itaca so I'm picking the one before that. Related to that also concerning versioning. I think you switched in a micro version release, the default for Glance from v1 to v2 which is, for me as a user, very difficult, right? I mean you're switching a major API version in a micro version. Yeah. That really happened? I don't remember when it switched to default. OCC. Oh, okay. That one, yeah, that one happened because OCC is where that default was. Did I take the first part of the question? Yeah, go ahead. Okay, so you know how you were saying how, so there's two parts of this question. For those of you who didn't hear it, I'll just do with versioning. So the first part is just because your OpenStack that you're using is at the Metaka release and we released version 3.3.0 and Newton, you don't have to be limited to what was released in Metaka of OSC and Metaka to use it on the cloud. You could use OSC now in the Newton release, the latest one, 3.3.0, and it'll work all the way back to like a Kilo cloud probably. Well, Kilo's still supported. Our attempt is to support every officially supported OpenStack release, backwards compatible. You don't have to install this on the same system as the cloud, right? It's for remote management. So you can just install it anywhere. You can install it in your own virtual environment if you're using Python and it should work all the way back to hopefully Kilo Liberty even earlier if possible. Do you have a specific case that doesn't work? We test some of it, yes. Well, we can't test every combination but via the testing in the gate, much of it gets tested. And if you find a case that doesn't work, report it, it's a bug. Because yes, even master should work all the way back and I suspect we'd still work with most of Juno. It really is gonna depend upon how the servers or the services have changed their APIs. Yeah, if a service like Keystone or Nova changes their API, then we can't do much about that. The default thing bothers me though. We should override that. And yeah, the other one about API versioning, probably, that probably should have been a major release. If that causes user trouble like that, then that's good feedback. If we're changing the default, we should make that a major version release. So instead of 2.3, it should have been a 3.0. Good feedback, I like it. Also one way to deal with that is at clouds.yaml file. You can set your version, the API versions in there. Any other questions? We've got a minute, I think. Yes, how do we determine, let me rephrase this, how do we determine whether it's something lives in a plug-in or lives in the repo? Yeah? It's in the project repo. They fall under the project's governance. Most of them put them in their client. So Python dash project client is where the plug-ins will live. I think there's one or two that have a separate repo for the plug-in. Yeah, for the most part, if heat client is a plug-in for OSC. So you'll see the code for the heat client plug-in in the Python heat client repo. Was that your question? Okay, good. It's hard to hear. I think we're over. I think we're at time. All right, well thank you everyone. All right, cool.


Welcome to the SNAP. This is a segment where we answer frequently asked questions and provide helpful tips in a very rapid fire format. So let's get right into it. In today's episode of the SNAP, I'm going to be showing you some tips to get the most out of your M+. Some heating tips and general advice, so that way you can get the best tips possible. For these advanced heating tips with the M+, I recommend using the Honest Torch, which is a single torch with a pinpoint precision flame. It also has a clear fuel chamber and is easy to adjust the flame height. Now, part of using any DynaVap device is knowing how to control your heating temperatures. Let's start with the low temps and work our way up. And always remember, heat the tip for a tasty rip, heat the base to launch the space. For low temp heating, start by rotating your device and heat near the end of the cap by the letter D. This will help you get that flavorful, terpy hit that provides more heady effects. For higher temperatures, the key thing to remember is low and slow. Aim your flame on the V on the cap. This will result in longer heat up times, but provides you with a denser vapor and more potent extraction. It's great for those looking for a more couch lock body effect. 10 Minutes Later Next, I'll demonstrate a single heat cycle extraction, which is basically just clearing the bowl in one heat cycle. Now, while this is the most time consuming technique, it is also the most potent and rewarding for those looking for that kind of experience. Using the dimples on the M+, tip as a guide, aim the jet of your torch at the dimples and rotate. For clearing the tip in one go, it is important to keep your Dynavabs angle upright, as this helps provide an even extraction with less potential for hotspots of form. That's going to lead to combustion. Now, these tips are also applicable to the new titanium M's with some tweaks. As you can see in this split screen, a titanium tip heats up considerably faster than a stainless steel tip. Take note of this while you are heating your device and adjust your technique accordingly. If you find that the tip is heating up too fast, try backing the flame off a little bit further back or lower your flame height. Each Dynavab tip heats up differently and it may take some practice to get a better feel for the changes, but once you do get it right, you'll know it. You could just say everything clicks into place. Thank you for watching this episode of The Snap. I hope you now have a better understanding on how to get better performance from your M+, and you're getting those hits that you've been chasing after. If you found this video helpful, click the subscribe button and give us a like. If you like what you see, make sure that you check out the other videos on our YouTube channel.


They're at their own software code so they're really running on the base element components and the DCS team, the data center solutions team, sells them that. So we still sell storage in that, that's a very different model. That model is the guy owns his own software and he's just looking for hardware. The products that we sell generally to the, you know, the compelling equal logic products are the complete solution and for, you talked about these giant companies, there's only a handful of them because only a few people can do that. They have a huge, huge investment software. Is there any difficulty in sort of differentiating among the customer base between equal logic or compelling, you know, when do you lead with compelling, when do you lead with equal logic? Yeah. Well, yes, there's difficult. Okay. Thank you for your candor. Yeah. I think there is difficulty. I think most of the time it's because of the salesperson, I mean, either came from the compelling side of the equal logic side and they know that products very well and the products do overlap a bit and we're not ashamed of the overlap. We actually intended it for it to be there, but they overlap like if you pick a capacity point and a performance number, they're going to overlap a lot. But if you start asking the customer, well, you know, how are you going to manage this? Who's going to manage this? How many people do you have to manage it? Is this something that you want to ever scale and how big will it scale? You get the answer to those questions and it separates itself into two systems very quickly. Okay. Okay. Our sales team does know how to sort, if you will, ask the questions that define the customer. Yeah. And quite often the customer will look at a system and say, well, you know, I've had very large companies that I thought should have bought, let's say, compelling, and they'll say, no, no, no, I want this system to operate in this environment this way and as soon as they said that, I'll say, oh, that's equal logic. Yeah. So you just can't go by the size of the company. You can't go by whether they're going to put it in a data center or not. You have to actually understand their usage of it before you don't know how they're going to... So it's a pretty consultative sales model then. It's consultative. Sales guy can do the consulting. Our sales guys are pretty well-trained. They can go in and ask the 20 questions. If they need to, we have professional services. So we can come in and do like a half-day assessment and the professional service will definitely sort between these or compelling-like opportunities. They might even say these are power-volt opportunities. Yeah. Because you've got a third line there. Yeah. Right. So let's see. The power-volt line was based on some LSI technology, right? Is it still LSI or is it NetApp now? Yeah, I think it's... No, it stayed with LSI, right? No, no. Oh, you're part of that? Yeah. The MD3000 technology was based on the Ingenio LSI and is now residing with our good friends in NetApp. Your good friends. Yeah, okay. So how's that going? Well, they've confirmed for us. They tend to do the same technology advancements that LSI did. So for us, of course, we put it on our own hardware. So we basically buy a software license for them. So there's much more to it than just that one piece. But the software is pretty robust and the company is continuing to support everything we care about. So as long as they do that, we're pretty comfortable with it. It's not a problem for us. We buy Tate drives from IBM. And we still buy stuff from EMC. So Tate isn't dead? Tate isn't exactly dead. Mostly dead. There's a lot of frenemies out there. No. Yeah. Okay. Well, we'll talk to Tom Georgins and see what he's going to do with that OEM business and we'll get back to you on that. Let me know if there's anything different. I'm sure he's going to talk to you first before he talks about that. That's good. All right. So are you going to stay here for the rest of the conference? Oh, yeah. The reason I closed this is I'm the emcee every morning.  Let's hear one. I'm putting you on the spot. Let's do it. Okay. You know, I have a lot of software engineers working for me, right? You know how to tell the introverted ones from the extroverted ones? How? The introverted ones, when you ask them a question, they'll look at their shoes. You know how that is. Sure. The extroverted ones will look at your shoes. That was fun. Oh, gotcha. That's it. I like his arms. I like his arcs. Yeah. What else are you excited about at the conference itself? Well, I'm excited about all the interest in fluid. Yeah. I mean, that's a big theme here. And Dell has taken this. And we're the ones that create. I'm sure everybody's going to be talking about it here in a few months. But we're the ones that have advanced this concept. We were talking about highly automated intelligent infrastructure. And when we're acquired, a compelling, they basically had trademarked the fluid data architecture. And so we said that fits. And that's a good container, if you will. It's a good message to make that statement about. So the whole fluid data, it has crystallized our thinking. Instead of us thinking, well, what's the next microprocessor that's going to make this faster? Or how can we make thin provisioning a little thinner or a little faster? Instead of that, we're now kind of elevating up to the customer value set of what makes the whole system more efficient? What makes the whole system be able to behave like a customer's need to behave in a world where there's 35 zettabytes of data out there? How do you do that? And so I would suggest this whole concept has raised our game. And unlike most companies, we took our the thing that keeps us awake at night, fluid data. And we brought it to this conference. And we asked the customers here, what do you think? What does this do for you? And we're getting great feedback from them on what keeps them awake at night. And this is kind of a hallmark of Dell. It was a hallmark of equal logic. It was a hallmark of compelling. We get our best answers from our customers, who then turns out, by the way, actually buy the equipment because it's what they want. So that's pretty exciting. So when you feel yourself starting to get in a rut, I mean, people can typically feel that in terms of innovation, like you were talking about before, is it really the customers that bring you back? Yeah, I'd say it's a, you know, it's kind of a, there's a three-legged stool here. There's the customers. There's the technology, the industry itself, whether you're going to acquire the company or not. There's always the technologists out there. We can OEM from these companies. We can learn from these companies. So there's an enormous amount of technology evolving. And that's always kind of exciting, especially for the geek engineers. Totally. And then the third leg of this is the business models are having to change.  You want OEM. Oh, by the way, we brought you all new hardware. So it's another 100,000 to keep that feature going. One of the things that really excites me is we're changing that game. Dell is changing that game. None of our products have the licensing model that is, that we keep coming back to you to ring the doorbell and have you send us more money. We're actually changing that. And I will tell you, the customers love it. You talk to one of our customers. They love the technology. They love co-pilot. They love this. But you talk about our licensing model and the CIO puts his cell phone down and looks up. Because he understands what that means. Or the CFO, he does too. And so these things are breakthroughs. And that's always pretty jazzy. Somebody described Dell to me recently as sort of the IBM for the SMB. I like that. It was interesting analogy. One of the big components of IBM's ability to do what they do is their IBM Global Finance and the ability to make those sort of do that financial engineering. Is that an area of interest for Dell? Well, we have Dell financial services. So for the SMB, I'd say we're pretty good at that. And I'm not an expert at it, but I know we can do leasing. We can do pay as you go. We can pre-install equipment and turn it on when you're ready to accept it. So we've got some pretty innovative things there. So I hadn't ever thought of it. I don't necessarily like comparing myself to other companies. No, I understand that. I didn't do it. But you repeated it. I get what I repeated it. I may not repeat it anymore, but we are that go-to company for infrastructure for the SMB. Now the interesting thing about the SMB is they're not a bunch of name droppers. It's not like when you go to the enterprise and it's, well, I'm at this shop or I'm at that shop. The SMB is all about solving their problems at their price point quite often. They could care less how somebody else did it. They may not want to go out on a limb and buy something that is never been bought before, but they're certainly not, they're not lemmings. They're not following that. Certainly a lot of them did, because a lot of people bought Compellent and a lot of people bought Equalogic when they were small, right? Yeah, exactly. So they are willing to take a risk. Yeah, they really are, if you deliver real value. Exactly, and it has to be the value that they value. It has to be what they care about. Yeah, yeah. Value is a good point to leave it on. Well, we really appreciate your time. Thank you for stopping by and I'm gonna go watch some of your jokes. Do you wanna leave us with one more? No. Oh, no. I gotta save something. Okay. Well, thank you for coming. It was great to connect with you again, Cal. I appreciate it. Great to have you here with us. All right, thank you. All right. I'm gonna exit stage record.


What is your name? My name is Will. Will. Will? I have no idea what I'm going to say, but when I thought about coming up here, I felt my heartbeat rise, so that told me I needed to get up here. You're speaking out the sadhana of having to come into your body and to integrate into the physical. And after I found out who I am, there was a very good question as to whether my person would survive. And I can say that, fortunately, he did not. So now, I don't really have a person now. And it's great. And as far as the question goes, there's not much question. So now that that person, the ego-mind self, came to a close and has been left to go down the stream, the only personhood that I have any inspiration to associate with integrally is humanity itself. But it also seems that I may also be in a position where I'm not a specific soul at this time, and the awakening for me was that I am, in true essence, the world's soul. And perhaps we all are, and it's just shedding all the layers off the top that couldn't bring that realization. So that journey back to Earth was interesting. I know everybody asks questions, but for me it's more like an exploration of, there's not even exploration. It's just I'm excited to be in this life and I'm happy to be in your presence. So I have a, I have a question. So my question is that the framework of this satsang is a prashnotar satsang, right? Prashnotar meaning question and answer. So that's the framework we are given. Just like when there's a road, you know, it's something we can walk on or cycle on, but we can't sail on it because it's not water, it's a road. So in that sense, the framework here is a prashnotar framework.  I'm just trying to, I'm flowing with you in this. I was hoping a question would arise. Exactly. So the thing is that when we are in a framework which has a specific, let's say a given, which is prashnotar question and answer, then the discipline of that framework is to come and sit here and ask a question because that's the framework. So let's see if you can formulate a question. What I'm trying to do is to bring you into the... I would be glad because I was hoping a question would arise and... I think you can very easily formulate one. It doesn't matter what it is. The point is to keep the, to keep the discipline of the satsang. Absolutely. Okay. When there's no past and there's no future, there's no ego-self, what would be your advice moving forward to give the greatest opportunity to allow my energetic body to expand freely to the greatest benefit, to the greatest amount of people? There is a, a sort of a a movement out of your system towards serving, serving everyone, right? And that possibility to serve everyone will be given to you by life when you move into a state of surrender to a soul which you might have to conjure up for the moment.  This system has to concretely experience surrender and when it experiences surrender to... Let's call it the soul. You can shape it like a heart if you want to. When you, when you move into a state of surrender to this heart-shaped thing in there, which is your soul, then that serving of that will reflect itself in the opportunity to serve outside. Which is what, in your case, is the reintegration. The urge and the wish is there. So obviously there's something within you which wants it and wishes it. It could be the ego, it could be the impulse of the soul. We don't have to think about all that. The point is, does this system know an active surrender? You are actually enlightened and now you're reintegrating. So in the reintegration process, the purpose of life will emerge and it will emerge as you surrender to something. Not I am... Not I am that, but I am in surrender to that. That's the next... It's the enlightenment processes are over and now start the Self-realization processes. Which is when the body, or this thing which is here, will start to do the bidding of the truth. To serve is what this body wants to do. But it doesn't know how because it doesn't know surrender. Now the reintegration starts. Welcome. Thank you. It's pretty cool. Isn't it? I've done a lot of laughing, crying, and reasoning. It's been pretty cool. There won't be any laughing and crying because now there is work to be done. Okay, cool. All right. Thank you much. Appreciate it. You can put a dakshina if you want instead of all those thanks. I said you can put a dakshina instead of all those thanks or including all those thanks. It will be a nice reintegration action to undertake. You can say thank you for that as well. It's a very heartfelt suggestion for your well-being. I haven't said it to everybody else. In fact, I haven't said it to anyone, so... Thank you. Welcome. I wonder if you really...  Life will show you exactly where to serve the other because that's your longing. That's what now is to come. No? I thought you were going to take something from me. Aishmanbhava. It's a very, very... very interesting state to be in, in that state, of depersonalization and then gradually the reintegration and generally what happens is that this urge for service is very strong and it will only find its proper means of expression when the surrender to the soul takes over and the service to the soul starts. It's an amazing process and if you don't believe me, you can try it and see it really does work. Life will give you that field of action in which to serve and you don't even have to be an identity that is serving. It's just this, this is in service, you know? In service, in service and it's solid. There's no wavering. It just knows, you know, I have to serve, I have to serve, I have to serve. Yes, you first. No. There are some few in life. Namaskar. Namaskar, yes. Well, I mostly came up here. I want to thank you. I came to Rishikesh on this occasion because I knew that I was in a position to be integrating basically everything that you're speaking of speaks very directly to me because of the steps I've taken and basically merging a universal awareness consciousness into an individual body, this and... I just wanted to mention what you said about duality. The irony was pretty interesting that becoming aware of non-duality and then the physiological effects and after effects of that put me in a state where I was on one side of a duality, being aware of non-duality. It was interesting. And then this merging into the self has been great and I just wanted to thank you. Your impact has been great. What's your question? My question is, as I return now, my trip is winding down. I found the integration has taken hold very well and my question is what advice would you have as I return to my life, my kids, to make sure that this state or this beingness is solidified and it doesn't escape me or that I don't fall off the horse, I guess. So in your particular case, you've been someone who's flown all into space and been one with everything and enlightenment you've done the drill. You know what I mean? For you, integration and actual reintegration is not something that can happen overnight. One can even see it in your eyes, you know. It's a process that will take time because even though you have a very tough body, this, that and all, that doesn't say anything. The reintegration of awareness totally sitting into the very cellular, cellularity, let's say, of your system and your body is going to take some time. In order to hold that experience and to also keep it, you would have to, in your particular case, it would be advisable to keep a connect with this framework because it is here that you have received that impetus to actually reintegrate and to do so in a way that even your conceptual is able to describe precisely. So you would need to actually maintain that connect simply because you're one of those enlightened types, you know. Not everyone has had that misfortune. And I mean that it is a misfortune because it really, really does things to the body which is really not necessarily something everybody needs to end your. So you would need to maintain that connect and the ego has to allow you to do that. And I'm saying the connect with this framework here because it is that one place on the planet where this reintegration is being taught is understood and is solid.  Hopefully you don't sit on horses, but anyway. Not a good idea for somebody like you to do anyway, but figuratively speaking. So it's your decision. How do you want to maintain your connect over here and what are you ready to do for it? You can also not maintain it and see what happens and then reappear if you feel that is needed. It's up to you. But it's something very precise for somebody like you. There is no embroidery and icing and all. It's the batter. Thank you. Yeah, with me there's no gray areas. Not safe actually. Alright, thank you. Namaskaram. Namaskaram. Who is it? He, no? Yes. You. Yeah.