19:03:52 <dtroyer> #startmeeting OpenStackClient
19:03:53 <openstack> Meeting started Thu Jul  9 19:03:52 2015 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:56 <sigmavirus24> o/
19:03:57 <openstack> The meeting name has been set to 'openstackclient'
19:04:25 <dtroyer> again, no prepared agenda so we'll follow the usual sequence: reviews, bugs, open
19:06:11 <terrylhowe> https://review.openstack.org/#/c/181514/
19:06:36 <dtroyer> #topic reviews
19:06:58 <terrylhowe> I’d like to do some rework on shell.py in general, but I’d like to have the api versions work out of occ^^
19:07:20 <dtroyer> so, uh, I kept holding back on that because I thought I was going to have a refactor of the whole arg handling and I can't find the dang thing now
19:08:03 <dtroyer> I think I should stop holding things up and we'll do cleanups as we move along
19:08:39 <dtroyer> I am still concerned about a behaviour change and need to check that out yet
19:11:25 <terrylhowe> I think I’ve maintained your desired precendence there cli opt, env var, occ, default value
19:11:38 <terrylhowe> but definitely give it a test spin
19:12:21 <terrylhowe> I keep bumping into this https://review.openstack.org/#/c/181722/ and I want to put identity-api-version in my clouds.yaml and that doesn’t work
19:12:49 <terrylhowe> I’m doing v3 auth and identity-api-version defaults to 2
19:14:25 <dtroyer> yeah, that does need addressing
19:14:58 <dtroyer> and IIRC it shouldn't be too hard, just a matter of getting the auth bits sorted and separated from CRUD
19:15:20 <dtroyer> terrylhowe: how much of this changes significantly with the SDK change?
19:15:33 <dtroyer> ie, separating auth and identity crud?
19:16:00 <terrylhowe> well, the sdk does generalize the service catalog so it could be used for either version at least
19:16:33 <terrylhowe> auth is complete idenpendent of identity-api-version like it is in osc now
19:16:47 <dtroyer> good, I think thats what we wanted to do here too.  so with that coming, does it make sense to try to bring in that separation now or band-aid it until SDK switch?
19:17:17 <terrylhowe> band-aid it probably
19:17:38 <dtroyer> ok.  does 181722 fix what you are running in to?
19:17:52 <terrylhowe> I put the catalog list one on my list of things to look at more if I get around to it
19:18:06 <terrylhowe> Yeh, I think 181722 would be a good band aid
19:18:22 <dtroyer> ok, it isn't abandoned so looks like a rebase should revive it
19:18:28 * stevemar sneaks in
19:19:08 * dtroyer throws a wet rebase-review at stevemar
19:19:16 <stevemar> ewww
19:21:15 <dtroyer> any other reviews to highlight?
19:21:19 <dtroyer> I don't see anything else I have questions about for anyone…  terrylhowe's been cranking out the tests and those look good.  are they ready?
19:21:24 <stevemar> bah to 181722
19:22:13 <dtroyer> I know, right?
19:22:23 <dtroyer> #topic bugs
19:22:23 <terrylhowe> the functional tests are g2g except the network one which needs a tweak to the gate to add neutron
19:22:41 <dtroyer> stevemar did a bang-up job cleaning up the queue
19:22:52 * dtroyer recalls the wet rebase-review thrown earlier
19:23:02 <stevemar> woo hoo
19:23:05 <stevemar> no more wetness
19:24:07 <dtroyer> so https://bugs.launchpad.net/python-openstackclient/+bug/1472909
19:24:07 <openstack> Launchpad bug 1472909 in python-openstackclient ""role assignment list" fails if two users in different domains have the same name" [Undecided,New]
19:24:35 * stevemar adds the --help option to the agenda
19:25:43 <dtroyer> are we driving the API incorrectly there or is that not supposed to happen?
19:25:54 <stevemar> thats a good question
19:26:01 <stevemar> i havent had the time to look @ it yet
19:26:33 <dtroyer> at a glance it seems like we don't handle the return well
19:26:56 <stevemar> we do some funky stuff with the returned data - so yeah, i wouldn't be surprised if thats the case
19:28:43 <dtroyer> since stevemar brought it up, https://bugs.launchpad.net/python-openstackclient/+bug/1444983 is about the help situation.  Does what sean is looking at cover the current concerns are are there others?
19:28:43 <openstack> Launchpad bug 1444983 in python-openstackclient "-h and --help revert to top level help when used in a subcommand" [Medium,Confirmed] - Assigned to Sean Perry (sean-perry-a)
19:29:25 <dtroyer> if I read what we write in the ML thread, he wants -h to be context-sensitive, which I don't think we can do, ie be both global and command-specific
19:30:08 <stevemar> well -h and --help
19:30:13 <dtroyer> right
19:30:15 <stevemar> kinda treat it like --format for list
19:30:31 <dtroyer> even so, it is working like I think we intended
19:30:38 <dtroyer> so I'm intersted to see how he fixes it
19:31:32 <terrylhowe> yeh me too.  I’m not sure it is possible in any easy way
19:32:16 <dtroyer> any other bugs to mention?
19:33:14 <stevemar> it'll involve a lot of ciiff-ness
19:33:21 <stevemar> oh dtroyer if you could review the ssh one
19:33:26 <stevemar> https://review.openstack.org/#/c/199719/2
19:33:31 <stevemar> you know nova more than i do
19:33:32 <dtroyer> ok
19:34:04 <dtroyer> moving on...
19:34:09 <dtroyer> #topic open discussion
19:34:17 <dtroyer> so I do have one quick thing…
19:34:48 <dtroyer> I am having back surgery at the end of July and will be offline-ish for at least 3 weeks
19:35:59 <terrylhowe> no bueno
19:36:10 <dtroyer> you guys can self-run the meetings for a while?
19:37:01 <dtroyer> anything else?
19:37:50 <terrylhowe> https://review.openstack.org/#/c/199656/
19:38:09 <terrylhowe> how did you guys feel about removing —dhcp option from network list?
19:38:41 <terrylhowe> I was kind of thinking it was unlikely anyone was using it and it doesn’t list networks at all
19:38:57 <dtroyer> I think that's the right thing.   I recall there was a reason to leave it there for now even though it wasn't right
19:39:07 <dtroyer> but don't remember it so lets do it
19:40:14 <lhcheng> https://review.openstack.org/#/c/198506/
19:40:33 <lhcheng> a new option was added called "endpoint_type"
19:40:44 <lhcheng> and we're renaming to interface_type
19:41:10 <lhcheng> should we just name this as "interface"?
19:41:26 <stevemar> dtroyer: before you run off to back-surgery land, we should have another release
19:41:51 <dtroyer> agreed on the release
19:42:27 <lhcheng> stevemar: should we land the rename patch first before we release?
19:42:35 <dtroyer> on interface, I'm not sure interface-type makes sense.  I recall jamielennox having an opinion there that might sway us
19:42:52 <stevemar> lhcheng: that might be a bit much to take on before dtroyer leaves
19:42:55 <dtroyer> lhcheng: rename as in rename the package?
19:43:16 <lhcheng> dtroyer: rename the "endpoint_type" argument
19:43:18 <lhcheng> :)
19:43:40 <dtroyer> oh, yes, we must do that before a release if we are going to, otherwise back-comapt-land
19:43:47 <terrylhowe> I think lhcheng is just talking changing the option from os-interface-type to os-interface
19:44:18 <lhcheng> terrylhowe: yup
19:44:46 <lhcheng> dtroyer: this was the feedback from jamielennox
19:44:49 <lhcheng> https://review.openstack.org/#/c/185193/ - PS14
19:46:01 <terrylhowe> is public, private, admin an interface or interface-type?
19:46:04 <dtroyer> thanks lhcheng, that's what I thought I saw
19:46:37 <lhcheng> the attribute name in keystone is just "interface"
19:46:50 <dtroyer> this is one place we should follow the API specs rather than make up something, it is too specific
19:47:37 <stevemar> i think jamie has the most opinion on that one
19:48:42 <lhcheng> okay, will ask Jamie later when he's online
19:49:51 <dtroyer> anything else for today?
19:50:07 <stevemar> i'm okay
19:50:14 <stevemar> we had a lot of functional tests added
19:51:55 <dtroyer> ok then, if nothing else, thanks everyone!
19:52:11 <dtroyer> #endmeeting