19:00:51 <dtroyer> #startmeeting openstackclient
19:00:52 <openstack> Meeting started Thu Mar  3 19:00: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:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:55 <openstack> The meeting name has been set to 'openstackclient'
19:01:15 <dtroyer> Hi all… who is here for OSC meeting?
19:01:44 <navidp> I am
19:01:54 <rtheis> o/
19:01:59 <rtheis> hi
19:02:03 <singhj> same here
19:02:03 <singhj> hi
19:02:04 <navidp> hi
19:03:00 <dtroyer> Let's get started…
19:03:05 <dtroyer> #topic reviews
19:03:18 <dtroyer> Anyone have specific reviews to talk about?
19:03:52 <rtheis> https://review.openstack.org/#/c/288056/
19:04:04 <navidp> I have auth migration from ksc to ksa https://review.openstack.org/#/c/276350/
19:04:23 <rtheis> I think a recent nova API validation change broke osc and nova aggregate create
19:04:48 <dtroyer> nice
19:05:41 <dtroyer> is that blocking more than just OSC?
19:05:49 <rtheis> This patch should unblock the gate and we can look at reverting once nova is fixed
19:05:59 <rtheis> I'm not aware of others being blocked
19:06:30 <dtroyer> the linked bug looks to be totally different
19:06:58 <rtheis> I asked on openstack-nova channel but no response
19:07:25 <rtheis> yeah, but it resulted in https://review.openstack.org/#/c/281143/ which I *think* is the cause
19:07:55 <dtroyer> The last time we went down a path like this they basically didn't want to do anything to the client lib..this time I don't think they'll be able to ignore it of the nova CLI is affected too
19:08:07 <dtroyer> ok, I see now at the bottom…
19:09:16 <dtroyer> I +2'd it, poke stevemar when he shows up…or after check run completes
19:09:33 <rtheis> will do
19:09:35 <dtroyer> navidp: https://review.openstack.org/#/c/276350/
19:09:46 <dtroyer> I've been looking at that this morning, haven't posted my comments yet
19:10:15 <dtroyer> I went down the rabbit hole of looking at my previous attempts to do this…they all involved varying amounts of occ pain
19:10:25 <dtroyer> I like that you're not going there yet
19:10:36 <navidp> dtroyer, thanks, wanted to check the approach i took confirms
19:11:20 <dtroyer> I posted my comments…basically you're changing OSC's TokenEndpoint class in an incompatible way
19:11:29 <navidp> i thought if it would get accepted then we can start deprecating osc plugins or else
19:11:57 <dtroyer> we'll probably never remove OSC's TokenEndpoint, jamielennox doesn't like it and we can't use his version
19:12:09 <dtroyer> OSCGenericPassword may be able to go away soon
19:12:38 <dtroyer> it probably already can' although the problem it works around is still in the wild
19:13:43 <navidp> I used admin token for osc token endpoint as i compared it to the ksc.
19:14:16 <navidp> dtroyer, do you want to add deprecation for osc_password ?
19:14:20 <rtheis> how does this related to https://review.openstack.org/#/c/225318/ ?  two different fixes to same problem?
19:14:47 <dtroyer> monty's goes way far and attempts to (in an incompatible way) move everything to occ
19:15:10 <dtroyer> I've tried that three times myself already
19:15:33 <dtroyer> since that was written.  also, it's way old
19:15:42 <rtheis> ok
19:15:50 <dtroyer> a lot in occ has changed since then, I'm not sure how much of that stevemar took into account in his rebase
19:16:13 <navidp> I thought this way we can initiate it and go further step by step without breaking everything.
19:16:53 <dtroyer> navidp: exactly.  but we also need to make sure we have tests to ensure we don't break compatibility
19:17:45 <dtroyer> any other reviews?
19:18:04 <navidp> dtroyer, sure and thanks
19:18:15 <singhj> https://review.openstack.org/#/c/273670/
19:18:43 <rtheis> singhj: I plan to take a look today
19:18:49 <singhj> just need to get this signed off on soon , 'port list' and 'port set' depend on it
19:18:56 <singhj> rtheis: thanks
19:19:08 <rtheis> Last I checked it look pretty good
19:19:19 <rtheis> yw
19:19:27 <brad_behle> https://review.openstack.org/#/c/279273/
19:19:30 <rtheis> any specific concerns?
19:19:38 <dtroyer> I had not gotten back to that one today yet…
19:19:38 <rtheis> singhj ^
19:19:56 <singhj> rtheis: nothing from me
19:20:00 <rtheis> ok
19:20:09 <dtroyer> singhj: will do after a bit, it was just details left for me
19:20:26 <brad_behle> rtheis already has reviewed the one I just posted and +2'd it, and at least one other patch depends on it so I was hoping to merge it today.
19:20:36 <singhj> dtroyer: cool, thanks
19:21:05 <rtheis> brad_behle: thanks for making those changes
19:21:42 <dtroyer> brad_behle: I don't think I've looked at it closely yet, will add to the list
19:22:09 <brad_behle> rtheis: thanks for the reviews, that subnet create has taken a while, a lot of parms to get right and documented
19:22:15 <brad_behle> dtroyer: thanks!
19:22:33 <dtroyer> creates are often hard like that…
19:22:41 * dtroyer started with server create back in the day
19:23:08 <rtheis> no other reviews from me
19:23:27 <dtroyer> I wanted to bring up https://review.openstack.org/#/c/284708/
19:23:39 <dtroyer> one question I have is about adding a 'backup' action
19:24:08 <dtroyer> we already have it as an object name
19:24:23 <dtroyer> also, I'm not aure how this differs from server image breate
19:24:38 <dtroyer> (aside from the obvious calls-a-different-manager-method)
19:25:29 <dtroyer> I am wondering if anyone else things having an object and action with the same name might be confusing
19:25:46 <dtroyer> also, 'server backup' is actually what is being created:  server backup create
19:25:58 <rtheis> good question ... I do think it is confusing
19:26:20 <dtroyer> the existing 'bakcup' object may need to be qualified too…I think it is a volume now?
19:26:50 <rtheis> right
19:27:27 <dtroyer> ok,  any other reviews?
19:27:28 <rtheis> I'll add this one to the review list
19:28:18 <dtroyer> #topic bugs
19:28:26 <dtroyer> How about bugs that need attention?
19:28:58 <rtheis> https://bugs.launchpad.net/python-openstackclient/+bug/1543335
19:28:59 <openstack> rtheis: Error: malone bug 1543335 not found
19:29:42 <rtheis> I think this is a security bug that is private
19:30:40 <dtroyer> it is, the question is who determines the default interface to use in that case?
19:30:45 <dtroyer> could be ksc?
19:30:51 <rtheis> yeah
19:31:13 <dtroyer> also, we don't have security bugs in this fashion normally because there is nothing that OSC does that can'tbe done with curl
19:31:19 <rtheis> I wanted to run it by stevemar  too
19:31:22 <rtheis> yep
19:31:24 <dtroyer> API-wise anyway
19:31:49 <rtheis> maybe filed against wrong project
19:32:19 <dtroyer> well, it's logical to start with the thing you are using…we need to decide if it's OSc or ksc chosing which interface to use
19:32:27 <dtroyer> by default
19:32:54 <rtheis> sure
19:33:22 <dtroyer> any other bugs?
19:34:03 <rtheis> nothing else
19:35:59 <dtroyer> #topic open discussion
19:36:06 <dtroyer> What is on your minds?
19:36:09 <rtheis> human vs machine readable output: https://bugs.launchpad.net/python-neutronclient/+bug/1524624  and https://review.openstack.org/#/c/281501/
19:36:10 <openstack> Launchpad bug 1524624 in python-neutronclient "result should not be changed by column formatter when JSON/YAML format is specified" [Low,Won't fix] - Assigned to Akihiro Motoki (amotoki)
19:36:47 <rtheis> sounds like cliff 2.0 has some features to address this
19:37:03 <rtheis> I know we do a lot of formatting dicts and lists when showing or listing resources
19:37:20 <dtroyer> it does?  I just proposed a flag to cliff for marking formatters as machine-parsable or not
19:37:38 <dtroyer> did I miss something already there?
19:37:58 <dtroyer> https://review.openstack.org/#/c/287536/
19:38:33 <dtroyer> I think we go ahead with Brandon's fix for now though…although that hard-coded table name is ugly
19:39:09 <dtroyer> aaaaand…this is something that we should extend to all of the other areas we re-format returned data from the responses
19:39:25 <rtheis> ok
19:39:40 <dtroyer> but not yet…not with a hard-coded name in it
19:40:27 <rtheis> how do we extend this ?  sorry I'm a little slow to catch up on this
19:41:00 <dtroyer> many other commands re-format returned dicts and lists for output to de-pythonize them
19:41:01 <rtheis> define our formatters as not human readable?
19:41:13 <dtroyer> that is part a, yes
19:41:27 <dtroyer> part b is checling for machine-parsable in the commands themselves
19:41:36 <rtheis> ok
19:41:49 <rtheis> should I open a bug for this or blueprint?
19:42:41 <dtroyer> your choice.  if you want to make a list and track progress against it that is easier to do as a bp
19:43:17 <rtheis> we would need cliff 2.0 or later too?
19:43:51 <dtroyer> whenever my proposed review is merged and released, yes
19:44:15 <rtheis> ok, I'll get a bp opened
19:44:58 <navidp> dtroyer, about ksa admin token class, it will return a token endpoint plugin_class at https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/loading/_plugins/admin_token.py#L19-L21
19:45:26 <navidp> regardin the comment https://review.openstack.org/#/c/276350/9/openstackclient/api/auth_plugin.py
19:45:40 <navidp> or I make a mistake here ?
19:46:03 <dtroyer> my point is simply that ksa doesn't have a class that does the right thing for us, we have to make it ourselves.
19:46:18 <navidp> dtroyer, ok got it
19:46:21 <dtroyer> because we have existing behaviour that ksa doen't want to handle
19:46:35 <navidp> correct
19:47:43 <rtheis> On a related note to output formatting ... https://review.openstack.org/#/c/287005/ ... is the osc output compatibility promise for column and field names only?
19:48:29 <dtroyer> at one point (long ago) I said that there was no promise regarding output at all
19:48:38 <dtroyer> now we can't go that far
19:49:06 <dtroyer> I'm torn, but column names do get used in scripts, etc as -c arguments so we should at least make note of them
19:49:28 <rtheis> ok
19:50:10 <dtroyer> ok, if there isn't anything else, I'll close before stevemar comes and makes us listen to the Blue Jay's spring training woes
19:50:20 <rtheis> :)
19:50:22 <rtheis> nothing else
19:50:34 <navidp> :)
19:50:38 <MeganR> I'm good - please close  :)
19:50:38 <rtheis> I say go Twins
19:51:15 <dtroyer> do I have to send you a world series shirt too rtheis?
19:52:02 <dtroyer> ok, thanks everyone!
19:52:04 <rtheis> sure `87 or `91 world series would be awesome :)
19:52:06 <rtheis> thanks
19:52:08 <dtroyer> #endmeeting