19:01:12 <dtroyer> #startmeeting OpenStackClient
19:01:12 <openstack> Meeting started Thu Oct  8 19:01:12 2015 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:16 <openstack> The meeting name has been set to 'openstackclient'
19:01:18 <dtroyer> anyone here?
19:01:21 <stevemar_> o/
19:01:24 <stevemar_> ahoy
19:01:25 <lhcheng> o/
19:01:36 <stevemar_> lhcheng: do you still have conflicts wiht this meeting?
19:01:59 <dtroyer> alarm ping: dhellmann, briancurtin, terrylhowe, sigmavirus24, dstanek
19:02:12 <sigmavirus24> o/
19:02:17 <lhcheng> stevemar_: yeah after 30 mins
19:02:50 <MeganR> o/
19:03:06 <stevemar_> lhcheng: ah okay
19:03:25 <stevemar_> MeganR: you're new, welcome!
19:03:33 <MeganR> Hi, thank you
19:03:57 <lhcheng> MeganR: o/
19:04:01 <stevemar_> dtroyer: whats on the agenda today boss
19:04:27 <dtroyer> I didn't make one, so lets let the review queue drive us for a few minutes
19:04:36 <dtroyer> or maybe start with:
19:04:39 <lhcheng> gate still failing?
19:04:43 <dtroyer> #topic gate status
19:04:49 <stevemar_> lhcheng: i put in something to fix it
19:05:04 <dtroyer> stevemar_'s fix merged, but I've seen anouther failure or two since then and haven't had a chance to check it out yet
19:05:26 <dtroyer> the rest of the rechecks are still running so it may be an actual problem
19:05:40 <stevemar_> that would be unfortunate
19:05:53 <dtroyer> stevemar_: this was due to the devstack default change, yes?
19:05:59 <stevemar_> dtroyer: i believe so
19:06:05 <stevemar_> the fall out wasn't so bad this time
19:06:14 <stevemar_> just shade and osc broke (that i know of)
19:06:28 <dtroyer> and was limited to our jobs, yes
19:06:31 <dtroyer> I think
19:07:09 <dtroyer> #topic stevemar_'s object store additions
19:07:21 <stevemar_> i'm sure something else might have broke, but i haven't heard yelling yet
19:07:25 <stevemar_> ohhh object store
19:07:26 <dtroyer> a bunch of those finally merged, delays mostly due to me.
19:07:35 <dtroyer> stevemar_: is that series complete?
19:07:38 <stevemar_> it's all good
19:07:42 <stevemar_> i think so
19:07:45 <stevemar_> oh, one more
19:07:54 <stevemar_> this is actually a good topic too
19:08:16 <stevemar_> deciding on how to show the metadata
19:08:23 <lhcheng> dtroyer: would love to see this included too: https://review.openstack.org/#/c/231847/
19:08:35 <stevemar_> do we leave the header as is, trim the X-Container-Meta
19:08:43 <stevemar_> or leave it as just "Meta x"
19:08:58 <stevemar_> so if we had property X=Y
19:09:05 <stevemar_> swiftclient shows:
19:09:12 <stevemar_> Meta X | Y
19:09:21 <dtroyer> I'd say we want to shoe exactly what the user supplied in the first place
19:09:24 <dtroyer> show
19:09:28 <stevemar_> we could do that, or:
19:09:30 <stevemar_> X | Y
19:09:44 <stevemar_> or the ugliest one, keep the header as is
19:09:51 <dtroyer> no no no
19:10:05 <stevemar_> you like X | Y eh
19:10:15 <dtroyer> is there something keeping us from producing output formatted like other properties?
19:10:28 <stevemar_> the issue with that is if someone decides to name is Bytes or something
19:10:39 <stevemar_> or one of the fields that is normally returned
19:10:53 <dtroyer> we have that problem elsewhere
19:10:59 <dtroyer> or ignore it elsewhere?
19:11:04 <stevemar_> i think that's why swftclient renames it to Meta X
19:11:33 <stevemar_> we actually dont have that problem else where
19:11:37 <dtroyer> I don't think I have the full picture then
19:11:56 <dtroyer> every other resource with —property does this
19:12:45 <stevemar_> it's all here: https://review.openstack.org/#/c/222471/7/openstackclient/api/object_store_v1.py
19:13:27 <dtroyer> so properties become top-level fields in the output?
19:13:37 <stevemar_> yes sir
19:13:43 <dtroyer> I don' tthink we do that anywhere else?
19:13:47 <stevemar_> right
19:13:56 <dtroyer> if we do we have the same problem
19:13:57 <stevemar_> we could set it to a new properties field
19:14:01 <stevemar_> but that's tricky...
19:14:26 <dtroyer> how so?
19:14:40 <stevemar_> actually, nvm, i guess: If 'meta' in header, we know it's a property
19:15:16 <dtroyer> right, we added the prefix in the first place to set it
19:16:11 <stevemar_> dtroyer: also, what were you trying to do with meta-owner
19:16:23 <stevemar_> it's all over the code base, and its the same as the account id
19:16:46 <dtroyer> no idea off the top o'my head...
19:17:02 <stevemar_> dtroyer: can i rip it out when i fix up the 'show'?
19:17:12 <stevemar_> it's always the same as the account id / project id
19:17:22 <dtroyer> I think so?  I may have been trying to make this look more like the rest of the world
19:17:41 <stevemar_> i dunno
19:17:46 <stevemar_> okay, i'll rip it out
19:17:49 <dtroyer> but remember the core of that code was pulled from swiftclient and I may not have understood it well enough
19:17:49 <stevemar_> yoiiiiink
19:18:47 <dtroyer> more on obj-sto?  lhcheng the review you noted above looks good, you'll have a follow-up soon?
19:19:12 <lhcheng> nope, I want to treat the header cleanup as separate bug
19:19:27 <lhcheng> dtroyer: we might need to do something like: https://github.com/openstack/python-swiftclient/blob/master/swiftclient/client.py#L240
19:19:42 <dtroyer> ok, fine.  I wanted to make sure merging 231847 didn't leave us in a half-done state
19:19:56 <dtroyer> so two issues then
19:20:03 <lhcheng> yup
19:20:10 <dtroyer> cool
19:20:14 <stevemar_> dtroyer: nah, it's fine to go in separate
19:21:17 <dtroyer> #topic image updates
19:21:25 <dtroyer> we still have a number of these in-flight
19:22:04 <stevemar_> we do?
19:22:07 <dtroyer> I'd like to get to a logical breakpoint before the next release
19:23:11 <dtroyer> bunting has —volume for image set (https://review.openstack.org/228512) and —owner for image create (https://review.openstack.org/227845)
19:23:36 <dtroyer> the latter may be fine to wait, I think we need at tleast the former in, —location and —copy-from may be lower priority
19:24:34 <stevemar_> ah right
19:24:57 <stevemar_> gah, more reviews to do
19:25:16 <dtroyer> always more!
19:25:28 <dtroyer> #topic other reviews
19:25:34 <dtroyer> any others anyone wants to raise?
19:25:45 <stevemar_> i wouldn't mind cutting another release once image and object are settled
19:25:56 <dtroyer> that's what I was thinking too
19:26:22 <dtroyer> looking for where that line is…seems like —volume is the one we're mostly waiting on?
19:26:56 <stevemar_> i think so
19:27:01 <stevemar_> plugins?
19:27:18 <stevemar_> "we need to talk about plugins"
19:27:21 <dtroyer> #topic plugins
19:27:23 <dtroyer> go for it
19:27:32 <stevemar_> zigo brought it up in the ML
19:27:38 <stevemar_> is there a better way to handle conflicts?
19:27:48 <stevemar_> or not-found
19:28:10 <dtroyer> his actual problem was a plugin bug, but the command conflict is a reall issue
19:28:12 <stevemar_> i've also gotten myself into a pretty nasty state once or twice
19:28:29 <dtroyer> better tools for debugging entrypoints would help
19:28:59 <dtroyer> dhellmann has his ep tool that is a huge help, maybe a doc describing the process for finding problems would help
19:29:00 <stevemar_> hmm, this is outside of my realm of expertise
19:29:25 <stevemar_> i made this: https://review.openstack.org/#/c/231730/
19:29:37 <dtroyer> I actually think that overriding entry points is a feature if it can be controlled
19:29:52 <stevemar_> but it would be nice if had a gate job or test that saw conflicts
19:30:09 <dhellmann> stevemar_: https://pypi.python.org/pypi/entry_point_inspector
19:30:09 <dtroyer> how?  we have to find all the plugins and gate on them?
19:30:20 <dtroyer> thanks dhellmann
19:30:56 <stevemar_> dtroyer: yeah, just talking abstractly
19:31:06 <stevemar_> i have no idea how to solve that issue
19:31:08 <dhellmann> we could set up a job that other projects could add themselves to to verify that they aren't introducing a duplicate
19:31:30 <dhellmann> it would just need to install everything and then scan the namespace for dupes
19:31:34 <stevemar_> dhellmann: those jobs would need to pull in other projects too
19:31:41 <dtroyer> I think the doc you started is our interim, and for-now-best, solution
19:31:58 <dhellmann> stevemar_: yeah, it would be consenting co-gating
19:32:00 * stevemar_ might be turning on his tv to watch game 1 of ALDS
19:32:09 <dtroyer> that still doesn't solve the 'private plugin' case though.  I have one for Nebula for example that could never run there...
19:32:27 <dhellmann> dtroyer: how do you guarantee load order for your plugin
19:32:29 <stevemar_> dhellmann: it sounds tricky, i just wish folks would look at a doc before doing that
19:32:29 <dhellmann> ?
19:33:04 <dhellmann> stevemar_: yeah
19:33:07 <dtroyer> dhellmann: I couldn't sort that out so assumed it wasn't possible.  but I hadn't asked you about it yet ;)
19:33:18 <dhellmann> dtroyer: I don't think it's possible :-)
19:33:36 <dhellmann> dtroyer: if we want to support overrides, we should add that to cliff explicitly
19:33:53 <dtroyer> there is a similar problem with making command aliases, for deprecating commands but only shoing the new one in help
19:34:06 * dhellmann nods
19:34:08 <dtroyer> dhellmann: yup
19:34:40 <dtroyer> and that's why you haven't seen my modifed command plugin yet...
19:35:58 <dtroyer> stevemar_: fwiw I filed a bug on cueclient for that message-broker command, haven't decided on designateclient yet on ptr_record
19:36:11 <dtroyer> got sidetracked on the alias part last night
19:36:23 <stevemar_> dtroyer: cueclient should be able to change, they haven't released yet AFAIK
19:36:40 <stevemar_> ah dammit, they did a 0.9.0
19:38:12 <stevemar_> dtroyer: i think keeping the "code name" in the doc makes sense
19:38:37 <stevemar_> there are 2 different messaging projects
19:38:52 <dtroyer> this may be the only place I think it does, users need to know that to install the right lib
19:39:09 <stevemar_> right
19:39:52 <stevemar_> dtroyer: i think that's all for me
19:39:59 <stevemar_> we can decide on summit stuff next week
19:40:51 <dtroyer> yeah.  so far the two things I'm kicking around are about the command conflict and some overall multiple-project things for the fishbowl
19:41:26 <dtroyer> and I'm shifting my conference talk away from including SDK since it is still so far off
19:41:47 <stevemar_> for me it's: look for cinder to buy-in for osc (we're super close to parity); ask glance to implement their v3 API in OSC only; focus on keystoneauth; sdk support; neutron anything
19:42:24 <dtroyer> #topic open discussion
19:42:28 <dhellmann> stevemar_: we can try to get glance to only implement the new image import API in osc as well
19:44:00 <dtroyer> I'm more nervous about doing that with glance just because that client is soo different (v2 at least) I'd prefer to not need it at all.
19:44:25 <dtroyer> unique deps like pyopenssl, warlock, etc
19:44:47 <dhellmann> do we not use glance's client to talk to that API?
19:45:15 <dtroyer> we do except for the list commands today, those are using my internal api prototype that the sdk didn't merge
19:45:21 <dhellmann> ah
19:45:53 <dhellmann> it looks like we're going to end up with a new API to find the preferred/supported settings in the cloud, and then another to start the import from a URL
19:46:21 <dtroyer> yay discovery!
19:46:40 <dhellmann> those will be part of v2, not v3
19:46:59 <dhellmann> v2.x or something -- we haven't figured that part out yet
19:47:10 <dtroyer> kinda unrelated, but do you know if glance has plans for microversioning their api?
19:47:34 <dhellmann> that's the thing we haven't worked out
19:47:51 <dhellmann> right now we're focusing on what an api should look like, and we'll deal with the version # when we see what we need to add/change
19:48:05 <dtroyer> ok.  I want to generalize nova's negotiation and try to use it as much everywhere as possible.
19:48:26 <dtroyer> so if that comes up I hope it's at least similar
19:48:40 <dhellmann> here's the spec if you want to follow it https://review.openstack.org/#/c/232371/
19:50:15 <dtroyer> thanks
19:50:29 <dtroyer> anything else?
19:50:50 * dhellmann has nothing
19:51:22 <dtroyer> I'm trying to distill OSC's auth process (including cmdline/env var handling) into a single example to make it easy to seee and try both direct ksa and the sdk.
19:51:33 <dtroyer> https://review.openstack.org/#/c/232695/
19:52:29 <dtroyer> that should be easier to follow than jumping between clientmanager.py and shell.py and whatever else
19:53:46 <dtroyer> oh, one more: stevemar_, any thoughts on the discussion in https://review.openstack.org/231812?
19:54:24 <dtroyer> chime in there if so
19:55:37 <dtroyer> alrightythen… last chance…
19:56:26 <stevemar_> dtroyer: i'll chime in
19:56:31 <dtroyer> ok, thanks everyone!
19:56:38 <stevemar_> i didn't realize it was so unfinished
19:56:39 <MeganR> thank you
19:56:40 <dtroyer> thanks
19:56:53 <dtroyer> #endmeeting