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