19:01:51 <dtroyer> #startmeeting openstackclient
19:01:52 <openstack> Meeting started Thu Mar 24 19:01:51 2016 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:55 <openstack> The meeting name has been set to 'openstackclient'
19:02:01 <dtroyer> anyone here?
19:02:08 <rtheis> hi
19:04:12 <dtroyer> this may be a quick meeting...
19:04:48 <singhj> o/
19:05:23 <dtroyer> well, lets get started
19:05:29 <dtroyer> #topic reviews
19:05:43 <dtroyer> Reviews to discuss?
19:05:58 <rtheis> https://review.openstack.org/#/c/290849/9/doc/source/command-objects/port.rst
19:06:30 <rtheis> dtroyer: question in there for you on using --clear versus --no versus an unset actin
19:06:52 <dtroyer> is that in the create command?
19:07:20 <singhj> dtroyer: set command
19:07:39 <rtheis> dtroyer: clear would be for set only
19:07:56 <singhj> dtroyer: specifically ex. port set --clear-security-groups <port>
19:08:15 <dtroyer> so a port can haz only one security group?
19:08:31 <dtroyer> nm, I see it
19:08:31 <singhj> it may have multiple
19:09:09 <dtroyer> for multiple I think it's easy to stick with the precedent of —clear-XXX
19:09:23 <dtroyer> unset could do it too though
19:09:39 <dtroyer> port unset —security-group <name> <port>
19:09:54 <dtroyer> to clear all would be a pita though
19:10:06 <dtroyer> should we do both?  otherwise to remove just one it's a clear and re-load
19:11:07 <singhj> well, right now, I've got --clear-xxx working, i'd be convenient to be able to unset
19:11:16 <singhj> it'd*
19:11:32 <singhj> I'm fine with either way, rtheis?
19:11:41 <rtheis> singhj: does the REST API allow unsetting a specific group?
19:12:47 <rtheis> maybe not, you probably just have to pull it out of the list
19:12:50 <singhj> it does not, it seems to be all or none. there is one similar command "--extra-dhcp-opts" that is based on individual unsetting
19:12:50 <dtroyer> it might take a GET, remove from dict, PATCH cycle to do
19:12:57 <rtheis> yeah
19:13:02 <singhj> but to achieve that you basically set a property to null
19:13:05 <singhj> its a bit hacky
19:13:58 <dtroyer> I would like to see unset support, it need not be in the first cut though.
19:14:03 <rtheis> I like --clear option and possibly adding unset command support
19:14:05 <dtroyer> should —clear-NNN be in set or unset?
19:14:20 <dtroyer> it feels like an unset option to me
19:14:32 <dtroyer> but I could defend either choice
19:14:45 <singhj> I can port it over, it's currently in set
19:14:47 <rtheis> yeah, I could go either way
19:15:15 <dtroyer> where is it in the route commands?
19:15:20 <rtheis> set
19:15:39 <dtroyer> would it be absurd to do both?
19:15:46 <singhj> where do we have unset working so far?
19:15:53 <singhj> I havent encountered it
19:16:03 <rtheis> I think it would be okay to do both
19:16:31 <rtheis> singhj: no unset for network commands
19:16:41 <dtroyer> a lot of places: flavor, server, project, etc
19:16:43 <rtheis> singhj: but you'll find it used in others
19:16:48 <dtroyer> ok, maybe not a lot, I count 10
19:17:04 <singhj> ah okay, sure
19:17:07 <dtroyer> usually for removing properties
19:17:11 <singhj> I'm fine doing it in both places
19:17:30 <singhj> when we say both do we mean --clear-* in unset and set
19:17:37 <dtroyer> lets do that then.  it feels just a tiny bit odd, but I can live with it
19:17:38 <singhj> is that the "both"?
19:17:44 <dtroyer> yes
19:18:11 <singhj> sure, sounds good to me
19:18:12 <dtroyer> so if —clear- and —security-group both appear in set, what should we do?
19:18:21 <dtroyer> is that the reason to not do clear in the set command?
19:18:30 <dtroyer> or should it clear first, then set?
19:18:39 <rtheis> I think that would be mutually exclusive group
19:18:42 <singhj> well right now they're mutually exclusive
19:18:46 <dtroyer> ok
19:19:06 <dtroyer> that'll work
19:19:21 <singhj> okay cool
19:19:23 <rtheis> thanks
19:19:35 <dtroyer> any others?
19:19:40 <rtheis> nothing from me
19:19:56 <singhj> same
19:20:03 <dtroyer> sheel and I were kicking around the volume transfer stuff this morning
19:20:27 <dtroyer> unfortunately the implementation in cinder is nothing like how image member/sharing works in glance so we can't take the same approach
19:21:04 <dtroyer> I think we can make it better but haven't convinced him yet ;)
19:21:43 <rtheis> dtroyer: this review https://review.openstack.org/#/c/292043/ ?
19:22:01 <dtroyer> yes
19:22:59 <dtroyer> I think 'volume transfer' is a very confusing resource name…it looks like an action
19:23:18 <rtheis> agreed
19:23:21 <dtroyer> but aside from that, the mechanics of the transfer are odd
19:23:46 <dtroyer> in a way that doesn't make adding it as options to the existing volume commands easy
19:24:00 <dtroyer> so, ideas are welcome
19:24:14 <rtheis> I'll put it on my review list
19:24:29 <dtroyer> also, https://review.openstack.org/#/c/297157/ could use a quick look rtheis
19:24:46 <dtroyer> its part of the release runup
19:24:51 <rtheis> ok
19:25:14 <dtroyer> How about…
19:25:18 <dtroyer> #topic bugs
19:25:54 <dtroyer> I have been doing UX studies with Piet Kruithof, and in 4 sessions found three bugs
19:26:16 <dtroyer> some may already exist, I haven't checked
19:26:28 <dtroyer> any bugs to bring up?
19:26:34 <rtheis> https://bugs.launchpad.net/python-openstackclient/+bug/1560157
19:26:34 <openstack> Launchpad bug 1560157 in python-openstackclient ""openstack network list" fails with "An SSL error occurred."" [Undecided,New]
19:26:41 <rtheis> this one caught my eye
19:27:10 <rtheis> maybe SDK related or interaction between osc and sdk auth
19:27:23 <dtroyer> that's interesting… yeah, I wonder if any other SDK commands do that?
19:27:32 <dtroyer> aren't we using the same sesison object either way though?
19:27:56 <rtheis> I thought so, but will have to check
19:28:23 <dtroyer> also, could be how the endpoint is conigured
19:28:28 <dtroyer> configured
19:28:45 <dtroyer> we should get some openssl commands to dump the endpopint info together for debugging
19:29:34 <dtroyer> #action make some notes for debugging SSL bits to get info from the server-side endpoint
19:29:52 <rtheis> sounds good
19:30:12 <rtheis> no other bugs from me
19:31:42 <dtroyer> ok, so what else is going on?
19:31:46 <dtroyer> #topic open discussion
19:32:29 <dtroyer> I want to do a release soonish, at least one more before the summit
19:32:34 <dtroyer> maybe two
19:32:47 <rtheis> sound good
19:33:05 <rtheis> any updates on summit schedule for osc?
19:33:36 <dtroyer> no schedule for sessions yet
19:33:51 <rtheis> ok
19:33:59 <dtroyer> I may be doing an on-stage update in a keynote
19:34:22 <rtheis> nice
19:34:38 <dtroyer> and I think Piet is going to do some UX sessions with operators on Tuesday or Wednesday
19:34:59 <dtroyer> we'll get some better info on commands more complidated than creating a server
19:35:18 <dtroyer> which is bad enough but is also pretty well understood and debugged
19:36:34 <dtroyer> ok if there is nothing else, lets be done
19:36:38 <rtheis> FYI: briancurtin has a sdk resource refactor https://review.openstack.org/#/c/289998/ ... the results of which will eventually impact osc
19:36:55 <rtheis> this is part of the sdk path to 1.0
19:37:07 <dtroyer> I saw a comment along those lines…and was the kind of reason I hoped we could wait until 1.0
19:37:38 <dtroyer> can we handle it in a compatible way?
19:37:50 <rtheis> yeah...I plan to dig into it further to see if we can handle in a compatible way
19:37:56 <briancurtin> the impact should be fairly minimal, mostly only affecting resources that have a child/parent relationship (server and server_interface, for example)
19:38:45 <briancurtin> i guess it could also affect you if you’re depending on resource properties that aren’t actually properties on resource classes…as in you’re just taking advantage of the fact that it previously would just send and receive arbitrary data
19:39:24 <rtheis> briancurtin: I think the later is what may impact some osc options for network commands
19:40:07 <briancurtin> rtheis: i’m going to be tackling some of that while applying the changes to the resources, as i’m doing the changes with the docs open next to the files rather than only doing  find/replace…sort of an assisted find/replace
19:40:46 <rtheis> ok
19:41:33 <dtroyer> so I think we're going to need to either be able to straddle this in a single OSC release or do an osc 3.0 when we get those changes
19:41:52 <dtroyer> briancurtin: that makes its first appearance in 1.0 right?
19:42:46 <briancurtin> dtroyer: i’m not sure i understand the question — asking about the refactored resources and proxies?
19:42:57 <dtroyer> yes
19:43:37 <briancurtin> dtroyer: i haven’t exactly worked out how to release this stuff, but yeah, i think once it’s all in it will be released as 1.0
19:43:38 <dtroyer> we've talked about doing a major rev soon, it might make sense to use SDK 1.0 in our OSC 3.0
19:44:46 <dtroyer> ok, anything else?
19:44:53 <rtheis> nothing else
19:45:18 <dtroyer> ok, thanks guys
19:45:27 <dtroyer> #endmeeting