19:01:12 <dtroyer> #startmeeting openstackclient 19:01:13 <openstack> Meeting started Thu Feb 11 19:01:12 2016 UTC and is due to finish in 60 minutes. The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:17 <openstack> The meeting name has been set to 'openstackclient' 19:01:20 <dtroyer> anyone here today? 19:01:22 <stevemar> dtroyer: o/ 19:01:25 <rtheis> o/ 19:01:39 <MeganR> o/ 19:01:41 <MeganR> Hi, I would like to introduce Tom and Satheesh from the Walmart team! 19:01:43 <dtroyer> courtesy ping: dhellmann, terrylhowe, lhcheng, dstanek 19:02:04 <brad_behle> o/ 19:02:06 <dstanek> o/ 19:02:16 <dtroyer> Hi Tom and Satheesh! Say hi so we get your nicks 19:02:53 <tomjosekal> Hi All 19:02:54 <Satheesh> Hi All.. 19:03:08 <terrylhowe> o/ 19:03:30 <dtroyer> cool, a full house today! 19:03:48 <dtroyer> #topic cliff 19:04:00 <stevemar> great to have more people :) 19:04:07 <dtroyer> I wanted to give a quick update on where cliff is ATM... 19:04:17 <dhellmann> o/ 19:04:38 <dtroyer> release 1.16.0 broke some things due to a change in argparse's allow_abbrev value 19:05:05 <dtroyer> besides changes in other places like DevStack, we reverted the default change in https://review.openstack.org/278781 19:05:30 <dtroyer> and I just added a simple test in https://review.openstack.org/279229 19:06:18 <dtroyer> dhellmann: (I asked this in -release a few minutes ago)… so I am sure I understand semver, fixing a break like that is a point release, correct? 19:06:20 <dtroyer> ie 1.16.1 19:06:52 <dhellmann> dtroyer : right, if the release only includes bug fixes it could be a point release. there's already a 1.17 release request up with a feature, I think 19:07:07 <dhellmann> sorry, I've been on/off line today traveling so I didn't see your query earlier 19:07:09 <dtroyer> ok, I didn't look for that 19:07:15 <dtroyer> np 19:07:44 <dtroyer> I'll go look at the 1.17 review and make sure the revert is included 19:08:13 <dtroyer> anything else on cliff? 19:08:58 <dtroyer> #topic openstackclient reviews 19:09:28 <dtroyer> I am guessing someone wants to talk about Jamie's namespace spec… 19:09:34 <stevemar> dtroyer: sure :) 19:09:37 <dtroyer> https://review.openstack.org/278782 19:09:48 <dtroyer> I just added my comments about 30 min ago 19:10:31 <dtroyer> tl;dr, I still don't like global namespacing, but want to change the idea a bit to lessen the impact on users 19:11:11 <dtroyer> I left aliases out because I think they're a decent idea on their own and shouldn't get dragged into the namespace discussion 19:11:56 <stevemar> (back) 19:12:34 <stevemar> yeah, i was a bit confused about why aliases were brought into the discussion 19:12:47 <dtroyer> it was for compatability 19:13:19 <dtroyer> I'm not fond of the idea of shipping aliases in the box though 19:14:10 <stevemar> i don't like namespaces for the core services 19:14:26 <stevemar> i think we can creatively work around that 19:15:36 <dtroyer> honestly I think spending some time naming resources makes a lot of this problem manageable 19:15:51 <stevemar> the extensions/plugins can create namespaces if they want 19:15:54 <stevemar> yeah, i agree 19:16:03 <stevemar> that goes back to the ML thread that sdague talked about 19:16:20 <stevemar> we really need a central source of proejcts & resources 19:16:51 <dtroyer> are you talking about beyond what we do in OSC? 19:16:59 <dtroyer> like the proposed service-type registry? 19:19:04 <dtroyer> ok, I expected more on this one ;) 19:19:20 <dtroyer> any other reviews that need attention? 19:20:47 <stevemar> there are a few nice ones out there that add network functionality 19:21:01 <stevemar> tangchen and rtheis have been crushing it in that regard 19:21:31 <dtroyer> I do wish they were a bit more aggregated ;) but yes, good stuff 19:22:06 <stevemar> rtheis: i really liked your metaclass that handles the neutron and nova-net bits 19:22:17 <rtheis> stevemar: thanks 19:22:41 <rtheis> Things are a bit slow in check, so https://review.openstack.org/#/c/279058/ is still spinning 19:23:01 <rtheis> hopefully that can close soon to unblock function test issue 19:24:04 <dtroyer> heh, I had not seen that one yet 19:25:08 <dtroyer> ok, this is going quietly… 19:25:13 <dtroyer> #topic bugs 19:25:28 <dtroyer> how about bugs on anyone's mind? 19:25:32 <Satheesh> Openstack Client Version: openstack 2.1.0 openstack quota show <project-id> ==> shows the nova ram/cores and neutron secgroup quota openstack limits show --project <project-id> --absolute ==> limits showing-up with the nova ram/cores usage/limits properly but not giving the exact usage/limits of neutron secgroup 19:26:17 <Satheesh> Probably the above comment came in single-line.. for clarity sending it again.. 19:26:18 <Satheesh> Openstack Client Version: openstack 2.1.0 19:26:23 <Satheesh> openstack quota show <project-id> ==> shows the nova ram/cores and neutron secgroup quota 19:26:28 <Satheesh> openstack limits show --project <project-id> --absolute ==> limits showing-up with the nova ram/cores usage/limits properly but not giving the exact usage/limits of neutron secgroup 19:27:07 <dtroyer> Satheesh: is that from an open bug? 19:27:30 <rtheis> openstack limits doesn't talk to neutron 19:27:52 <Satheesh> not seen any bug for it.. will double-check once again.. if there's no bug - will file one for it.. 19:28:46 <Satheesh> ok.. openstack quota - was getting the data from neutron... can't we try similar way for limits also? 19:28:56 <dtroyer> ok. that is known, in that the common resources like quota and limits may not be wired up to Neutron yet as rthsaid 19:29:08 <dtroyer> yes, it should do that 19:29:41 <rtheis> searching for neutron limits API but not finding one... 19:30:17 <Satheesh> yes.. neutron we don't have absolute-limits API.. 19:31:48 <Satheesh> dtroyer, rtheis - can we file this as bug and work as an improvement for "openstack limits" ? 19:32:14 <dtroyer> yes, please do. 19:32:26 <stevemar> Satheesh: absolutely, do you know how to open bugs in launchpad? 19:32:39 <stevemar> (that wasn't meant as sarcasm) 19:32:46 <Satheesh> yes stevemar.. will open a bug for it today 19:32:53 <stevemar> awesome :) 19:33:05 * dtroyer throws stevemar a towel 19:33:24 <dtroyer> any other bugs? 19:33:36 <dtroyer> I do see a bunch for new commands that we generally track in blueprints... 19:34:06 <dtroyer> but, <shrug/> 19:34:15 <stevemar> dtroyer: i think tangchen and rtheis did that so they can more logically split things up 19:34:24 <rtheis> subnet pools was me ... I was following suit on other network stuff 19:34:45 <rtheis> dtroyer: would you prefer just to use neutron-client blueprint? 19:35:02 <dtroyer> that's fine. I find it easier to track command work with them all in one blueprint per resource 19:35:09 <dtroyer> but I'm not doing that much now, either 19:35:37 <stevemar> rtheis: whatever is easier for you 19:35:45 <dtroyer> in the beginning we did entire APIs in a single blueprint. for Network I don't think that's tenable, one per resource is where I would divide it 19:35:57 <dtroyer> but, yeah, whatever you can manage best 19:36:01 <rtheis> ok 19:36:47 <dtroyer> ok, if no other bugs… 19:36:54 <dtroyer> #topic open discussion 19:37:01 <dtroyer> what else is on our collective mind today? 19:37:43 <stevemar> we'll have to do one more release before we close shop for mitaka 19:38:12 <dtroyer> said another way, we'll probably designate the next release as the token stable/mitaka branch ;) 19:38:13 <rtheis> stevemar: do you have a timeline for this release 19:38:20 <stevemar> i'd love to get a view on what percentage of projects are using OSC (and only OSC) 19:38:58 <stevemar> rtheis: http://releases.openstack.org/mitaka/schedule.html Feb 29-March4 (Final release for client libraries) 19:39:09 <rtheis> stevemar: thanks 19:39:20 <stevemar> rtheis: we're normally the last, since we depend on releases of all the other libraries :) 19:39:37 <dtroyer> so there may actually be more than one release between now and then 19:39:48 <rtheis> ok 19:40:04 <stevemar> dtroyer: really? 19:40:06 <stevemar> why? 19:40:28 <dtroyer> why not? we decided to release more often last fall, then sat while the SDK work was completed 19:40:41 <dtroyer> I liked the idea of releasing every other week or so 19:40:44 <stevemar> dtroyer rtheis oh yeah -- thingee mentioned something earlier in the week, he's keen on getting cinder entirely moved over 19:40:57 <stevemar> dtroyer: i tried to keep that up :[ 19:41:27 <dtroyer> the other extreme was cliff, sep 2015-feb 2016 is a long time ;) 19:41:40 <thingee> yeah, I brought it up in the last cinder meeting. there is no one else stepping in to help me, yet 19:41:50 <dtroyer> re cinder… have they scoped the amount of work there yet? 19:42:10 <dtroyer> even just how many commands are missing or need new options? 19:42:19 * dtroyer is just curious 19:42:20 <thingee> dtroyer: not yet. That'll be the first thing I do 19:42:36 <dtroyer> cool 19:42:38 <stevemar> dtroyer: in the "deprecate all clis" x-project spec, someone had it listed out 19:42:56 * thingee checks 19:43:16 <thingee> http://specs.openstack.org/openstack/openstack-specs/specs/deprecate-cli.html 19:43:17 <stevemar> https://review.openstack.org/#/c/243348/ 19:43:17 <dtroyer> that's always going to be a moving target, but we can get close 19:43:30 <stevemar> Walter A. Boring IV (hemna) Jan 13 11:59 AM 19:44:00 <dtroyer> oh, right, in the comments 19:44:20 <thingee> stevemar: thanks 19:44:37 <stevemar> thingee: np 19:45:26 <dtroyer> anything else? 19:45:34 <rtheis> nothing else here 19:46:16 <stevemar> nada 19:47:05 <dtroyer> well alrighty then… 19:47:10 <dtroyer> thanks everyone! 19:47:23 <dtroyer> #endmeeting