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