19:05:36 #startmeeting OpenStackClient 19:05:37 Meeting started Thu Mar 5 19:05:36 2015 UTC and is due to finish in 60 minutes. The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:05:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:05:40 The meeting name has been set to 'openstackclient' 19:05:52 agenda: https://wiki.openstack.org/wiki/Meetings/OpenStackClient#05_Mar_2015 19:06:35 I believe all three actions from last week are completed, anyone have anything to say about them? 19:06:49 (planning to talk about cliff in a minute) 19:08:09 ok, cool 19:08:21 nice to have the meeting time picked out 19:08:25 #topic project status 19:08:48 Let's start with cliff. 19:09:04 dhellmann, looks like there was agreement to move it here on the ML? 19:09:11 looks like no one complained about the suggestion 19:09:19 dims and bnemec were in support of it 19:09:21 yes, I think it's safe to propose changing ownership 19:09:44 ok, I've added it to the etherpad already. 19:10:27 also, mordred suggested os-client-config be added too so I added that too. comment? 19:10:42 I don't know what that is 19:11:28 it is a lib that reads a yaml file for cloud config, allowing you to define multiple clouds and use that config rather than always spcifying the multiple auth and region values 19:12:23 dtroyer, added where? 19:12:26 makes sense 19:12:30 #link https://git.openstack.org/cgit/stackforge/os-client-config 19:12:38 added to the OSC project repo list 19:12:42 stevemar: as a repo managed by this team 19:13:15 he developed it for his shade project, I think there are a couple of other users for o-c-c already too 19:13:30 the nice thing is that we'll all have a single config file for this 19:13:31 we're just adding to our army now 19:13:55 and y'all thought jamie and I were joking about taking over the world in HK… 19:14:06 the only issue i see with that is that it might be too much to ask in one request? 19:14:10 I’m looking forward to have o-c-c in there 19:14:25 graduate osc, oh and pull in cliff, also move occ from stackforge 19:14:50 stevemar: I don't think that will be an issue, but if it is we can do multiple steps. 19:14:54 stevemar: would submit them separately, if there are concerns, but let's start with one request. 19:14:56 heh 19:15:21 o-c-c is going to be the most work I think, moving it out of stackforge 19:16:06 sounds good to me then 19:16:14 ok, if we're good with this I'll submit the review and send email. 19:16:25 ++ 19:16:32 IIRc there may not be a TC meeting next week so it might be a bit before anything happens 19:16:48 even if we do meet, we might not discuss this proposal because of the timing 19:16:59 ola! 19:17:31 * mordred has read backscroll, agrees with everything 19:17:40 #action dtroyer to submit project proposal review including cliff and os-client-config 19:18:09 #topic release schedule 19:18:40 In the agenda I suggested we look at a release next week, we have a good pile of fixed bugs finished. 19:19:20 One thing we should discuss is whether the —os-cloud support should be included. 19:19:45 that is a lot to iron out by 3/9 19:19:50 dtroyer, maybe one more release without occ? 19:20:14 we'll push a lot of fixes by releasing something soon 19:20:16 given that it hasn't merged yet, I agree 19:20:24 I'd like to have some working time on it 19:20:30 yeah, agreed 19:21:08 I would like to get the first patch of that series merged, the one tht moves the auth plugin code to auth_plugins.py as that fixes an existing problem 19:21:40 anything else that should be included that isn't done yet? 19:22:13 that one seems OK to include, it's just shuffling the plugin around 19:22:15 subnet crud would be nice, but that isn’t merged yet either 19:22:43 * dhellmann adds osc reviews to his todo list for tomorrow 19:22:44 there are 7 bugs targeted for m8 still open 19:23:23 what about lhcheng's changes? 19:23:43 https://bugs.launchpad.net/bugs/1423748 hypervisor commands should be easily doable 19:23:44 Launchpad bug 1423748 in python-openstackclient "Add support for hypervisor-stats and hypervisor-uptime command" [Undecided,In progress] - Assigned to Lin Hua Cheng (lin-hua-cheng) 19:23:57 that one stevemar? 19:24:03 dtroyer, yessum 19:24:25 dtroyer, i haven't had a chance to review them much, but i saw that you went a few rounds with it 19:25:15 i had two hesitations: the uptie one just includes a standard uptime(1) output string, seems we might want to clean that up a bit 19:25:17 also this one seems important https://review.openstack.org/#/c/156107/1 19:25:39 and I wanted to confirm creating a new 'hypervisor stats' object was the Right Thing 19:26:31 oh, fun, I didn't think we were going to do admin commands 19:26:34 yes, that one was next. I think Iw as just waiting for clean tests 19:26:46 +A 19:26:50 k 19:27:11 did you want pretty output for the uptime one? 19:27:25 dhellmann: most of identity is admin commands, we've gone back and forth on those 19:27:37 yeah, not arguing, just catching up :-) 19:27:50 stevemar: I was thinking about breaking down the actual uptime value, and maybe the load avg values into their own fields 19:28:14 that would make it easier to use different output formatters 19:28:25 dhellmann: I'm open for thoughs there. One idea was to put them into a plugin so users don't get them by default, but that might be annoying 19:28:40 re admin 19:28:42 dtroyer: I sort of like that. An openstackclient-admin package. 19:29:04 it would be nice if the service catalog would only give admin urls if they were allowed 19:29:39 terrylhowe: figure out how to do that (policy is the problem) and a lot of people will be very happy ;) 19:29:56 dtroyer: so the uptime value is "16:05:22 up 7:09, 5 users, load average: 0.29, 0.68, 0.59", should we split it into three fields? 19:30:20 #idea think about putting known admin-only commands into a separate package/plugin 19:30:39 lhcheng: is the user count important? 19:31:04 I count 4 values there, unless you want the load average as 3 separate items then it's 6 19:31:17 I thought load average could stay a single field 19:31:22 yeah 19:31:33 and wasn't sure of the value of the time 19:31:38 or users 19:31:38 dhellmann: I think the first value "16:05:22" is when the uptime is taken. 19:32:00 lhcheng: ok, it's still potentially useful though, right? 19:32:21 dtroyer: not sure if user count is important, we don't really use it 19:32:27 dtroyer: if the values are there we might as well parse them out, it's not that hard 19:33:12 lhcheng: is splitting the uptime string something up could do before Monday? 19:33:40 it would be nice to have that in the next release and not change the format later 19:33:43 i would hope so :) 19:33:49 dtroyer: sure, I can finish that up 19:34:17 lhcheng: great, thanks 19:34:36 dhellmann: yeah, we could include the time the stats was taken too. So there are 4 fields then. 19:35:37 sounds good 19:35:57 moving on, I'd like some other thoughts on https://review.openstack.org/#/c/147453/ as it introduces a CLI incompatibility 19:36:28 I can probably live with the help output not quite representing what really is allowed though 19:36:53 should we push this out to m9? 19:37:07 oof, this one 19:37:33 this one had a bunch of nested args 19:38:16 couldn't we have set nargs='?' for the --live option? 19:38:26 I guess then there's no way to tell if it was set at all 19:39:40 the problem is that moving the host name off —live to —host is incompatible. 19:39:51 right 19:40:09 although probably the right move 19:41:03 given the spotty support for live migration overall in deployments, is this one of those places we note that? and maybe save it for 1.1.0? 19:41:19 ie, it might be low impact to users 19:41:20 if it's not backwards compatible, do we want that to be 2.0? 19:41:54 it doesn't feel right to do 2.0 for just this 19:42:20 actually, I just ha an idea… —live isn't needed if —host is present 19:42:48 essentially it becomes renaming —live to —host and keeping the compat but suppressed in help 19:43:29 no, —host is optional 19:43:42 if that's the case, why not leave --live alone and add a new option for the new case? 19:43:48 --live-pick-a-host-for-me 19:44:42 ugh. for the near term, push this to m9 either way I think 19:44:57 dhellmann: yeah, thats another thing to consider 19:46:03 stevemar: I gather that you will want to defer https://bugs.launchpad.net/bugs/1409218 (ec2 creds) doe to timing? 19:46:04 Launchpad bug 1409218 in python-openstackclient "condense credentials (ec2, v3, compute)" [High,In progress] - Assigned to Steve Martinelli (stevemar) 19:46:06 I commented on the review 19:46:26 dtroyer, yep 19:46:41 keystone is keeping me busy for the next little while 19:48:18 I'm thinking to defer the remaining bugs (top 3 on the milestone page list) 19:48:24 https://launchpad.net/python-openstackclient/+milestone/m8 19:49:41 10 min warning 19:49:58 also the one blueprint too 19:50:07 yeah, both of them 19:50:40 anything else on bugs? 19:51:04 thats okay for now 19:51:24 #topic open discussion 19:51:42 Is there anything else we need to talk about? 19:51:59 dtroyer, is there a place you want to put future work items on? 19:52:04 aside from blueprint? 19:52:15 i'm not the biggest fan of bps :) 19:52:21 they tend to get lost 19:52:31 dtroyer: i haven't dug into the review, but what were your thoughts on Julien wanting to use SDK for his metering client work? (i think it was metering) 19:52:38 rather, forgotten about 19:53:11 stevemar: are you talking a specs-like thing? or just keep abusing bugs? 19:53:35 dtroyer, i was thinking specs 19:54:06 dtroyer, for things like config files, maybe global switches? using -a instead of --all 19:54:08 stuff like that 19:54:34 specs might be overkill 19:54:48 I'm hesitating to jump into a specs repo, yeah. 19:55:02 some of the design guidelines/rules you're talking about can go into the docs 19:55:04 okay, blueprints for now then 19:55:16 where else doesn't have the same issue as LP blueprints? 19:55:35 dhellmann: right. I started moving stuff out of the wiki, not sure if we're done yet 19:55:53 briancurtin: even without pulling in the sdk I think I'd like telemetry to be a plugin. 19:56:29 we've never really drawn the line of what gets into the repo and what is a plugin, that's just my gut feeling 19:57:53 dtroyer: since our APIs are not yet stable and consistent across teh board, i would hazard against pulling it in until we've ironed that all out, so plugin seems better for right now 19:58:35 we're reasonably close to it being more broadly usable, but today's not the day 19:58:47 briancurtin: I've thought that was the case but I've been out of that loop for a while. Next week I'll be able to come to the sdk meetings again so that should help me there 19:59:21 dtroyer, yeah... we need to draw the line on what projects are going to have full support vs plugins 19:59:40 my biggest concern about the sdk is the auth bits. I don't want to mix ksc and sdk, and that's not going to be a small job. 19:59:43 probably just follow the big tent / layer model 19:59:55 out of time :( 19:59:58 stevemar: that means everything is in? 20:00:08 well we pick a layer! 20:00:12 stevemar: this was why I based cliff on plugins -- the idea at first was to have everything *out* 20:00:13 we can talk about this more, no hurry I think 20:00:36 and fwiw, everything in OSC right now is in the plugin form, we could move them out too ;) 20:00:50 anyway, thanks everyone! 20:00:56 thanks! 20:01:03 thanks! 20:01:07 #endmeeting