18:00:10 <lbragstad> #startmeeting keystone
18:00:11 <openstack> Meeting started Tue Apr  4 18:00:10 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:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:14 <openstack> The meeting name has been set to 'keystone'
18:00:17 <lbragstad> #topic roll call
18:00:23 <dstanek> ehlo
18:00:26 <lbragstad> ping agrebennikov, amakarov, annakoppad, antwash, ayoung, bknudson, breton, browne, chrisplo, cmurphy, davechen, dolphm, dstanek, edmondsw, edtubill, gagehugo, henrynash, hrybacki, jamielennox, jaugustine, jgrassler, knikolla, lamt, lbragstad, kbaikov, ktychkova, morgan, nishaYadav, nkinder, notmorgan, portdirect, raildo, ravelar, rderose, rodrigods, roxanaghe, samueldmq, SamYaple, shaleh, spilla, srwilkers,
18:00:26 <lbragstad> StefanPaetowJisc, stevemar, topol, shardy, ricolin
18:00:27 <cmurphy> o/
18:00:32 <rodrigods> hey
18:00:36 <ayoung> Oyez!
18:00:55 <lamt> o/
18:01:04 <gagehugo> o/
18:01:12 <knikolla> o/
18:01:14 <sdague> o/
18:01:17 <lbragstad> agenda
18:01:18 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:01:59 <breton> o/
18:02:21 <rderose> o/
18:02:27 <lbragstad> since we're doing roll call to prune the list of folks on the ping list, we'll give it another minute
18:03:07 <henrynash> hi
18:03:15 <ayoung> henrynash, how are ya!
18:03:34 <henrynash> I’m absolutely spiffing, old boy
18:03:35 <lbragstad> alright - cool, let's get started
18:03:40 <lbragstad> #topic forum proposals
18:03:44 <spilla> o/
18:03:47 <antwash> o/
18:03:52 <lbragstad> here is a list of all proposed keystone-related sessions for the forum
18:03:58 <lbragstad> #link http://forumtopics.openstack.org/cfp/details/9
18:04:04 <lbragstad> #link http://forumtopics.openstack.org/cfp/details/90
18:04:15 <lbragstad> #link http://forumtopics.openstack.org/cfp/details/45
18:04:25 <lbragstad> #link http://forumtopics.openstack.org/cfp/details/92
18:04:34 <lbragstad> feel free to review and leave comments
18:04:54 <lbragstad> that'd be a good way to prepare for those discussions to come in Boston
18:05:13 <ayoung> lbragstad, very nice
18:05:15 <lbragstad> I wanted to advertise them here since the deadline for proposals was last week
18:05:33 <lbragstad> #topic Direction of coupling SQL with foreign keys
18:05:35 <lbragstad> dstanek o/
18:05:54 <dstanek> hoy
18:05:57 <lbragstad> #link https://review.openstack.org/#/c/445505
18:05:59 <dstanek> #link https://review.openstack.org/#/c/445505
18:06:01 <lbragstad> ^ relevant context
18:06:15 <rodrigods> where is morgan :)
18:06:19 <dstanek> so that review brought up some interesting questions in my mind
18:06:59 <dstanek> so the first is that even though identity and federation are in separate python packages they are really tightly coupled
18:07:17 <dstanek> so having foreign keys between those subsystems makes sense to me
18:07:30 <rderose> dstanek: ++
18:07:31 <ayoung> can we merge them?
18:07:52 <ayoung> As I see it, Federation is the framework, identity is the self contained implementation
18:07:53 <rodrigods> federation is an auth method
18:08:04 <rodrigods> auth method framework
18:08:16 <rodrigods> everything around it is to proper handle auth
18:08:24 <ayoung> federated_user  should probably be in the federated backend if anything
18:08:43 <dstanek> federation is highly coupled with identity. no matter what arbitrary boxes we want to draw
18:09:16 <ayoung> dstanek, very right
18:09:35 <ayoung> I wonder if we are wrong to even treat them as separate things. Really historical accident only.
18:09:41 <dstanek> so forcing us the do dumb things to avoid FKs seems crazy
18:09:48 <dstanek> ayoung: ++
18:10:09 <knikolla> ++
18:10:12 <ayoung> rodrigods, any strong opinion?
18:10:23 <rodrigods> ayoung, nope
18:10:24 <dstanek> federation is technically not much different that the ldap identity backend
18:10:45 <ayoung> dstanek, I would love to have LDAP reimplemented in terms of Federation
18:10:50 <lbragstad> is notmorgan around?
18:10:51 <rodrigods> dstanek, ^ that depends on how you are looking to federation
18:11:13 <henrynash> dstanek: I think that is a (slightly) different argument regarding LDAP
18:11:23 <rodrigods> henrynash, ++
18:11:28 <ayoung> was this done at my insistence?
18:11:32 <dstanek> rodrigods: how is it different?
18:12:18 <henrynash> dstanek: using the backend drivers does not require accepting the conceptual model of federation, which means that youcan’t “read user identites” from keystone...
18:12:18 <ayoung> henrynash, if LDAP was done right, it would be provided by an apache module before it ever hit the Keystone code, like mod_shib et alles
18:12:22 <dstanek> we use some external thing as the source of users/groups and keep a lightweight pointer to it locally - federation is just more more involved to do those thing
18:12:40 <henrynash> dstanek: now it is an interesting ppint that with shadwo users, maybe taht distinction goes away
18:12:55 <rodrigods> dstanek, so fed_users are federation
18:12:56 <rodrigods> not identity
18:13:00 <rodrigods> meh
18:13:03 <ayoung> even SQL could be implemented as a "populate env vars prior to hitting Keystone proper"
18:13:03 <rodrigods> i'm getting confused
18:13:17 <henrynash> ayoung: agree that we could (and should) also support that
18:13:34 <ayoung> and then the write capability of the identity backend would really be a separate subsystem from auth.
18:14:21 <ayoung> rodrigods, I think we are all saying that we should make Federation a first class citizen in Keystone, and merge it in with the identity code for the most part, but there are some historical accidents that make that hard to do right up front
18:14:28 <henrynash> The issue for me is that up until now federation == new usage model (i.e. “users aren’t in keystone, so don’t go there for info on them”, while identity was the more traditonal model
18:14:37 <rodrigods> ayoung, hmm agree
18:14:51 <dstanek> henrynash: which as you pointed out isn't true any longer
18:15:04 <rodrigods> fed_users is the glue between identity and federation
18:15:24 <rodrigods> so... yeah, i guess dstanek has a point
18:15:26 <dstanek> rodrigods: federated users are a part of the identity system today
18:15:35 <henrynash> As I said (although as you all know I’m still no fan of shadow users)…if we were to go “all in” and make shadow users look like the old model, then I cold be convinced
18:16:01 <ayoung> it is shadow users.  We just called it something else
18:16:05 <henrynash> (although not quite convinced it should do that)
18:16:18 <ayoung> Quack
18:16:19 <henrynash> sorry….it *could* do that
18:16:23 <dstanek> this brought up a more interesting point in my mind...how much value is it to not assume SQL (or at the very least assume that RI is handled by the backend and not keystone)
18:16:51 <dstanek> or maybe that backends are all or nothing (SQL, mongo if you can stomach it, etc)
18:17:13 <dstanek> not looking for an answer to this....just want to bring it up and see if there are thoughts
18:17:41 <lbragstad> i know notmorgan had an opinion
18:17:54 <ayoung> OK...so what do you mean by " it to not assume SQL"
18:17:57 <lbragstad> maybe we take an action to continue the conversation and ensure we get his viewpoint, too
18:17:59 <ayoung> what is "it" in this question>?
18:18:17 <henrynash> dstanek: I agree we are kind of “sticking to the old rules” even though they are becoming less convincing they are buying us anything (I.e. it’s either SQL everywhere, or SQL everywhere except LDAP for Identity)
18:18:48 <ayoung> It think it is SQL everywhere as a federation layer, and then it talks some other protocol...
18:18:56 <ayoung> cleaner model conceptually
18:18:56 <dstanek> ayoung: we do backflips in code to enforce FKs in Python because we assume (or want to enable) non-SQL systems to store data
18:19:03 <ayoung> dstanek, right
18:19:29 <dstanek> i'm just wondering is people think that is still valuable overall
18:19:58 <ayoung> dstanek, would love to kill the SQL identity backend and only to Federation
18:20:02 <ayoung> do Federation
18:20:05 <ayoung> in the Auth pipelien
18:20:07 <ayoung> pipeline
18:20:09 <dstanek> i don't want to take up too much time as i can write this up offline, but i want to give people the change to save me from that work by telling me they hate it
18:20:25 <ayoung> keep[ the RI checks in Python
18:20:29 <dstanek> ayoung: i'm talking about *all* backends
18:20:34 <lbragstad> dstanek maybe start a ML post?
18:20:39 <rodrigods> lbragstad, ++
18:20:48 <lbragstad> and yeah - whatever we do we should be consistent
18:20:53 <rodrigods> dstanek, conceptually, separating the backends is correct
18:20:54 <ayoung> yeah, would like to see it clearly laid out what you are proposing.
18:20:54 <dstanek> lbragstad: ++
18:21:04 <dstanek> rodrigods: why?
18:21:06 <lbragstad> not assuming RI in one backend and not in another would be a terrible experience
18:21:10 <rodrigods> but only if adds some value
18:21:11 <ayoung> If we were consistent, we would treat SQL like every other federation backend
18:21:12 <lbragstad> s/not//
18:21:15 <rodrigods> dstanek, for the reasons you said above
18:21:59 <dstanek> rodrigods: so that people can make architectural mistakes? do you see value in separate backends by subsystem?
18:22:30 <rodrigods> dstanek, only if "<dstanek> ayoung: we do backflips in code to enforce FKs in Python because we assume (or want to enable) non-SQL systems to store data"
18:22:56 <dstanek> rodrigods: that's a reason not to allow different backends
18:23:11 <ayoung> rodrigods, you OK with letting that patch go?
18:23:31 <rodrigods> dstanek, what? heh
18:23:36 <rodrigods> ayoung, i'm completely fine
18:23:43 <rodrigods> i was convinced by morgan
18:23:51 <rodrigods> let me search the abandoned backport patch
18:24:07 <lbragstad> is everyone good to move this to the mailing list/
18:24:11 <dstanek> yep
18:24:11 <ayoung> ++
18:24:14 <knikolla> ++
18:24:22 <rodrigods> dstanek, ayoung see morgan's comment https://review.openstack.org/#/c/420893/
18:24:24 <lbragstad> dstanek would you mind starting that thread? or do you want me to?
18:24:42 <dstanek> lbragstad: i'll go ahead and do it
18:24:57 <lbragstad> #action dstanek to start ML thread on FK constraints in backends or python
18:24:59 <lbragstad> dstanek thanks
18:25:03 <ayoung> Hmmm
18:25:06 <lbragstad> #topic Pike specs
18:25:17 <lbragstad> 1.5 weeks until spec proposal freeze
18:25:25 <ayoung> He's not wrong.
18:25:36 <lbragstad> 9 weeks until spec freeze
18:25:41 <lbragstad> #topic Pike specs: unified limits
18:25:49 <lbragstad> #link https://review.openstack.org/#/c/440815
18:25:52 <lbragstad> sdague o/
18:26:17 <sdague> o/
18:26:25 <ayoung> sdague, what limits are we talking about besides existing quotas?
18:26:30 <lbragstad> sdague thanks for keeping up with that spec btw
18:26:45 <sdague> ayoung: none really
18:27:08 <sdague> yeh, this is the follow on from the PTG discussion about moving the limits definitions into keystone
18:27:30 <lbragstad> and leaving allocation enforcement to the service
18:27:37 <sdague> right exactly
18:27:53 <ayoung> sdague, how strongly do you feel about this being the right direction?  We've trod this ground a time or two, and it has never been Keystone that stopped the discussion
18:28:20 <sdague> ayoung: well, we got the PTLs from cinder, glance, neutron, nova all on board with it
18:28:38 <lbragstad> i think there are several differences in the current proposal from the ones we've hashed in the past
18:28:52 * notmorgan swears he's been lurking the whole time and not on ehte phone
18:29:07 <dstanek> ayoung: what i'm a fan of is that keystone doen't do quotas - is provides limit metadata
18:29:08 <sdague> this is the concept spec for it, which it would be good to get keystone team to decide if we're doing this
18:29:11 <ayoung> OK...so I kind of like it in theory, and think that Keystone's current orginazation sucks to support it in practice, but if the other leads are OK with it, I don't see that as a deal breaker
18:29:24 <ayoung> sdague, when would limits be queried?
18:29:34 <sdague> then I can work up a lower level spec with the actual interfaces
18:29:39 <sdague> ayoung: every time that info is needed
18:29:41 <notmorgan> sdague: ++
18:29:47 <rodrigods> notmorgan, we are going to have a ML thread about FKs between subsystems
18:29:56 <sdague> https://review.openstack.org/#/c/440815/6/specs/keystone/backlog/unified-limits.rst@171
18:30:22 <notmorgan> rodrigods: no.
18:30:36 <notmorgan> rodrigods: no need, just need to add a test mechanism (i have a way to do this)
18:30:43 <ayoung> sdague, and we would not treat this as an authorization process
18:30:52 <sdague> ayoung: meaning?
18:30:55 <notmorgan> rodrigods: i'm simply going to make SQlite run in different DBs for each subsystem :P
18:31:11 <ayoung> sdague, not part of token validation
18:31:12 <notmorgan> rodrigods: so the tests will totally fail.
18:31:19 <notmorgan> rodrigods: :P
18:31:25 <rodrigods> notmorgan, lol
18:31:27 <sdague> ayoung: no, you would be using a valid token to get this information
18:31:36 <lbragstad> ayoung "187	+Service/Administrative users will have this read access for all projects."
18:31:38 <sdague> either project scoped, and get the rpoject
18:31:38 <ayoung> sdague, I could see the token validation process used to fetch the data, but not do anything with it
18:31:49 <notmorgan> rodrigods: if you're doing FKs between systems as a ML topic, keep in mind we likely will simply move back to a single unified DB and drop non-sql options
18:32:01 <ayoung> sdague, been a long time coming.  I think this can work
18:32:05 <notmorgan> rodrigods: if you ask too many people
18:32:07 <rodrigods> notmorgan, dstanek is going to be responsible to write it
18:32:11 <rodrigods> :)
18:32:15 <sdague> ayoung: ah, so, that is probably a keystone internals question. I don't think that every token validation needs this, more that it would be a dedicated interface
18:32:24 <ayoung> notmorgan, does that mean we can drop LDAP?
18:32:25 <lbragstad> yes
18:32:28 <lbragstad> sdague ++
18:32:32 <rodrigods> i'm just http://www.reactiongifs.com/wp-content/uploads/2011/05/tumblr_ljh0puClWT1qfkt17.gif
18:32:33 <notmorgan> ayoung: heh
18:32:58 <lbragstad> sdague when we talked about the limit data before, we were pretty clear that the last thing we wanted to do with it was stuff it into the token
18:32:59 <notmorgan> rodrigods: in short, i have a plan to make it a hard-set thing
18:33:13 <lbragstad> sdague afair
18:33:14 <sdague> so, the big question right now, is getting keystone team approve to move forward in concept, so I can start the more detailed interface design and hopefully get some progress this cycle
18:33:17 <notmorgan> if i have time to write it.
18:33:22 <ayoung> lbragstad, technically it does not go into the *token*
18:33:25 <notmorgan> sdague: i like this plan.
18:33:27 <sdague> lbragstad: I definitely agree, not in token
18:33:44 <notmorgan> sdague: and i appreciate the work you (and the other folks) are putting into it.
18:33:52 <lbragstad> notmorgan sdague ++
18:34:03 <sdague> at L242 the "not in token" is called out again explicitly
18:34:05 <ayoung> sdague, you did the mnost important part:  getting consensus from the other teams about the scope and limits of...limits?
18:34:29 <sdague> ayoung: yeh, we seem pretty bought in there
18:34:37 <dstanek> sdague: i like the work here and don't see why we shouldn't be able to agree to it
18:34:47 <ayoung> that is where the discussion has fallen apart in the past.  We probably should plan on having the limit as an optional part of the token validation process, as that is a nefficiency question
18:34:58 <ayoung> it would be passed from Auth token middleware via headers like other info
18:35:12 <ayoung> and getting that defined properly is probably the hardest part
18:35:32 <ayoung> esp for, say Neutron that might have quotas on 16 different types of resources
18:36:16 <ayoung> can always be done as a deliberate call to Keystone, but that is going to be an additional round trip.  Probably OK, but worth considering if it is worth/necessary
18:36:26 <lbragstad> FWIW - i'm good to +2 the spec. I think we should probably propose it to On-Going since it's a really well written document
18:36:31 <ayoung> ++
18:36:47 <sdague> lbragstad: so, revise with the other directory?
18:36:58 <lbragstad> sdague yeah - i think that'd be best
18:37:01 <sdague> I can do that pretty quick
18:37:20 <ayoung> OK...my turn?
18:37:37 <lbragstad> sdague awesome - after that i'm good to +2 and I'd encourage other keystone folks to give it a good hard look
18:37:41 <ayoung> ++
18:38:11 <sdague> updated
18:38:17 <lbragstad> sdague is there anything you need from us as next steps outside of reviewing the new spec?
18:38:43 <ayoung> lets agree to meet and hammer out a strawman-level API at the summit
18:39:20 <sdague> ayoung: so, I intend to do that in advance
18:39:27 <sdague> as another spec
18:39:27 <ayoung> ++
18:40:06 <sdague> and there is already a discussion on unified limits and hierarchical quota models for Boston where we can talk about some of this as well
18:40:27 <ayoung> That will work
18:40:28 <lbragstad> #link http://forumtopics.openstack.org/cfp/details/9
18:41:25 <samueldmq> Nice. Will be good to have those as topics next month in Boston
18:42:02 <ayoung> Next topic?
18:42:08 <lbragstad> sdague thanks again, let us know if you need anything else?
18:42:25 <lbragstad> #topic Pike specs: RBAC from Middleware
18:42:27 <sdague> lbragstad: just a +A :)
18:42:32 <ayoung> RBAC from Middleware   https://review.openstack.org/#/c/452198/   sdague would love your input on it
18:42:38 <lbragstad> #link https://review.openstack.org/#/c/452198/
18:42:46 <lbragstad> #link https://review.openstack.org/#/c/401808/
18:43:17 <ayoung> So, this has been under discussion a long time, and I would like to see it come to fruition
18:43:35 <ayoung> the goals here have been to balance all of the demands on RBAC
18:43:39 <dstanek> sdague: thanks for your hard work here
18:43:43 <lbragstad> dstanek ++
18:44:02 <ayoung> namely, it is essential to all of the other services that RBAC be enforced in a consistant way to ensure we are not opening security holes
18:44:16 <ayoung> making policy safe to modify without breaking services
18:44:28 <samueldmq> We need to take care how we're doing that I think
18:44:29 <ayoung> make it possible to upgrade, etc
18:44:40 <dstanek> ayoung: has there been any x-project discussion about this yet?
18:44:52 <samueldmq> I'd really like to see how that fits with the current discussion on policies
18:44:53 <lbragstad> dstanek there was some on the spec, but it merged
18:45:01 <samueldmq> And the direction we're going
18:45:09 <ayoung> samueldmq, very much so, and this proposal is the best we've been able to hammer out.  I'd like to make sure, at a minimum, that Keystone core understands, not just the proposal, but the whys behind it.
18:45:34 <lbragstad> ayoung why don't you start with the two things you shared yesterday you'd like to solve
18:45:37 <ayoung> We've had discussions on it in the policy meetings, in cross project meetings at prior summits (I misseed the PTG)
18:45:41 * lbragstad and ayoung talked a lot yesterday
18:45:42 <ayoung> sure
18:45:57 <ayoung> so, as the hippocratic oath says "First, do no harm"
18:46:15 <ayoung> the goal here is to not introduce anything that will destabilize the existing policy work
18:46:20 <ayoung> but rather, compliement it
18:46:37 <ayoung> a long time identified goal is to split role enforcement from scope
18:46:46 <samueldmq> I just wanted to make sure people/deloyera want to have 2 layers of policy
18:46:49 <ayoung> scope is "does this token have a project that matches the project of the resource"
18:47:17 <ayoung> the scope check is an engineering decision.  End users should not customize it, as they will only break it, not make things better
18:47:31 <ayoung> thus, editing policy files is a risky business
18:47:33 <samueldmq> ayoung: that is to enforce token roles in the middeware correct?
18:47:39 <ayoung> samueldmq, yes
18:47:53 <lbragstad> no - the scope check belongs in the service
18:48:05 <lbragstad> because it takes into account things that only the service knows about
18:48:05 <ayoung> explicitly, this proposal is to make a check in the middleware, prior to the scope check, that only checks the roles
18:48:08 <dstanek> i've stated by objects to the current URL approach in that paste
18:48:09 <samueldmq> ayoung: I didjt mean final users but deployera
18:48:14 <samueldmq> Deployers
18:48:17 <lbragstad> the rbac check is what is being proposed we do in middleware
18:48:19 <ayoung> and the role matches (for now) only a rule based on the URL
18:48:24 <dstanek> and i'm worried what this does to the in-code effort of having sane defaults
18:48:41 <ayoung> that means it will not support role to instance of resources or any other checks like that
18:49:02 <samueldmq> So is the goal to have the role checks only in the middleware?
18:49:05 <ayoung> an example would be the url for say creating a network port:
18:49:16 <samueldmq> And in the service we only keep scope checks?
18:49:29 <ayoung> soimething like serivce=network verb=PUT /port
18:49:49 <ayoung> in middleware, we would check what role is associated with the above:
18:49:53 <samueldmq> I wanted to see how this converge in the future eith the other work, rather than checking roles in 2 places
18:50:02 <ayoung> assuming a starting case of there being two roles:
18:50:05 <ayoung> admin and Member
18:50:20 <lbragstad> samueldmq i have similar concerns about the usability of that
18:50:35 <dstanek> samueldmq: i think you have to real with roles during a scope check if we allow complicated rules
18:51:10 <ayoung> dstanek, samueldmq lbragstad yes.  We are not going to remove anything from policy.  But I think we can persuade people to leave policy alone
18:51:26 <ayoung> if they really really need complex policy, let them write it.
18:51:27 <lbragstad> I'd be curious to see operators give their feedback on this, I don't think we had any operators review the original spec that was merged to ongoing (outside of edmondsw)
18:51:39 <ayoung> but for most people, I think it is not what they want.
18:51:49 <samueldmq> dstanek: yes and my point is that having enforcement in 2 places for tbe same thing (roles) will make things harder to customize/debug
18:51:52 <lbragstad> but we are sucking a bunch of information that is already defined somewhere into keystone
18:52:35 <dstanek> samueldmq: agreed
18:52:43 <ayoung> samueldmq, it might be if the operator is using both RBAC and policy. But if they use default policy, and RBAC from middleware, it should be much easier
18:52:55 <ayoung> policy is not easy
18:53:02 <lbragstad> it might not break backwards compatibility, be we're adopting a lot of information into keystone
18:53:12 <ayoung> In essence, you need to run with a debugger to see why something is failing
18:53:28 <dstanek> ayoung: do other cloud providers or commercial systems implement something like this?
18:53:34 <ayoung> dstanek, kubernetes does
18:53:40 <samueldmq> ayoung: so the goal is to have people putting current policy aside to use that mechanism
18:53:42 <ayoung> its still alpha there
18:53:45 <dstanek> rbac and complicated policy?
18:53:46 <ayoung> samueldmq yes
18:53:52 <samueldmq> We should document that we qant that
18:53:56 <samueldmq> In the future
18:54:00 <ayoung> dstanek, p[er "resource" type policy scoped to namespace
18:54:10 <samueldmq> And make sure we have enough deployers agreeing on thay
18:54:19 <samueldmq> And they know the implications of it
18:54:32 <lbragstad> i think we are trying to solve two problems (per the discussion yesterday) 1.) introduce a read-only role 2.) allow users to have roles to do subsets of things
18:54:43 <samueldmq> Like not being able to combine role and scope in a more complicates rule
18:54:53 <samueldmq> That's my point
18:55:23 <dstanek> ayoung: maybe i'm dense, but i don't understand what this buys us
18:55:25 <ayoung> I want to be clear, the keystone team should not say "no" to this without providing a viable alternative proposal.  I've spent, quite literally, years trying to come up with a solution here.  policy.json based approaches were origianlly considerd, vetted, and discarded
18:55:34 <ayoung> OK,,, what does this buy us....
18:55:44 <lbragstad> ayoung there is an alternative proposal
18:55:58 <ayoung> lbragstad, not really there isn't.
18:55:58 <lbragstad> ayoung you reviewed it https://review.openstack.org/#/c/427872/17
18:56:05 <ayoung> lbragstad, that is not a real replacement
18:56:08 <ayoung> that will break
18:56:12 <samueldmq> ayoung: you like the solution. As do I. But I want to make sure people want it too.
18:56:13 <lbragstad> how does ^ not solve the problems you described yesterday?
18:56:28 <samueldmq> I am more than happy to review
18:56:34 <ayoung> lbragstad, Openstack is more than Nova
18:56:40 <lbragstad> ayoung sure
18:56:55 <ayoung> Nova alone cannot define new roles without providingh a way to prevent those roles from executing operations on other services
18:57:09 <lbragstad> ayoung i'm positive that's not what nova was trying to do
18:57:09 <ayoung> with that proposal, they would have to modify policy.json on every.single.service
18:57:16 <ayoung> even ones they do not know about
18:57:19 <samueldmq> Looks like we need to look at the spec and add questions there
18:57:32 <samueldmq> It has been merged alteady, correct?
18:57:46 <ayoung> lbragstad, so the goal here is to provide a mechanism that can be added in to the middleware flow, provide decent defaults, and move forward from there
18:58:18 <ayoung> at a minimu, we want to knwo that a service that is registered with keystone, that expects a user with the default role (Member) *has* to have that role to perform standard operations
18:58:24 <lbragstad> but side-affects of adding this mechanism to middleware doesn't make any sense with upgradeability
18:58:51 <ayoung> otherwise, if you go to the nova approach, define a role, say "reader" that can only read Nova resource, it can still write to all resources within that project scope on neutron etc
18:58:51 <lbragstad> and i would argue that it makes it harder to manage
18:59:13 <lbragstad> ayoung i think this is something that we'd have to go through as a community together
18:59:18 <knikolla> 1 minute left warning
18:59:21 <ayoung> lbragstad, the default rule handles upgradeability at least as well as things do today, if not slightly better
18:59:40 <ayoung> lbragstad, and that is why I am bringing it up at the team meeting.
18:59:40 <lbragstad> ayoung no it doesn't beacuse you're not taking into account the default role define at the service
19:00:00 <ayoung> lbragstad, so knikolla and I will be m,aking a proof of concept of this work prior to the summit, and are talking about tit there
19:00:02 <samueldmq> I guess qe gotta continue in -keystone
19:00:05 <lbragstad> let's carry this over to -keystone
19:00:09 <lbragstad> #endmeeting