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