19:03:04 <dtroyer> #startmeeting openstackclient
19:03:05 <openstack> Meeting started Thu Jan 21 19:03:04 2016 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:08 <openstack> The meeting name has been set to 'openstackclient'
19:03:10 <stevemar> hehe
19:04:22 <stevemar> dtroyer: i am swamped with keystoney mitaka-2 stuff
19:04:28 <dtroyer> courtesy ping: dhellmann, terrylhowe, lhcheng, dstanek, MeganR
19:04:34 <stevemar> dtroyer: you reviewed a whole bunch of stuff last week
19:04:45 <dtroyer> stevemar: sure.  I really don't have much new anyway
19:04:47 * dhellmann sits in the back of the room to listen
19:05:48 <dtroyer> I think getting to the next release point WRT network commands is still the priority
19:06:24 <dtroyer> is terry out this week?  I haven't seen him in IRC for a while
19:07:23 <stevemar> dtroyer: probably, haven't seen much of him either
19:07:37 <dtroyer> this may be quick…  I'll wait a few more minutes then call it if no one else shows
19:09:13 <stevemar> dtroyer: terry *just* reviewed a patch
19:09:28 <stevemar> :)
19:09:40 <lhcheng_> o/
19:09:44 <rtheis> sorry, I'm late
19:09:46 <rtheis> o/
19:10:01 <stevemar> welcome welcome
19:10:06 <dtroyer> ooooh, youse guys were close… I almost called it a day ;)
19:10:07 <stevemar> sit in the front row
19:11:21 <dtroyer> ok, well we've got a few here, this still may be short
19:11:34 * dstanek is lurking
19:11:59 <dtroyer> aha!  another keystone dev ;)  this is good as the one thing I wanted to ask about is connected to KSC
19:12:20 <dtroyer> #topic bugs
19:12:38 <dtroyer> going through some older bugs i came across https://bugs.launchpad.net/python-openstackclient/+bug/1391116
19:12:40 <openstack> Launchpad bug 1391116 in python-openstackclient "password prompts should check for empty string" [Medium,Confirmed] - Assigned to Tang Chen (tangchen)
19:12:43 <stevemar> dtroyer: we're everywhere
19:13:03 <stevemar> dtroyer: i asked tangchen to open that bug
19:13:23 <dtroyer> I'm curious why thedata validation shouldn;t be in the KSC python lib rather than in OSC
19:13:30 <stevemar> the issue is worse when shown in OSC
19:13:57 <stevemar> so in OSC and KSC, on a user create and update call, you can set the password to be ""
19:14:10 <dtroyer> right.  is that valid?
19:14:29 <stevemar> dtroyer: we have no requirements about passwords
19:14:36 <dtroyer> ok, so it is valid
19:14:42 <dtroyer> but apparently it is unusable?
19:14:49 <stevemar> the issue crops up on authentication
19:14:59 <dtroyer> right.  should it work with an empty password?
19:15:18 <lhcheng_> fwiw, we made password mandatory field in horizon, it can't be empty.
19:15:30 <dtroyer> good to know
19:15:31 <stevemar> so i *think* this works if you do a straight REST call to keystone and authenticate
19:15:42 <stevemar> and i think it works with KSC using auth plugins
19:15:57 <stevemar> but if you set OS_PASSWORD="" for OSC, it fails
19:16:06 <dtroyer> is that the real bug then?
19:16:07 <stevemar> i might be mis-remembering ...
19:16:28 <stevemar> i'm not sure, i asked him to log the bug so we could chat about it here
19:16:30 <dtroyer> I think I have always assumed that empty password was not valid
19:16:55 <stevemar> so whats the harm in preventing an empty password for create and update?
19:17:10 <dtroyer> I don't know there is any other than really bad practice
19:17:26 <dtroyer> or we could take the Horizon position and decide it is not allowd
19:17:52 <stevemar> could
19:17:53 <dtroyer> it sounds as if KSC has stated it will not prevent empty passwords
19:18:02 <dtroyer> is stating
19:19:08 <dtroyer> ok, so I think I understand now
19:19:30 <dtroyer> Horizon has decided to not accept empty passwords
19:19:47 <dtroyer> Keystone and KSC allow them and are not going to prevent them
19:19:57 <stevemar> that sums it up
19:20:18 <dtroyer> so it is up to OSC to decide what to do: fix OS_PASSWORD="" or disallow empty passwords
19:20:42 <dtroyer> opinions anyone?
19:20:51 <dtroyer> I can argue both sides
19:21:03 <lhcheng_> one of OSC's goal is to improve usability, sounds like making password required achieve that goal?
19:21:23 <lhcheng_> allowing empty password would just cause headache for users.
19:21:39 <clarkb> seems like that should be decided by the api
19:21:41 <MeganR> is there a use case for allowing empty paswords?
19:21:41 <dtroyer> the danger there is say another app sets an empty password, we could be getting in the way of that being usable
19:21:47 <clarkb> if empty passwords are a problem fix it in the api
19:21:58 <dtroyer> clarkb: that's my thinking
19:22:07 <lhcheng_> dtroyer: good point
19:23:08 <dtroyer> so it sounds like we should fix OSC to accept empty passwords for auth?
19:23:27 <stevemar> cause right now, i can do `os user create bob` and it works for v3 https://github.com/openstack/python-openstackclient/blob/master/openstackclient/identity/v3/user.py
19:24:02 <stevemar> but bob will never be able to authenticate now :(
19:25:05 <dtroyer> right.  ok, I'll clarify the bug so I don't forget this conversation…
19:25:27 <lhcheng_> a use case I could think of where empty password would happen is during a enterprise user account creation workflow, the account could be created by an admin with empty password. then on user logging on first time (passing a nonce), they are prompted for the password.
19:25:44 <dtroyer> even though this is different than Horizon, it is more permissive
19:25:52 <dtroyer> lhcheng_: good example
19:26:10 <lhcheng_> but that's too custom of a use case.. something we did for the public cloud.
19:26:37 <MeganR> @lhcheng: thank you
19:27:53 <dtroyer> bug updated
19:28:04 <dtroyer> any other bugs anyone wants to talk about?
19:28:41 <stevemar> dtroyer: there was one about trusts...
19:29:09 <stevemar> dtroyer: i filed it last week: https://bugs.launchpad.net/python-openstackclient/+bug/1535190
19:29:10 <openstack> Launchpad bug 1535190 in python-openstackclient "cannot use trust based authentication with osc" [Undecided,New]
19:29:22 <dtroyer> yes
19:29:31 <stevemar> i think it's partly related to https://bugs.launchpad.net/python-openstackclient/+bug/1533369
19:29:32 <openstack> Launchpad bug 1533369 in python-openstackclient "moving authentication from keystoneclient to keystoneauth" [High,Confirmed] - Assigned to Navid Pustchi (npustchi)
19:29:32 <dtroyer> do you have an idea of what needs to be done there?
19:30:00 <stevemar> dtroyer: i think it comes down to untangling the osc-ksa-occ mess
19:30:29 <dtroyer> I'm regretting occ now, fwiw
19:31:24 <stevemar> dtroyer: there is at least one little bit we can fix, that's to allow TRUST_ID as a scope, in addition to PROJECT and DOMAIN
19:31:54 <stevemar> after that, i'm not sure whats going on, it seems like the scope isn't being set, so i get an empty catalog
19:32:53 <dtroyer> does that come from the env/CLI/clouds.yaml?
19:33:07 <stevemar> dtroyer: the trust id?
19:33:10 <dtroyer> yes
19:33:21 <stevemar> dtroyer: think of it as an alternate to project_id
19:33:25 <stevemar> so it'll come from CLI/env
19:33:52 <dtroyer> ok
19:35:26 <stevemar> dtroyer: just wanted to bring it to the groups attention, i don't know when i can work on it
19:36:05 <dtroyer> np, it helps me understand how we handle trusts
19:36:12 <dtroyer> any other bugs?
19:37:13 <dtroyer> #topic reviews
19:37:17 <dtroyer> how about reviews?
19:37:41 <stevemar> i've been neglecting reviews
19:37:45 <stevemar> did the logging one land?
19:38:12 <dtroyer> I think I said something and Akihiro abandoned them
19:38:42 <lhcheng_> Akihiro have a new patch up, I haven't got the chance to browse through it
19:38:47 <dtroyer> well, the three bulk update ones
19:39:40 <stevemar> abandoned?
19:39:42 <stevemar> hmm
19:39:51 <lhcheng_> https://review.openstack.org/#/c/269613/ this is the new one
19:40:06 <dtroyer> yeah, I haven't looked at it yet either
19:41:02 <dtroyer> I may jump on https://review.openstack.org/84782 to get it in
19:41:33 <stevemar> wow thats an early number
19:41:53 <dtroyer> I think it was from is original set of commands
19:42:07 <stevemar> dtroyer: do it up
19:43:25 <dtroyer> it looks like https://review.openstack.org/258519 got stuck last week, although I'm not sure we need to hold up the release for it fi it isn't ready
19:44:14 <rtheis> yeah, that is behind https://review.openstack.org/#/c/257543/
19:44:39 <dtroyer> ah, ok
19:44:40 <rtheis> for the refactor of existing network commands over to neutron
19:45:21 * dtroyer re-reads the last comment in 257543
19:46:07 <dtroyer> FWIW we have historically erred on the side of simplicity and duplicated code
19:46:46 <rtheis> thanks, good to know
19:47:05 <dtroyer> I'd like to do a release next week if possible, do we need to wait for this?
19:47:33 <rtheis> I don't think we do
19:47:42 <dtroyer> ok
19:48:17 <dtroyer> any other reviews?
19:50:13 <rtheis> I have a couple on moving availability zones to common: https://review.openstack.org/#/c/267598/ and https://review.openstack.org/#/c/267061/
19:50:50 <dtroyer> one more: https://review.openstack.org/#/c/259595/  stevemar, you had previously +2 it but a couple of changes were made that I don't want to just push it in...
19:52:00 <stevemar> hmm?
19:52:15 <stevemar> oh, i wanted to test it out
19:52:16 <dtroyer> rtheis: right.  I'll give them a look this afternoon, I don't see anything worrisome at a quick glance
19:52:23 <stevemar> one reviewer had a good point
19:52:33 <rtheis> dtroyer: thank you
19:52:35 <stevemar> dtroyer: you fix that thing gongysh mentioned?
19:52:45 <stevemar> where he got the error even after using --project
19:53:18 <dtroyer> yes, I believe I did
19:53:31 <stevemar> awesome
19:53:33 <stevemar> i see it now
19:53:58 <dtroyer> I duplicated it and fixed it for me, but my setup isn't the most representative
19:54:25 <stevemar> dtroyer: too late now, i +W'ed!
19:54:38 <dtroyer> :)
19:54:56 <dtroyer> any others?
19:56:00 <dtroyer> #topic open discussion
19:56:10 <dtroyer> 5 minutes, what is on your mind?
19:57:04 <lhcheng_> we got a new customer, searchlight is developing an osc plugin
19:57:58 <dtroyer> cool
19:57:59 <lhcheng_> dtroyer: do we have a doc/ guideline for resource namespacing?
19:58:20 <dtroyer> I recall writing a bit on that, I think it's in the docs
19:58:51 <lhcheng_> they had dash on their resource name, I asked them to fix that.  I can't find a reference where we don't recommend that.
19:59:48 <dtroyer> now I am curious where I put that stuff
19:59:55 <dtroyer> I don't see it in the repo docs
20:00:15 <stevemar> dtroyer: in the ether
20:00:31 <stevemar> dtroyer: -> #endmeeting
20:00:39 <dtroyer> #endmeeting