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