19:03:29 <dtroyer> #startmeeting OpenStackClient
19:03:30 <openstack> Meeting started Thu Apr 16 19:03:29 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:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:33 <openstack> The meeting name has been set to 'openstackclient'
19:03:55 <dtroyer> I threw some things into the agenda at https://wiki.openstack.org/wiki/Meetings/OpenStackClient#16_Apr_2015 this morning
19:04:31 <dtroyer> but first I want to take care of something that should have been done a while ago
19:04:49 <dtroyer> and add terrylhowe to the osc core team
19:05:29 <stevemar> \o/
19:05:45 <stevemar> rejoice
19:06:06 * stevemar can now slack off
19:07:43 <dtroyer> Terry has put in a ton of work and reviews into OSC, and I want to say thanks for that and welcome
19:08:08 <terrylhowe> thanks, I think I know generally what dtroyer is looking for with osc :)  I’ll try not ot aggrevate him too much
19:08:29 <dtroyer> that's what keeps me honest you know…
19:09:06 <dtroyer> #topic summit status
19:09:14 <stevemar> dtroyer can use a little aggravation every now and then
19:09:47 <dtroyer> I don't have anything specific here, and haven't even created an etherpad yet, but we should start thinking about how to use the sessions in Vancouver
19:10:24 <dtroyer> we have one fishbowl for a large audience and one work-room or whatever they're called for the smaller get together
19:11:59 <dtroyer> #link https://etherpad.openstack.org/p/osc-liberty-summit-planning
19:12:10 <dtroyer> there's an empty etherpad to collect ideas and suggections
19:13:32 <dtroyer> if there are no comments we'll keep going
19:14:04 <dtroyer> #topic reviews
19:14:10 <stevemar> i thought we had a list already
19:14:30 <dtroyer> really?  it's been an odd couple of weeks and I didn't dig through the notes…
19:14:47 <stevemar> i'll dig through my history later
19:14:49 <stevemar> no biggie
19:15:50 <dtroyer> anyway, reviews:  I put https://review.openstack.org/#/c/164091/ on the agenda because that's a topic that has been getting attention elsewhere lately
19:16:23 <dtroyer> that is the —timing fix, also https://review.openstack.org/173098 (defer imports) plays into this
19:16:50 <stevemar> sigh
19:17:04 <stevemar> do we want to make a call on this now or wait til vancity to discuss?
19:17:34 <dtroyer> 164091 is a bug fix, I don't think it needs to wait
19:18:03 <dtroyer> I personally don't mind doing the imports now, but if there is reluctance it can wait
19:19:04 <stevemar> do we have any benchmarks on the defer imports fix?
19:19:25 <dtroyer> I spent a bit of time with Boris' static import tool, profimp, and pinned down where we've been importing things unnecessarily
19:19:55 <dtroyer> I haven't posted the outcomes anywhere, probably should.  that patch gained about half a second on my mac oerall
19:20:28 <dtroyer> but it also corrects the forced import of the client libs on every run.
19:20:46 <dtroyer> that could be split up as its more of a design flaw fix
19:21:12 <stevemar> give me a day to pull it down and play with it
19:21:42 <dtroyer> ok
19:22:00 <stevemar> that should be easy to verify
19:22:14 <stevemar> then devstack / infra guys will like that
19:22:26 <stevemar> half second * 40ish calls
19:22:32 <stevemar> or more
19:23:00 <dtroyer> we'll get better returns by re-working devstack a bit to do batches of osc calls.
19:23:08 <dtroyer> s/better/additional/
19:23:48 <dtroyer> there's also a coprocess scheme we could use but it'll take some tweaks to osc, we can talk about those next month
19:24:33 <stevemar> ++ on batch calls
19:24:40 <dtroyer> anyone else have any reviews they'd like to bring to our attention?
19:24:42 <stevemar> can't believe i didn't think of that earlier...
19:24:48 <terrylhowe> here documents for the batches?
19:25:19 <dtroyer> terrylhowe: yes.  there are issues when we need to capture an ID or something, but there are easy gains to be had there
19:25:33 <stevemar> i wouldn't mind talking about the image listing stuff
19:25:44 <dtroyer> stevemar: go for it
19:26:06 <stevemar> so i think my proposal (--limit), and terry's (actually handling the paging) can co-exist
19:26:16 <stevemar> we'll use terry's as default
19:26:23 <stevemar> and if someone wants a limit, so be it
19:26:30 <dtroyer> yes, I think they should
19:26:54 <terrylhowe> It’d technically be nice if all the list commands had limit/marker
19:26:58 <stevemar> do we have a strategy for global options (like limit)
19:27:02 <stevemar> ++ terrylhowe
19:27:05 <dtroyer> I wonder about the word 'limit' but that's a shed to paint, possibly later
19:27:32 <stevemar> my last comment was an open question
19:27:33 <dtroyer> I would like to see all list commands have these options, even if we have to fake it locally on some
19:28:17 <dtroyer> once we get usable caching it might not be too terrible performance-wide to do repeated limited lists
19:28:26 <stevemar> maybe we can create a base List class and inherit from there
19:28:58 <stevemar> create the parser/option in the base class
19:29:07 <stevemar> (just thinking out loud)
19:29:40 <dtroyer> it cold all be done in the layer below the command classes, the sort of thing I was aiming for in openstackclient.api.api
19:30:21 <dtroyer> the object_store list functions already have a model for doing both, although its recursive and some folk don't like that
19:31:17 <dtroyer> anyway, can we start with the two proposals we have, fit them together and iterate outward form there?
19:31:23 <terrylhowe> the support in the REST APIs is so varied
19:31:25 <stevemar> yep
19:31:41 <terrylhowe> yes
19:31:55 <stevemar> theres also the service providers patch that i -2'ed
19:32:02 <stevemar> we need a newer version of ksc
19:32:19 <dtroyer> I had a note to ask if that's been released in ksc yet
19:32:40 <stevemar> it has been
19:32:54 <dtroyer> in stable/kilo?
19:32:56 <stevemar> but we need to keep our requirements in sync with g-r
19:33:13 <stevemar> i don't know, let me check
19:33:29 <stevemar> for upgrading in liberty: https://review.openstack.org/#/c/168187/
19:34:13 <stevemar> dtroyer, no, in stable/kilo it's still 1.1.0, for this new stuff we need 1.3.0
19:34:42 <dtroyer> would it be possible/desirable to check version at run-time?
19:35:05 <stevemar> not worth it, i'd rather wait til g-r is updated
19:35:12 <stevemar> and push this through when ksc is updated
19:35:14 <dtroyer> that's actually a general question that might help us deal with a variety of library versions and not have to wait all the time
19:35:18 <stevemar> no one is clamoring for this
19:35:29 <dtroyer> for this review, I'm good with that
19:35:57 <stevemar> you are thinking that we could have something in place that fails gracefully?
19:36:07 <dtroyer> I've wondered though about getting better at dealing with older libraries so we don't always have to wait for releases
19:36:09 <dtroyer> yes
19:36:28 <dtroyer> it might not be worth the effort though
19:36:33 <stevemar> would be handy if it was a decorator or something
19:37:08 <stevemar> it basically calls to identity_client.something_dne or volume_client.something_else
19:37:11 <stevemar> and those are failing
19:37:15 <stevemar> should be easy to check
19:37:45 <stevemar> add it to the backlog!
19:38:07 <dtroyer> it can wait behind the wait command ;)
19:38:14 <dtroyer> ok, any other reviews to talk about?
19:39:16 <dtroyer> #topic bugs
19:39:28 <dtroyer> #link https://bugs.launchpad.net/python-openstackclient/+bug/1406470
19:39:29 <openstack> Launchpad bug 1406470 in python-openstackclient "track backwards incompatible changes" [High,Confirmed]
19:40:01 <dtroyer> this is really a process suggestion, I think stevemar's suggestion is workable
19:40:30 <dtroyer> any dissenting comments or objections?
19:40:52 <stevemar> hmm
19:41:01 <stevemar> what was my suggestion?
19:41:30 <dtroyer> using a tag in the commit message
19:41:40 <dtroyer> that's what I read anyway, did I miss?
19:42:53 <stevemar> right right
19:42:59 <terrylhowe> we going to start removing deprecated options and such?
19:43:08 <stevemar> no, thats what i meant, i just forget things
19:43:18 <stevemar> yeah, when we're in a pinch
19:43:25 <stevemar> or the server side changes
19:43:32 <stevemar> like what happened with v3 service create
19:43:46 <dtroyer> but also marking when things change to find them later to follow up
19:44:49 <dtroyer> I'm not sure where we should write this down, should we continue to put process stuff like this in the wiki?
19:45:29 <terrylhowe> anyone running super old versions of OS should probably use pinned clis anyway
19:46:17 <stevemar> somewhere permanent thats for sure
19:46:28 <stevemar> i wouldn't mind the dev docs
19:46:34 <stevemar> its my go-to
19:46:46 <stevemar> a section for backwards incompatible changes
19:46:55 <terrylhowe> ++ dev docs
19:47:12 <dtroyer> I wasn't sure about using that for project stuff though, but that'll work
19:47:30 <dtroyer> stevemar: want to translate that bug to a doc proposal?
19:48:48 <stevemar> sure
19:49:27 <dtroyer> #action stevemar translate bug 1406470 to a dev docs entry
19:49:28 <openstack> bug 1406470 in python-openstackclient "track backwards incompatible changes" [High,Confirmed] https://launchpad.net/bugs/1406470
19:49:29 <stevemar> #action stevemar to translate bug to doc page for tracking backwards incompat. changes
19:49:38 <stevemar> beat me to it!
19:50:15 <dtroyer> #link https://bugs.launchpad.net/python-openstackclient/+bug/1409218
19:50:16 <openstack> Launchpad bug 1409218 in python-openstackclient "condense credentials (ec2, v3, compute)" [High,In progress] - Assigned to Steve Martinelli (stevemar)
19:50:32 <dtroyer> I really just have a question about continuing to target this to m9 release
19:51:23 <dtroyer> maybe it isn't a high priority bug as we've pushed it at least once already
19:52:40 <stevemar> dtroyer, someone just asked me about that yesterday
19:52:43 <stevemar> and it's blocking them
19:52:50 <stevemar> since they can't use v2 option
19:53:06 <stevemar> cause the user that is trying to do it is in a non-default domain
19:53:56 <dtroyer> ok, I'll leave it for now and we can look again in a week or two when we are hopefully preparing the next release
19:54:42 <stevemar> dtroyer, yeah, i might just have the keystone bits done :\
19:55:01 <stevemar> we can split out the nova credential related stuff
19:55:15 <dtroyer> that works for me
19:55:53 <dtroyer> the last three bugs we've already covered today so unless there is more there we'll move on
19:56:28 <dtroyer> #topic blueprints
19:57:11 <dtroyer> the only thing I wanted to say about https://blueprints.launchpad.net/python-openstackclient/+spec/waitcommand was to point it out and get some feedback on if it might be a useful thing and measure priority.  comments in the bp work
19:57:34 <stevemar> i don't recall this one
19:57:57 <dtroyer> I just wrote it yesterday
19:58:42 <dtroyer> the use case is to not do polling loops in bash for things we can easily do liek we handle —wait now
19:59:12 <terrylhowe> might be nice to have a —failure option action append for statuses that are failures
19:59:23 <terrylhowe> looks very handy to me though
19:59:37 <dtroyer> terrylhowe: add that to the bp?
19:59:47 <terrylhowe> sure
20:00:15 <dtroyer> so with a minute left…
20:00:23 <dtroyer> #open discussion
20:00:29 <dtroyer> jeez...
20:00:32 <stevemar> buzzz
20:01:25 <terrylhowe> nothing here
20:01:27 <dtroyer> I've talked too much already, but I do want to say that I'm finding a home after the recent unpleasantness that will let me focus more on client stuff, not just osc.
20:01:44 <terrylhowe> excellent
20:01:56 <stevemar> we're all happy to have you stick around osc and client land
20:02:13 <dtroyer> thanks
20:02:21 <dtroyer> and thank you all for coming
20:02:26 <dtroyer> #endmeeting