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