19:04:50 #startmeeting openstackclient 19:04:51 Meeting started Thu Jun 25 19:04:50 2015 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:04:52 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:04:54 The meeting name has been set to 'openstackclient' 19:05:14 https://wiki.openstack.org/wiki/Meetings/OpenStackClient 19:05:17 not sure if we have an agenda, but lets go through the bugs and reviews 19:05:22 I don't see anything in the agenda 19:05:31 heyo 19:05:50 also courtesy pings for dhellmann briancurtin and sigmavirus24_awa 19:05:54 o/ 19:05:54 I didn't write an agenda…and got wrapped up in something else... 19:05:54 dtroyer: hey hey 19:06:26 could we do a quick review of the recent releases? 19:06:27 dtroyer: glad to have you back, i figured bugs and open reviews for now 19:06:31 sure 19:06:42 #topic review recent release 19:06:43 re re re 19:07:24 dhellmann: was kind enough to cut us a new release while you were away dtroyer 19:07:51 the reason for it was that jamie was itching to try out a v3 only devstack patch 19:08:06 good news is, it worked 19:08:18 had to make a change or two to ec2 credentials 19:08:34 and bump up the requirements (hence the change in version numbering) 19:08:44 https://launchpad.net/python-openstackclient/+milestone/1.5.0 19:08:49 #link https://launchpad.net/python-openstackclient/+milestone/1.5.0 19:09:10 the change in requirements was a new KSC version 19:09:22 ok, cool, thanks 19:09:55 dtroyer: that sufficient for you? 19:10:10 1.4.0 was out when you were here right? 19:10:48 no, it didn't make it before I left, but looks like it was basically what was in process 19:10:55 dtroyer: you might want to double check that we're not mucking up the release numbering ... 19:10:57 oh okay 19:11:08 1.4.0 was much bigger 19:11:11 what I looked at so far seemed right on 19:11:28 https://launchpad.net/python-openstackclient/+milestone/m12 19:12:17 i'm a bit confused about how we have a liberty and a trunk stream now, but whatever 19:12:24 i can take that up with you offline 19:12:56 any other questions about the recent release? 19:13:07 that's something Doug does that I also didn't quite grok, but since they're doing the releases now we'll follow along 19:13:25 no, that covers it, thanks. I was just wondering if I found all of the relevant bits 19:13:47 dtroyer: yeah, theres something different now, but i figured doug knew what he was doing :P 19:14:04 #topic open bugs and reviews 19:14:19 paste your links here! 19:16:33 https://review.openstack.org/123539 19:16:43 that one should be merge-able i think 19:17:15 ^^ add project parents and children to 'project show' 19:17:37 someone volunteered to add support for volume QoS https://review.openstack.org/194922 19:17:47 took a first pass at it, it's looking decent 19:19:28 and more interest from amey in adding volume support in general: https://review.openstack.org/187480 19:19:57 dtroyer, stevemar : sorry for the delay, distracted in another channel - the milestones are created by the release script using the series and version numbers, so that someone tracking "what is going on in liberty" can find that 19:20:21 if we want to predict work that will be done in a future version by number, we can pre-create the milestones using those numbers in the right series 19:20:46 the next-$SERIES milestone is renamed if present to the version being released when the script is run, if we only want to predict one release ahead 19:20:57 or we could just let the script target bugs and blueprints when they are done and released 19:21:11 the goal is to do as little of that by hand as the dev team wants 19:22:47 thanks for the explanation dhellmann. I've only been working one milestone ahead so next-$SERIES works for me 19:22:59 and that mostly for producing release notes 19:23:43 yep, and just make sure it's in the liberty series and everything should work fine 19:23:48 dtroyer: glad one of us understands it :P 19:24:41 terrylhowe also has a bunch of functional tests that need merging 19:25:11 https://review.openstack.org/#/c/188160/ has a bunch of dependencies to it, it would be nice to get that one through 19:26:42 terrylhowe: I plan to start working through those tomorrow 19:28:08 same 19:28:47 on to bugs 19:28:50 #topic bugs 19:29:02 we have a few new bugs that could use some triaging 19:29:07 https://bugs.launchpad.net/python-openstackclient/+bugs?orderby=-id&start=0 19:30:05 some just need to be updated with a comment saying they are being worked on 19:30:53 i'll do a few (like bug 1461817) 19:30:55 bug 1461817 in python-openstackclient "Existing image is updated when call image create" [Undecided,New] https://launchpad.net/bugs/1461817 19:31:34 anyway, do what you can, no crazy critical bugs atm 19:31:47 any other comments? 19:32:56 bueller 19:33:26 #topic anything else? 19:34:10 two things from me here, 1) the keystone team will likely be *removing* the keystone CLI in python-keystoneclient v2.0 19:34:40 more of an FYI and a yay - but expect comments/questions about using OSC 19:34:42 coolio 19:35:23 2) theres a project called heat-translator https://github.com/openstack/heat-translator/ which transforms Heat templates to and from another standard 19:35:42 they created a plugin for OSC 19:36:07 i've been helping them get it started, and got good feedback on the process 19:36:32 none of the calls require authN, so it's kinda overkill, but they like the uniformity of calling 'openstack' 19:36:58 I’m pretty much done what I wanted to do with functional tests, so hopefully I get chance to look at the plugin stuff some more soon 19:37:07 the only thing I'd worry about there is object-name collisions with other plugins down the road…otherwise the common interface is nice 19:37:46 oh, one thing... 19:37:50 oh, dtroyer, i pulled something together a few weeks ago for an osc-base 19:37:54 so plugins can use that 19:38:05 nice…cookiecutter? 19:38:13 of course 19:38:14 https://github.com/stevemart/osc-base 19:38:51 I smell a repo-add change in our future… 19:38:54 thanks 19:39:11 terrylhowe: took a look at it already, havent had the time to incorporate his suggestions, but i'd appreciate some more eyes on it nonetheless 19:39:52 dtroyer: your one more thing? 19:39:59 I talked to Pieter Kruithof today about doing a UX study, they seem to have some energy to look at CLI and API stuff. 19:40:34 sounds good to me 19:40:44 we're kicking around the sorts of things we would want to get feedback on, so if you think of something send along to me or raise it here in future meetings 19:41:02 the help system is still getting complaints 19:41:16 as is our defaulting to an interactive shell 19:41:38 help needs help, yes. 19:41:51 o/w i think folks are happy with the command and the amount of help text 19:41:57 I'm still resistant to changing the default shell as plenty of other commands do that, we're not an outlier by any means 19:42:08 buuuuut..... 19:42:41 I like the interactive shell, although I rarely use it 19:42:45 whenever i want to see the help and options for a command, i just type it with no args, (thats where my mind goes) 19:43:04 once I add a -0 option (think xargs) it'll be much more useful 19:43:23 so yeah, that's one thing to ask about 19:43:46 and the --help vs -h vs help vs ... 19:44:08 if you have a command in there, if you dont have a command... 19:44:23 there are different help outputs available, how should we let the user select them? 19:44:47 thats piets problem to solve :P 19:46:11 thats all from me! 19:47:06 nothing else here 19:47:45 last chance to speak up, otherwise i'm parking this bus 19:47:50 nother here either 19:48:01 thanks everyone! 19:48:05 #endmeeting