18:00:19 <lbragstad> #startmeeting keystone 18:00:21 <openstack> Meeting started Tue Apr 25 18:00:19 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:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:25 <openstack> The meeting name has been set to 'keystone' 18:00:35 <gagehugo> o/ 18:00:41 <lbragstad> ping antwash, ayoung, breton, cmurphy, dstanek, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, notmorgan, ravelar, rderose, rodrigods, samueldmq, spilla 18:00:45 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting 18:00:47 <spilla> o/ 18:00:48 <lbragstad> agenda ^ 18:00:50 <lamt> o/ 18:00:52 <hrybacki> o/ 18:00:58 <rodrigods> o/ 18:01:16 <samueldmq> hi 18:01:46 <cmurphy> o/ 18:01:50 <edmondsw> o/ 18:01:52 <lbragstad> we'll give it a minute for some others to show up 18:03:22 <lbragstad> ok 18:03:25 <lbragstad> #topic mascot 18:03:33 <lbragstad> based on feedback from a couple developers 18:03:41 <lbragstad> the foundation did another revision of the mascot 18:03:41 <dstanek> o/ 18:03:42 <lbragstad> #link http://lists.openstack.org/pipermail/openstack-dev/2017-April/115869.html 18:04:06 <lbragstad> now we need to decide whether or not we want to stick with the original or formally adopt the new on 18:04:07 <lbragstad> one* 18:04:17 <rodrigods> i like the first one 18:04:20 <rodrigods> https://drive.google.com/file/d/0B5G9bO9bw3ObeHk4RG1MS1Zfak16cDdtWjlqUlBlRDRQTUZn/view 18:04:27 <dstanek> does he have a name? 18:04:30 <henrynash> (slinks in the back door) 18:04:37 <dstanek> "roadkill turtle" 18:04:44 <samueldmq> henrynash: o/ 18:04:59 <dstanek> henrynash! 18:05:05 <henrynash> :-) 18:05:10 <lbragstad> ok - maybe a better question is do we want to adopt either of the new revisions or do we want to stick with the original? 18:05:57 <samueldmq> well, we do have an original version 18:06:01 <lbragstad> right 18:06:05 <samueldmq> and newer version doesn't look that different 18:06:20 <rodrigods> lbragstad, do you have the original version handy? 18:06:25 <samueldmq> some may like, some may not, we don't want to bikeshed I think :-) 18:06:30 <lbragstad> no - the original version shaped the shell like a shield, which i thought was kinda cool, and that carried over to this version 18:06:33 <samueldmq> but a voting could be fair maybe 18:06:38 <henrynash> I’m ok with the one with the key in his shell (despite possibility of being had up for injury to protected species) 18:07:00 <lbragstad> should we just vote? 18:07:02 <gagehugo> I like both of the revisions, I'm fine with either 18:07:05 <edmondsw> lbragstad I like either of the new ones better than the original 18:07:13 <rodrigods> +1 to just vote 18:07:18 <gagehugo> +1 18:07:21 <lamt> +1 18:07:25 <henrynash> vote! Oh Yes, like in teh UK we need anouther vote 18:07:33 <dstanek> i like them all equally. happy with any of them. 18:07:34 <henrynash> +1 18:07:50 <edmondsw> +1 18:08:04 <lbragstad> #startvote should we adopt the new mascot with a key 18:08:05 <openstack> Unable to parse vote topic and options. 18:08:07 <knikolla> o/ i'm late 18:08:18 <henrynash> yes 18:08:26 <dstanek> lbragstad: you have to give it the answers you expect 18:08:36 <lbragstad> what in the world is the syntax? 18:08:46 <cmurphy> #help startvote 18:08:50 <cmurphy> :( 18:09:13 <ayoung> Hello 18:09:42 <henrynash> #vote we pick a new voting bot technolgy 18:09:47 <lbragstad> lol 18:09:58 <cmurphy> lbragstad: https://docs.openstack.org/infra/system-config/irc.html#voting 18:10:02 <lbragstad> #startvote should we adopt the new mascot with a key in the shell? Yes, No 18:10:03 <openstack> Begin voting on: should we adopt the new mascot with a key in the shell? Valid vote options are Yes, No. 18:10:04 <openstack> Vote using '#vote OPTION'. Only your last vote counts. 18:10:12 <henrynash> #vote yes 18:10:24 <edmondsw> #vote Yes 18:10:27 <rodrigods> #vote yes 18:10:29 <cmurphy> #vote Yes 18:10:30 <ayoung> hold on, still looking... 18:10:30 <hrybacki> #vote Yes 18:10:34 <spilla> #vote Yes 18:10:38 <lamt> #vote Yes 18:10:42 <dstanek> #vote sure, why not 18:10:43 <openstack> dstanek: sure, why not is not a valid option. Valid options are Yes, No. 18:10:54 <henrynash> ayoung: the alternative is one with a dancing ardvark and a martini 18:11:04 <lbragstad> ooo i want *that* one 18:11:05 <dstanek> #vote yes 18:11:09 <lbragstad> #vote yes 18:11:24 <ayoung> henrynash, I'm not looking to disparage the artist, but my silly "Here's Stoney" looks better than both of them 18:11:29 <knikolla> #vote no 18:12:06 <ayoung> #vote Noneoftheabove 18:12:07 <openstack> ayoung: Noneoftheabove is not a valid option. Valid options are Yes, No. 18:12:22 <gagehugo> #vote Yes 18:12:22 <ayoung> #vote Sure Why Not 18:12:22 <openstack> ayoung: Sure Why Not is not a valid option. Valid options are Yes, No. 18:12:54 <ayoung> #vote yes 18:12:59 <breton> #vote yes 18:13:07 <lbragstad> anyone else? 18:13:20 <samueldmq> #vote no 18:13:27 <lbragstad> #endvote 18:13:27 <openstack> Voted on "should we adopt the new mascot with a key in the shell?" Results are 18:13:28 <openstack> Yes (12): rodrigods, spilla, dstanek, ayoung, edmondsw, gagehugo, hrybacki, cmurphy, lamt, lbragstad, henrynash, breton 18:13:29 <openstack> No (2): samueldmq, knikolla 18:13:51 <ayoung> https://twitter.com/admiyoung/status/789179752531668992/photo/1 18:13:55 <lbragstad> samueldmq knikolla is there something you'd like to see changed about the mascot? 18:14:15 <ayoung> https://twitter.com/admiyoung/status/794739330937982976/photo/1 18:14:42 <samueldmq> lbragstad: actually I like one of the new versions. the one with the small key, not the big one 18:14:54 <ayoung> You all mean keyhole, right? 18:15:05 <knikolla> lbragstad: well, the keystone is called keystone because it holds everything. the keyhole is redundant. 18:15:14 <ayoung> I was voting to change the keyhole to a key 18:16:05 <breton> lol 18:16:38 <lbragstad> it seems most folks are fine with the new version 18:16:53 <lbragstad> we should update the ML thread if there are specific changes you'd like to see made 18:17:02 <ayoung> I still think it should reference a bridge 18:17:09 <lbragstad> otherwise it would be nice to firm this up with the foundation so that it doesn't change again 18:17:20 <ayoung> with a keystone in the shell. Not just a keyhole 18:17:46 <lbragstad> at a certain point, i think we're going to start trying to incorporate too many things 18:17:48 <knikolla> ayoung: rather than e revision, that's a complete redesign. but i agree on the keystone. 18:18:01 <samueldmq> we should include all the other mascots in the shell 18:18:04 <samueldmq> lol 18:18:17 <ayoung> knikolla, well, I mean, if they actually asked the TEAM that the mascot represents they would have known that 18:18:36 <lbragstad> well - do be fair, they did 18:18:38 <ayoung> samueldmq, or stack a bunch of turtles on on top of another.... 18:18:50 <lbragstad> they asked us what we wanted and we said a "turtle" 18:18:53 <ayoung> lbragstad, and then ignored us outright? 18:19:02 <lbragstad> we provided no further details 18:19:03 <samueldmq> I like that recursivity 18:19:06 <ayoung> lbragstad, yes I did 18:19:15 <ayoung> I did two POCs which I just linked 18:19:47 <lbragstad> ayoung did you communicate those to the Foundation? 18:19:58 <ayoung> :) 18:20:00 <ayoung> Lets move on 18:20:33 <lbragstad> i'll leave the thread open for a week to gather feedback 18:20:38 <lbragstad> #link http://lists.openstack.org/pipermail/openstack-dev/2017-April/115869.html 18:20:50 <lbragstad> then i'll send out a poll to vote on the versions 18:20:56 <lbragstad> if we don't have feedback 18:21:10 <lbragstad> #topic open discussion 18:21:56 <lbragstad> does anyone have questions on the specs? 18:23:04 <lbragstad> samueldmq you had questions about stuff proposed to Pike? 18:23:14 <samueldmq> lbragstad: yes I did 18:23:25 <lbragstad> samueldmq go for it 18:23:26 <samueldmq> I wanted to check the team is in sync with our goals to Pike 18:23:43 <lbragstad> this is what we've accepted for Pike so far - http://specs.openstack.org/openstack/keystone-specs/ 18:23:45 <lbragstad> #link http://specs.openstack.org/openstack/keystone-specs/ 18:24:13 <lbragstad> i think gagehugo's spec for project tags is ready, i need to give it another review though 18:24:24 <samueldmq> lbragstad: so "Extend user API to support federated attributes" is basically the only one that has been accepted but not implemented correct? 18:24:41 <lbragstad> samueldmq there were patches in review but they didn't land 18:24:57 <lbragstad> policy-in-code is done and policy-docs is almost done 18:25:07 <samueldmq> lbragstad: ok, but from the not-yet-approved specs 18:25:10 <samueldmq> what aer we targetting? 18:25:22 <lbragstad> i would say 18:25:23 <lbragstad> #link https://review.openstack.org/#/c/431785/ 18:25:41 <lbragstad> and we need eyes on 18:25:42 <lbragstad> #link https://review.openstack.org/#/c/455709/ 18:25:43 <lbragstad> for sure 18:26:21 <samueldmq> lbragstad: nice 18:26:40 <samueldmq> lbragstad: that was basically my question 18:26:51 <lbragstad> i would expect those to get into Pike for sure, but I also think a lot of stuff is in limbo because of recent OSIC layoffs 18:27:20 <gagehugo> lbragstad: I think a couple security people were going to look at https://review.openstack.org/#/c/447139/ some time this week if they get the chance 18:27:24 <samueldmq> lbragstad: exactly, that's why I am asking too 18:27:31 <breton> we need to do something with the trusts issue 18:27:35 <lbragstad> gagehugo awesome 18:27:36 <samueldmq> to check if we needed to re-scope or something 18:27:49 <breton> the spec i proposed was -1d and no alternative was proposed 18:27:56 <samueldmq> just to make sure we keep moving 18:28:00 <dstanek> breton: which spec? 18:28:33 <lbragstad> samueldmq i expect the recent events to cause hiccups, but i'm not sure what the ramifications will be until more dust settles 18:28:45 <breton> https://review.openstack.org/#/c/437533/ 18:28:49 <breton> dstanek: ^ 18:29:18 <lbragstad> breton the immediate alternative from what I remember was to document things better 18:29:21 <samueldmq> lbragstad: ++ and to be honest, keystone has been suffering a lot with cuts lately. specially cores 18:29:22 <lbragstad> which should be done anyway 18:29:31 <samueldmq> I just want to help in any ways I can 18:29:58 <lbragstad> samueldmq right now that'd probably be spec reviews and policy documentation reviews :) 18:30:24 <samueldmq> lbragstad: nice! ah, and we will probably Outreachy have intern (s) this year again 18:30:34 <breton> lbragstad: sahara and other folks are still not happy :( 18:30:38 <samueldmq> from May-August iirdc 18:30:39 <rodrigods> 2, actually 18:30:41 <samueldmq> iirc 18:30:42 <rodrigods> 2 interns 18:31:02 <samueldmq> rodrigods: yes, I've written intern(s) as I was not sure yours wass in keystone too, thanks 18:31:31 <rodrigods> samueldmq, cool 18:31:55 <rodrigods> the project i'm mentoring is the same for the last round 18:32:11 <samueldmq> nice 18:33:28 <samueldmq> lbragstad: alright, I think we can start from those and keep moving :) 18:33:36 <lbragstad> breton yeah - from what i remember we didn't leave that session with a silver bullet, 18:33:50 <lbragstad> breton but we did agree to improving the documentation as a first step 18:35:14 <rodrigods> regarding docs: https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:tests_development_docs 18:37:05 <samueldmq> ayoung has a couple of things too 18:37:19 <ayoung> I do? 18:37:25 <samueldmq> ayoung: what's the state of your policy in middleware proposals? just in need ofr reviews? 18:37:31 <knikolla> rodrigods: fyi i had started to write https://review.openstack.org/#/c/448773/ which aimed to be a more comprehensive overview 18:37:36 <ayoung> samueldmq, being actively worked on by knikolla 18:37:43 <samueldmq> I remember teher were discussions on whether to pursue with that 18:37:44 <ayoung> I have other things though 18:37:57 <samueldmq> vs what's going on in policy-in-code, how we align with that, and so on 18:38:00 <rodrigods> knikolla, awesome 18:38:08 <rodrigods> do you think we should merge them? 18:38:19 <samueldmq> ayoung: nice 18:38:32 <ayoung> samueldmq, at this point, I've given up on matching efforts to releases 18:38:41 <knikolla> rodrigods: i'll have a look at what you have and we can sync up 18:38:54 <ayoung> We'll just write stuff and when enough people complain about Keystone not having feature X it will get merged 18:38:54 <knikolla> rodrigods: make sure we aren't repeating ourselves 18:38:55 <ayoung> or it won' 18:38:56 <ayoung> t 18:38:57 <rodrigods> knikolla, mine is more on "writing" the tests 18:38:59 <dstanek> knikolla: very nice. what's left to get it out of wip? 18:39:20 * samueldmq nods 18:39:24 <knikolla> dstanek: for role-check-in-middleware? 18:39:47 <knikolla> or the docs for testing 18:39:49 <dstanek> knikolla: no, your test doc 18:40:18 <knikolla> dstanek: mainly time to write it. 18:40:26 <dstanek> gotcha 18:40:36 <knikolla> dstanek: i'm quite busy this week with the rbac patches. 18:40:48 <knikolla> dstanek: i wanna get it done by the end of next week. for the onboarding and training stuff. 18:41:31 <samueldmq> knikolla: rbac patches? 18:41:36 <ayoung> RBAC in middleware 18:41:43 <ayoung> samueldmq, we are still presenting on it at the summit 18:41:51 <samueldmq> ayoung: knikolla kk 18:41:51 <ayoung> so please merge it for Pike 18:42:16 <samueldmq> my main concerns on that was that we must have a plan on where we converge with the other efforts going on cross-project right now 18:42:36 <ayoung> samueldmq, no 18:42:40 <ayoung> samueldmq, we merge it and tell them 18:42:45 <ayoung> this is what keystone does 18:42:55 <samueldmq> and don't care about cross-project then? 18:42:55 <ayoung> we don't try to solve vm stuff for Nova 18:43:06 <ayoung> RBAC is what Keystone does 18:43:18 <samueldmq> I mean we should be solving things for OpenStack not just keystone, or just nova 18:43:21 <lbragstad> sure - but in practice that's actually not the case 18:43:26 <ayoung> Heh 18:43:32 <samueldmq> when I say cross-project I mean all projects nto just nova 18:43:49 <ayoung> In practice we shout an the world ignores us and then Nova goes and does its own things and everything stays broken 18:44:11 <ayoung> This can be done without breaking anyone, and without other projects input 18:44:15 <lbragstad> so continuing that pattern doesn't make sense 18:44:19 <ayoung> and it is optional, so it does not break anything 18:44:37 <ayoung> and it solves a lot of problems and people will be happy 18:44:45 <samueldmq> so this way it doesn't look we're all part of the same ecosystem and part of a single big project: openstack 18:44:45 <ayoung> and there will be peace throughout the realm 18:44:54 <samueldmq> it'll just be a bunch of projects that can be put together 18:44:57 <ayoung> openstack is Keystone and a bunch of services in the catalog 18:45:03 <samueldmq> if we can't even agree in a solution for a common issue 18:45:19 <ayoung> in order to agree you have to spend time actually researching the issue 18:45:28 <ayoung> so far, its been us and johnthetubaguy 18:45:40 <samueldmq> ayoung: yes and there is a policy meeting 18:45:55 <ayoung> samueldmq, and that has been us and johnthetubaguy 18:46:01 <samueldmq> it's cross-project, if just nova shows up, let's work with them 18:46:28 <samueldmq> ok so let's work with him and catch more folks as we make progress 18:46:35 <samueldmq> we're all making progress this time as I see 18:47:01 <samueldmq> anyways, I still think cross-project is the right way to go 18:47:05 <ayoung> Or we could just merge my spec, accept my patches, and actually have a solution 18:47:10 <samueldmq> is it hard? yes, of course. 18:47:16 <ayoung> its not happening 18:47:29 <ayoung> samueldmq, I cannot spend years working on this any more 18:47:36 <ayoung> there were cross project meetings 18:47:44 <ayoung> it was us and johnthetubaguy 18:47:49 <ayoung> no one cares 18:47:51 <ayoung> lets just fix it 18:48:13 <samueldmq> ayoung: I am okay with your solution, I just want to make sure we're all converging to the same place at the end 18:48:22 <samueldmq> otherwise it doesn't make sense to me 18:48:34 <samueldmq> anyways I think this can be discussed in the next policy meeting 18:48:41 <ayoung> samueldmq, no one else is really trying to solve this problem 18:48:51 <samueldmq> lbragstad: they're still happening correct? the policy meetings? 18:48:58 <lbragstad> yes 18:49:01 <ayoung> every now and againm, some one pops up and realizes there is a problem 18:49:03 <samueldmq> there was an email proposing them to happen montly iirc 18:49:04 <ayoung> usually around read-only roles 18:49:13 <ayoung> policy meetings have been weekly 18:49:24 <lbragstad> samueldmq that was the horizon meeting, not the policy one 18:49:36 <samueldmq> ok I am sorry 18:49:52 <samueldmq> lbragstad: which day in the week? can you just put here again as a reminder? 18:50:00 <samueldmq> I'll put my point in the meeting agenda 18:50:13 <lbragstad> #link http://eavesdrop.openstack.org/#Keystone_Policy_Meeting 18:50:20 <ayoung> samueldmq, I spent 2 hours doing a video conference on this last week to the policy meeting folks 18:50:39 <samueldmq> ayoung: how did it go? the last meeting 18:51:10 <ayoung> samueldmq, I think I talked over everyone and berated them into silence. As usual 18:51:40 <ayoung> So...here is my challenge 18:51:40 <dstanek> samueldmq: i think i have a better understanding of the overall direction. i still don't like the URL approach, but i don't think that'll change 18:52:01 <samueldmq> dstanek: nice 18:52:08 <ayoung> Read the spec. Understand it. If you cannot come up with a better approach, or do not find a fatal flaw in it, support it on through. Please. 18:52:15 <ayoung> dstanek, its the worst 18:52:22 <ayoung> expect that there is no alternative 18:52:24 <samueldmq> ayoung: I'll read it again 18:52:32 <ayoung> samueldmq, you coming to Boston? 18:52:37 <samueldmq> I do have some concerns, let's talk about it a bit more in the meeting tomorrow 18:52:43 <samueldmq> ayoung: yes I am 18:52:52 <ayoung> samueldmq, then come to the talk, and the policy session 18:53:00 <dstanek> ayoung: is it impossible to the the same text we use in policy today? like 'identity:do_the_thing' 18:53:11 <ayoung> I acutally used a lot of the feedback from last week to try and make sure I addressed the most common problems 18:53:16 <edmondsw> at the end of the day, the middleware approach still requires cross-project buy-in. It can only restrict things beyond what each project's policy.json restricts, so in order to use the middleware and add a role, for instance, you also need to edit policy.json files 18:53:28 <edmondsw> right? 18:53:34 <ayoung> dstanek, need a way to map that to the operation the user wishes to perform 18:53:36 <samueldmq> dstanek: I guess we'd need to put the mapping URL->text somewhere in the middleware then 18:53:42 <lbragstad> edmondsw ++ 18:53:43 <lbragstad> yeah 18:53:45 <edmondsw> so I'm leery of forcing that in without some kind of agreement cross-projetc 18:53:47 <ayoung> edmondsw, not by default 18:53:48 <lbragstad> ayoung the projects already handle that mapping 18:53:54 <lbragstad> i'm hesitant to duplicate it 18:54:03 <ayoung> lbragstad, no no no they don't 18:54:29 <ayoung> lbragstad, the only way it can be deduced is by reading code 18:54:31 <edmondsw> at the end of the day, if nova tells people not to use the middleware, it's not going to get used. 18:54:33 <ayoung> and it is different in every project 18:54:39 <ayoung> edmondsw, they won' 18:54:39 <ayoung> t 18:54:47 <lbragstad> ayoung so how does nova translate POST /v2/servers/ to compute:server_boot 18:54:52 <samueldmq> edmondsw: that's exactly my point. and I want to see, in the big picture, we're all working with the same goal, walking to the same point. 18:54:56 <ayoung> edmondsw, at the end of the day, if Tripleo tells people to use the middleware, they will 18:55:05 <ayoung> lbragstad, deep in code 18:55:11 <lbragstad> exactly 18:55:11 <dstanek> ayoung: samueldmq: ++ 18:55:16 <lbragstad> nova does that - it's in the code, 18:55:17 <ayoung> I'd have to look to find exactly that one 18:55:26 <dstanek> we already do it today 18:55:34 <ayoung> lbragstad, its kindof like how keystone does it, based on the Python function name 18:55:47 <lbragstad> we're duplicating it by adding an API to keystone (that will live for the lifetime of v3) 18:55:47 <ayoung> look, policy.json needs to go away 18:55:55 <ayoung> it will linger 18:56:01 <ayoung> but it is not a good tool for RBAC 18:56:06 <ayoung> and it is not used for RBAC today 18:56:29 <ayoung> URLs are the object refences of the Weeb 18:56:30 <ayoung> web 18:56:37 <ayoung> not compute:some_operation 18:56:44 <ayoung> URLs are the commited API of OpenStack 18:56:51 <ayoung> not identity:create_user 18:57:05 <ayoung> they are going to call the Web API 18:57:11 <ayoung> VERB + URL + BODY 18:57:27 <ayoung> the python client can work with that 18:58:13 <ayoung> The policy.json approach will stay around for the one-offs, and for transition. I don't see it as something we really want to put any more effort in it 18:58:22 <ayoung> in to? 18:58:24 <samueldmq> ayoung: I agree, the thing is how we get to that assuming that we have legacy code 18:58:31 <ayoung> samueldmq, all laid out 18:58:33 <samueldmq> and from the way we have been doing things 18:58:46 <ayoung> the RBAC in middleware change goes in with 0 json changes 18:59:06 <samueldmq> ayoung: does the middleware approach replaces .json? 18:59:22 <samueldmq> there can't be complex rules anymore, where there is a combination of role/context, for example 18:59:24 <ayoung> samueldmq, not at first, for, say keystone 18:59:31 <ayoung> for Nova, you don;'t need a .json file anywauy 18:59:34 <samueldmq> I am not saying this is the ideal, but this is what we have/allow today 18:59:46 <ayoung> so there, you would use the middleware approach to do RBAC on top of Nova 19:00:00 <samueldmq> ayoung: let's continue in -keystone? 19:00:07 <ayoung> samueldmq, if people want to continue to do complext policy, let them 19:00:08 <lbragstad> #endmeeting