18:00:03 <lbragstad> #startmeeting keystone
18:00:03 <openstack> Meeting started Tue May 30 18:00:03 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:07 <openstack> The meeting name has been set to 'keystone'
18:00:07 <lbragstad> ping ayoung, breton, cmurphy, dstanek, edmondsw, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, notmorgan, rderose, rodrigods, samueldmq, spilla, aselius
18:00:11 <hrybacki> o/
18:00:12 <rodrigods> o/
18:00:12 <gagehugo> o/
18:00:16 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:00:19 <lbragstad> agenda ^
18:00:21 <lbragstad> o/
18:00:32 <lbragstad> how is everyone?
18:00:34 <edmondsw> o/
18:00:38 <raildo> o/
18:00:45 <gagehugo> weekend was too short
18:00:47 <samueldmq> hi all
18:00:50 <lbragstad> gagehugo: ++
18:00:54 <samueldmq> gagehugo: need more? :)
18:01:15 <gagehugo> samueldmq it would be nice
18:01:52 <lbragstad> #topic announcements
18:02:00 <lbragstad> #info spec freeze is next week
18:02:22 <lbragstad> for reference this is what we have committed for specs this release
18:02:25 <lbragstad> #link http://specs.openstack.org/openstack/keystone-specs/
18:02:27 <knikolla_phone> O/
18:03:13 <lbragstad> we have several others in review - so this week is our last week for the final push without requiring a spec freeze exception
18:03:36 <lbragstad> does anyone have questions on specs that have been merged or are in flight?
18:04:43 <lbragstad> we will need reviews on the unified limits spec
18:04:46 <lbragstad> #link https://review.openstack.org/#/c/455709/
18:04:54 <ayoung> kill it
18:05:02 <ayoung> impossible to implement
18:05:07 <ayoung> will cause world famine
18:05:50 <lbragstad> we also have the API key/application specific password one in flight yet
18:05:52 <lbragstad> #link
18:05:54 <lbragstad> #link https://review.openstack.org/#/c/450415/
18:06:06 <ayoung> http://adam.younglogic.com/2017/05/why-quotas-are-hard/
18:07:33 <lbragstad> that's about all i have for specs
18:07:56 <hrybacki> crickets love specs
18:08:13 <lbragstad> #topic outreachy program starts today
18:08:13 <samueldmq> lbragstad: api-key + limits?
18:08:24 <ayoung> so we are punting on RBAC in middleware?
18:08:34 <samueldmq> there is also the policy ones correct, I saw you have a few outlining that
18:09:04 <lbragstad> samueldmq: two of those are general documents
18:09:12 <lbragstad> samueldmq: that don't really tie to any work
18:09:22 <samueldmq> lbragstad: neat
18:09:31 <lbragstad> samueldmq: the third is the one that would require some work for us, but i realize it's late
18:10:35 <lbragstad> as far as the RBAC in middleware - we're missing feedback from other projects
18:11:04 <lbragstad> unless johnthetubaguy is around?
18:12:19 <ayoung> you are never going to get it
18:12:40 <ayoung> once people understand a problem, they jump right to implementing their own, service specific solution
18:12:51 <ayoung> best to just leave them out of it and solve the problem for them
18:13:15 <lbragstad> ayoung: let come back to this in open discussion
18:13:18 <lbragstad> rodrigods: o/
18:13:31 <rodrigods> hey everyone
18:13:47 <rodrigods> so the new round for the outreachy program starts today
18:13:54 <rodrigods> and we have an awesome intern, lwanderley
18:13:55 <lbragstad> sweet!
18:14:03 <lwanderley> hi, everyone :)
18:14:07 <lbragstad> lwanderley: o/
18:14:08 <rodrigods> she will be working in the LDAP integration tests
18:14:09 <hrybacki> o/
18:14:10 <knikolla> lwanderley: o/
18:14:11 <samueldmq> lwanderley: welcome aboard
18:14:16 <rodrigods> finally addressing this for us
18:14:26 <hrybacki> can we get context -- one liner on the outreachy program (sorry if everyone else already knows)
18:14:31 <gagehugo> lwanderly o/
18:14:36 <lbragstad> hrybacki: ++ good question
18:14:37 <samueldmq> that's great, also remember we have sjain who will be working on docs
18:15:13 <raildo> hrybacki, https://wiki.openstack.org/wiki/Outreachy
18:15:27 <rodrigods> me and raildo are going to mentor her in the project
18:15:35 <knikolla> rodrigods: have we decided what ldap backend we're using for the integration tests?
18:15:39 <samueldmq> #link https://gnome.org/outreachy/
18:15:40 <hrybacki> ahh, wonderful. Thanks raildo rodrigods
18:15:47 <raildo> hrybacki, it's an intern program from OpenStack and other Open Source projects :)
18:15:54 <rodrigods> knikolla, open ldap for now (it is the current plugin devstack provides)
18:16:01 <lbragstad> ++
18:16:19 <lbragstad> rodrigods: lwanderley the openstack-ansible folks are looking to do something similar for their gate
18:16:29 <rodrigods> lbragstad, awesome
18:16:31 <lbragstad> (standup keystone with open ldap to test with)
18:16:42 <samueldmq> devstack does support setting up ldap to a certain degree, doesn't it ?
18:16:59 <rodrigods> the project is a really cross-project effort and will involve lots work in keystone, devstack and possibly tempest
18:17:16 <lbragstad> it might be worthwhile to check in with that group
18:17:20 <ayoung> samueldmq, it did at one point
18:17:32 <knikolla> samueldmq: yes. anybody confirms that it still works? i don't think that piece of code has been touched in over a year.
18:17:41 <rodrigods> knikolla, it is currently broken
18:17:45 <samueldmq> ayoung: ah cool, I had the impression there was something in there (not sure it worked)
18:17:51 <rodrigods> will be lwanderley first task to fix it :)
18:18:00 <lbragstad> looks like the library is still there - https://github.com/openstack-dev/devstack/blob/dec121114c3ea6f9e515a452700e5015d1e34704/lib/ldap
18:18:04 <knikolla> rodrigods: ok, cool!
18:18:18 <knikolla> lwanderley: good luck
18:18:18 <ayoung> should be set up as part of the keystone gate job if we don't want it to break again
18:18:38 <rodrigods> ayoung, absolutely
18:18:43 <raildo> ayoung, ++
18:18:45 <rodrigods> that's the idea
18:18:50 <lbragstad> ayoung: that's exactly what openstack ansible wanted to help us with during the PTG in Atlanta
18:19:08 <knikolla> rodrigods: still leaving the code in devstack, or splitting it out as part of our devstack plugin?
18:19:25 <ayoung> fix the devstack one first
18:19:29 <ayoung> always work from success
18:19:39 <ayoung> move it to Keystone as step 2
18:19:44 <rodrigods> knikolla, what ayoung said :)
18:19:51 <knikolla> +1
18:19:56 <lbragstad> fwiw - we will be splitting out our tempest plugin into it's own repository next release https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
18:19:58 <lbragstad> #link https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
18:20:05 <rodrigods> lbragstad, ++
18:20:13 <raildo> ayoung, should be a mentor with us, haha
18:20:39 <samueldmq> lbragstad: that's great
18:20:48 <ayoung> raildo, Qui ducis super ducis?
18:21:25 <ayoung> Qui docent doctores?
18:21:27 <ayoung> meh
18:21:32 <ayoung> Who mentors the mentors?
18:22:13 <knikolla> it's turtles… ehmm… mentors all the way down
18:22:53 <ayoung> https://aptira.com/wp-content/uploads/2017/04/openstack_keystone-1.png
18:23:00 <lbragstad> rodrigods: raildo lwanderley don't hesitate to ping me if you need anything
18:23:13 <raildo> lbragstad, thanks :)
18:23:14 <rodrigods> be certain that we will
18:23:38 <lbragstad> rodrigods: cool, anything else on the outreachy front?
18:23:41 <lwanderley> lbragstad: thanks :D
18:24:00 <lbragstad> lwanderley: thanks helping out!
18:24:04 <lbragstad> thanks for*
18:24:14 * lbragstad can't type after holiday s
18:24:19 <rodrigods> heh
18:24:24 <lbragstad> moving on
18:24:28 <lbragstad> #topic open discussion
18:24:31 <lbragstad> floor is open
18:25:56 <clarkb> I'm trying to go through e-r's uncategorized bugs and classify them today and ran across an itneresting thing with grenade + keystone
18:26:08 <lbragstad> clarkb: o/
18:26:13 <clarkb> tempest times out to keystone logged at http://logs.openstack.org/36/458636/16/gate/gate-grenade-dsvm-neutron-ubuntu-xenial/5f07eaa/logs/tempest.txt.gz?level=DEBUG#_2017-05-23_19_00_51_098
18:26:26 <clarkb> then in the keystone log we find that that user isn't found http://logs.openstack.org/36/458636/16/gate/gate-grenade-dsvm-neutron-ubuntu-xenial/5f07eaa/logs/apache/keystone.txt.gz?level=WARNING#_2017-05-23_19_01_18_408
18:26:51 <clarkb> possible upgrade/migration bug?
18:27:00 <clarkb> in any case would be good if keystone could look into it a bit more
18:27:15 <lbragstad> clarkb: cool - is there a current bug open?
18:27:47 <clarkb> no thats as far as I have gotten
18:27:56 <lbragstad> ok
18:28:39 <lbragstad> is anyone interested in taking a poke at this?
18:29:02 <ayoung> nope
18:29:22 <ayoung> So, back to my question
18:29:49 <lbragstad> clarkb: i'll set aside some time later to look into it. I'll probably open a bug to track stuff for now though
18:30:08 <ayoung> is Keystone abdicating its responsibity to implement a reasonable RBAC solution?
18:30:36 <lbragstad> clarkb: but thanks for bringing this to us
18:30:38 <ayoung> Do we really have an obligation to do any more begging for feedback from people that have shown they do not care?
18:30:54 <lbragstad> ayoung: no
18:31:06 <ayoung> OK, then approve the dang spec.
18:31:14 <lbragstad> several folks have expressed concerns with the approach
18:31:21 <ayoung> Or provide a better viable spec
18:31:42 <morgan> providing actionable requests is important
18:31:51 <morgan> if the concerns are actually blocking the approval
18:32:07 <lbragstad> and it's something that impacts projects, getting their opinion and buy in is important if the approach is going to be successful
18:32:08 <morgan> if they are "I dunno, this looks wrong", we can't hold things up on that
18:32:23 <lbragstad> i know i had concerns on the upgrade approach
18:32:29 <ayoung> they have built broken policy based on Keystone not providing the appropriate tools
18:32:36 <ayoung> we need to fix 968696
18:32:39 <lbragstad> sure
18:32:41 <ayoung> and we need RBAC in middleware
18:32:45 <morgan> as long as they are actionable "hey, upgrade needs to be more clear because X, how dow e do that"
18:32:47 <morgan> that is reasonable
18:32:47 <ayoung> and both have been laid out
18:32:50 <lbragstad> two separate but related things
18:32:50 <ayoung> and both are sitting there
18:33:27 <morgan> and we should demand improvement to the spec.
18:33:32 <morgan> but again if it is "i don'
18:33:37 <morgan> t like this" or #bikeshed
18:33:53 <morgan> i'll support approving as long as the main concerns that are actionable are addressed/not still an issue
18:33:56 <morgan> ayoung: is that fair?
18:34:02 <morgan> lbragstad: ^ same question to you
18:35:05 <lbragstad> There was a ton of feedback on the spec after it merged
18:35:07 <lbragstad> #link https://review.openstack.org/#/c/391624/
18:35:22 <lbragstad> I'd like to make sure those things are addressed, along with the upgrade case
18:35:40 <morgan> that souinds pretty specific/directed
18:35:49 <morgan> especially the questions on the upgrade case(s)
18:36:19 <ayoung> upgrade was answered several times
18:36:26 <lbragstad> ayoung: where?
18:36:38 <edmondsw> I remember being upset when it merged because a bunch of comments hadn't been addressed yet
18:36:38 <lbragstad> what happens if a project changes a policy and upgrades
18:36:43 <ayoung> lbragstad, in the weekly policuy discussion, and with an update doc
18:36:58 <edmondsw> so it's not just post-merge comments
18:37:27 <ayoung> we need a better way to do new development
18:37:31 <ayoung> this is not workable
18:37:41 <lbragstad> the default route?
18:37:47 <lbragstad> which is in keystone database
18:38:03 <ayoung> lbragstad, I think I can link directly...
18:38:12 <lbragstad> could be completely different from the default registered in a service
18:38:24 <lbragstad> there is nothing keeping the two defaults in sync
18:39:32 <lbragstad> if new policies are added to the service (which are added to the default policies in code) how do we ensure those are added to keystone new API for storing all that data?
18:40:07 <lbragstad> I can't see how that is going to be pleasant for operators to handle anyway I look at it (but I'll defer to operator opinion here, too)
18:40:49 <ayoung> lbragstad, short answer is, we start by defaulting to services continue to enforce "Admin required" in policy.  Default rule would be "Member".  Once we can clean up Admin in policy, we make the default rule "Admin"
18:40:55 <ayoung> and I know I added that to the doc....
18:41:28 <ayoung> Ah...but I'm l;ooking at the old review...one sec
18:41:56 <lbragstad> Does the address the upgrade case?
18:42:15 <lbragstad> A lot of projects want to move towards fixing or improving default roles (introducing roles that make sense)
18:42:42 <lbragstad> we're going into this knowing that those changes are coming down the pipe
18:43:47 <ayoung> https://review.openstack.org/#/c/452198/8/specs/keystone/pike/role-check-from-middleware.rst  line 537 or so
18:44:12 <lbragstad> ayoung: yes - sure
18:44:30 <lbragstad> ayoung: but again, that's a blanket default that can be inconsistent from the default the service or project has implemented
18:44:31 <ayoung> If anyone touches Default roles without being a regular attendee of the Policy meetings they are in a state of sin
18:44:36 <ayoung> lbragstad, no
18:45:04 <ayoung> lbragstad, projects no longer get to say anything about roles
18:45:13 <ayoung> the role data is not their to touch
18:45:23 <ayoung> there is exactly one role they can depend on
18:45:25 <ayoung> and that is admin
18:46:03 <ayoung> the rest of it is data managed in the keystone database, and can be a huge array of anything
18:47:47 <lbragstad> that goes back to my cross-project communication bits, i don't see signoff for any of that
18:47:55 <ayoung> This is what Keystone is supposed to do.  I'm willing to entertain alternate approaches to solve it, but solutions need to be applicable across all the projects.
18:48:04 <ayoung> nova does not get to Veto
18:48:27 <lbragstad> ayoung: have you talked to the other core services yet?
18:48:31 <ayoung> yes
18:48:33 <ayoung> endlessly
18:48:35 <ayoung> for years
18:48:38 <ayoung> including recently
18:48:42 <lbragstad> ayoung: about *this* specifically
18:48:47 <lbragstad> how this affects them
18:48:55 <lbragstad> and what this means for their project
18:49:20 <ayoung> you mean beside scheduling a full session about it at the Openstack summit and have it filled with Keystone plus 1 or 2 others?
18:49:31 <ayoung> You mean other than all the effort you know I have put in to this?
18:50:01 <lbragstad> ayoung: I'm not questioning your effort, i'm looking for buy in from the other projects that this won't be another failed attempt
18:50:21 <ayoung> lbragstad, this will not be a failed attempt because it bypasses their approval
18:50:31 <ayoung> it does in middleware what it should be doing./
18:50:43 <ayoung> Note sdagues comment on the 968696 wtyuff...
18:51:17 <ayoung> "so, I don't really understand why we would leak through this implementation detail on is_admin_project to Nova instead of having keystonemiddleware and oslo.context process the abstraction for us."
18:51:29 <ayoung> they want the solution to be in middleware
18:51:41 <ayoung> if we could solve 968696 in middleware, they would be happier
18:51:43 <ayoung> and so would I
18:52:02 <ayoung> why, then, should we shirk our responsibilituy on RBAC
18:52:12 <ayoung> which is totally a Keystone Kreation?
18:53:18 <ayoung> referenced comments here https://review.openstack.org/#/c/384148/
18:54:18 <lbragstad> ayoung: what sdague is saying there is why don't we have oslo.context process the is_admin_project bits for us, not do the middleware role check
18:55:06 <ayoung> lbragstad, please give me more credit than that, and more closely read what I wrote.
18:55:23 <ayoung> I know exactly what he was asking for there.  And I was explicitly extrapolating.
18:55:29 <lbragstad> ayoung: the reason why i say that is because he left the same response here - http://lists.openstack.org/pipermail/openstack-dev/2017-May/117534.html
18:56:34 <ayoung> regardless of what we call it, policy needs to know about it at the scope check level
18:56:47 <ayoung> we could call it godmode and it would make no difference
18:56:52 <ayoung> it can't be done in middleware
18:57:12 <lbragstad> ayoung: regardless - i can take an action item to follow up with him to get clarification
18:57:24 <lbragstad> because it sounds like we're talking about two different interpretations
18:57:29 <ayoung> go for it
18:57:41 <lbragstad> #action lbragstad to follow up with sdague about comments on https://review.openstack.org/#/c/384148/
18:58:00 <ayoung> I'm done.  I'm going to let you drive this.
18:58:17 <lbragstad> alright - we have a couple minutes left
18:58:21 <ayoung> Call me if you need clarification
18:58:21 <lbragstad> anyone else have anything?
18:58:28 <lbragstad> ayoung: will do, thanks
18:59:35 <hrybacki> looks like that's it
18:59:50 <lbragstad> yep - thanks for coming
18:59:54 <lbragstad> #endmeeting