18:01:47 <morganfainberg> #startmeeting Keystone
18:01:48 <openstack> Meeting started Tue Dec 16 18:01:47 2014 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:51 <openstack> The meeting name has been set to 'keystone'
18:01:52 <gabriel-bezerra> o/
18:01:54 <raildo> ayoung, \,,,/
18:01:57 * morganfainberg resists urge to startmeeting keystoners
18:02:17 <morganfainberg> #topic Kilo-1 on Dec 18
18:02:25 <morganfainberg> thats right, in a couple days
18:02:28 <morganfainberg> k1 will be cut
18:02:38 <morganfainberg> we're very close, 3-4 outstanding bugs that are actively being worked on
18:02:46 <morganfainberg> #link https://launchpad.net/keystone/+milestone/kilo-1
18:03:05 <morganfainberg> make sure we get reviews on them, lets get them in by tomorrow so ttx can cut k1 keystone for us!
18:03:29 <lbragstad> o/
18:03:34 <morganfainberg> #topic Review Specs
18:03:38 <morganfainberg> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone-specs,n,z
18:03:49 <morganfainberg> reminder, specs have a hard dealine of k2
18:04:07 <morganfainberg> anything comeing in post k2 will need an explicit exception granted
18:04:18 <amakarov> hi!
18:04:36 <morganfainberg> now that the house keeping is out of the way
18:04:38 <morganfainberg> #topic Dynamic Policy Specs
18:04:42 <morganfainberg> ayoung, o/
18:04:49 <ayoung> Ah
18:04:59 <nonameentername> o/
18:05:03 <henrynash> the man of many specs....
18:05:04 <ayoung> OK...so I wanted to make sure people understood the concept
18:05:26 <ayoung> the many specs are the result of tryung to break it down to consumable concepts
18:05:28 <ayoung> so...
18:05:41 <henrynash> ayoung: ++
18:05:50 <ayoung> We've got the ball rolling by promoting policy to an oslo library
18:06:12 <samuelms> rodrigods, o/
18:06:12 <ayoung> there is some confusion over that and the next one: enforce policy in a library
18:06:21 <ayoung> and there is somet question about where that should live
18:06:51 <ayoung> I recently posted a refactoring of the keystone code that shows the difference in intention, though, between the oslo stuff and this
18:06:53 <henrynash> ayoung: you mean where the actualy code taht calles the policy engine lives?
18:06:59 <rodrigods> regarding the policy lib, the repo is here https://github.com/rodrigods/oslo.policy
18:07:11 <ayoung> the distinction is that the oslo policy library is a rules engine, and not keystone specific
18:07:13 <rodrigods> the spec is in the meeting wiki
18:07:21 <morganfainberg> ayoung, as it should be.
18:07:22 <ayoung> so while it is "necessary" it is not "sufficient"
18:07:50 <ayoung> the next step is to common-ize the code for enforcing policy from a server...and to make sure that keystone is not treated differently than the other services
18:07:57 <ayoung> ok,  so I post this today:
18:08:21 <ayoung> https://review.openstack.org/#/c/141969/   policy refactoring
18:08:54 <ayoung> it is still inside the keystone server  but the code that is pulled into authorize.py needs to be made available to a wider audience:  either KC or middleware
18:09:07 <topol> o/
18:09:24 <ayoung> there needs to be more cleanup on this code before that happens, too, as there is a lot of duplication
18:09:32 <jamielennox> o/
18:10:06 <ayoung> henrynash, so to address your question : yes, where the actually code that calls the policy engine lives?
18:10:13 <ayoung> er.. ? -> .
18:10:16 <henrynash> ayoung: lookd the right approach to me
18:10:38 <henrynash> ayoung: and, yes, that code could do with some cleanup :-)
18:10:38 <ayoung> henrynash, to be more specific, to standardize how we pull values out of the token and enforce policy on them
18:10:42 <ayoung> ++
18:11:11 <ayoung> now, raildo samuelms and company have been working on the actual policy files themselves in a parallel effort
18:11:17 <jamielennox> I would like a certain amount of that code to live inside the upcoming oslo.policy library
18:11:21 <henrynash> ayoungL so feel free to lean on my for reviews of that stuff
18:11:48 <ayoung> jamielennox, yeah, I think that there will be logicial splits in the code, and anything that is common to all rules engines would move to oslo.policy
18:12:06 <jamielennox> specifically the object that i pass out of auth_token middleware i want people to pass directly to oslo.policy so that essentially keystone controls "ends" of the information required to enforce policy
18:12:08 <ayoung> henrynash, will do. and I think you and I are on the same course,  but from different starting points
18:12:21 <henrynash> ayoung: ++
18:12:26 <jamielennox> both "ends"
18:12:51 <ayoung> jamielennox,   OK, I think we are on the same page
18:12:51 <morganfainberg> jamielennox, that makes sense to me.
18:13:08 <morganfainberg> ayoung, i haven't seen anything that looks wildly off in the weeds being proposed here.
18:13:16 <ayoung> in order to enforce policy, we want to standardize the auth context.  that starts with the token, but then goes on
18:13:26 <morganfainberg> or anything that surprised me, mostly what we've discussed summit and up to this point :)
18:13:30 <jamielennox> (this may not be new ground i just only caught the last part of the conversation)
18:13:34 <ayoung> I first rewrote it in the keystone server, but moved the rewrite to the KC code:
18:13:46 <morganfainberg> jamielennox, you caught on very early in the conv.
18:14:15 <ayoung> https://review.openstack.org/#/c/138519/  is the "Access Info" and is based on design guidance from morganfainberg
18:14:20 <ayoung> I happen to really like his guidance
18:14:46 <ayoung> it is a type of coding that some might find odd, but it enforces, as much as possible, that we have the right "types" for enforcing the policy
18:14:54 <ayoung> that review has a wider implication
18:15:01 <ayoung> it is also to be used in building the token
18:15:12 <ayoung> and will be part of morganfainberg 's effort to clean up the token provider
18:15:23 <morganfainberg> ayoung, and that code is a bit easier to read than using python descriptors
18:15:24 <ayoung> its rally the hear of the data as managed by Keystone
18:15:29 <ayoung> really
18:15:34 <ayoung> really the heart
18:15:59 <morganfainberg> ayoung, which is likely what i would have tried to use (easier to read = better in this case)
18:16:17 <ayoung> one goal is to be able to make a call into keystone without a token, build up an AccessInfo object, and use it to enforce policy for tokenless operations
18:16:38 <ayoung> that should make gyee happy...
18:16:54 <ayoung> ok...so that is all rfactoring, no new behavior yet
18:16:59 <ayoung> on to new behavior
18:17:24 <ayoung> once the endpoints can agree on how to enforce policy, we want them to be able to get their policy files from the keystone server
18:17:36 <ayoung> thuis has been on the roadmap for years
18:17:56 <topol> why would they need to agree on how to enforce policy?
18:18:03 <ayoung> the policy API as origianly specified was lackignthe ability to fetch the "right"policy file until henrynash got the endpoint stuff working
18:18:17 <ayoung> topol, good question, lets make it explicit
18:18:31 <ayoung> topol, the policy mechanism is really RBAC
18:18:42 <ayoung> and RBAC is an engineering effort to simpligfy access control
18:18:52 <dolphm> ayoung: what's the value of enforcing authorization on unauthenticated calls?
18:18:53 <topol> all true
18:18:55 <ayoung> we've made it a point that all of openstack shares the token infra
18:19:09 <ayoung> dolphm, good point...I'll come back to that
18:19:28 <ayoung> topol, so we want to make sure that a role is a reusable concept across two or more services
18:19:29 <morganfainberg> dolphm, thanks for asking, i actually was going to ask that.
18:19:35 <ayoung> we've seen the abuse of "is admin"
18:20:07 <ayoung> what we want is to have agreement on what it means to have a role
18:20:34 <topol> ayoung, so  the interesting question is how much if any policy re-work the projects *must* do as opposed to this is a better option should you choose to leverage it?
18:20:44 <ayoung> topol, so, one thing dolphm showed me last year is thathe policy approach was designed such that we could have  single policuy file for all known enforcement points
18:21:01 <ayoung> topol, the goal is to minimize the amount of work
18:21:15 <bknudson> I don't think the other projects want to think about policy, so if we propose something they would be happy
18:21:25 <lbragstad> ++
18:21:25 <topol> ayoung, agreed.  Im tweaking your sales pitch
18:21:30 <ayoung> and to get it so that instead we identify the assumptions that they are building into their policy enforcement, and either incorporate those assumptions or remove them as appropriate
18:21:38 <topol> bknudson++
18:21:39 <ayoung> yeah...glad to make this explicit
18:21:44 <ayoung> ok,  dolphm back to your question
18:21:51 <morganfainberg> bknudson, i know no other projects want to think about policy
18:21:57 <ayoung> I would not say "unauthenticated" calls are what I want here
18:21:59 <morganfainberg> bknudson, well... except one but that doesn't count.
18:22:11 <ayoung> I want to enforce policy on calls without gettnig a token first, but that are authenticated somehow
18:22:27 <ayoung> the most common need is for long term agreements with services
18:22:28 <topol> To sell this we need to deliver free gifts to the other projects. That being the better way of how to do policy. If they have to figure it out on their own you wont get traction
18:22:42 <morganfainberg> ayoung, in what context? on endpoints or just to keystone?
18:22:56 <ayoung> for example, when Nova etc does a token validation, they need to first get a token themselves, which is a second round trip
18:22:57 <morganfainberg> topol, if it just works or requires minor tweaks thats a pretty easy sell i think.
18:23:10 <morganfainberg> ayoung, ok so just when interacting with keystone
18:23:16 <morganfainberg> not a user talking to nova
18:23:16 <lbragstad> Policy-Management-as-a-Gift?
18:23:17 <ayoung> morganfainberg, yeah,
18:23:24 <bknudson> nova only gets a token when its old token is expiring.
18:23:29 <bknudson> or has expired.
18:23:33 <ayoung> bknudson, right
18:23:37 <henrynash> lbradstad: it is Christmas, after all
18:23:39 <morganfainberg> bknudson, he's saying we should allow something like x509 for that
18:23:44 <topol> ayoung, why this extra hoop? Sounds scary.  Why not just say you can now pull your policy from keystone and we have a better sample for you to consider for your policy file.?
18:23:45 <ayoung> yep
18:23:48 <morganfainberg> bknudson, rather than needing a username/password
18:24:02 <ayoung> topol, two reasons
18:24:05 <morganfainberg> bknudson, not that a username/password wouldn't *also* work, but it wouldn't be required.
18:24:08 <ayoung> one, so we can updated it if there is a CVE
18:24:28 <ayoung> 2.  to build toward dynamically generating rules for the policy file...let me address that one
18:24:36 <bknudson> ok, but if the argument is that nova needs to do 2 requests for each token that's not a good argument.
18:24:41 <ayoung> OK,  if you look at the rules, they are often things like "admin or owner"
18:25:12 <ayoung> bknudson, yes it is
18:25:17 <topol> I agree the rules are not granular
18:25:20 <morganfainberg> bknudson, no thats not the only argument, the main argument is that deployers don't want usernames/passwords in config files - and encrypting that is a separate issue
18:25:28 <bknudson> because nova doesn't need to do 2 requests for each token.
18:25:35 <morganfainberg> bknudson, nova not needing an extra round-trip every now and again is a benefit, but not the sole story
18:25:40 <ayoung> bknudson, but,  was a goal.  The rest of the design stands on its own even if we don't do it
18:26:34 <morganfainberg> bknudson, it's a kill few birds with one stone.
18:26:38 <ayoung> OK  so back to rules:
18:26:53 <ayoung> the idea is that our roles are really collections of capabilities
18:27:07 <ayoung> henrynash, I think that is one of your key points
18:27:10 <topol> ayoung whats not coming through is how this benefits the projects. Benefits beyond them getting the policy file from keystone and beyond a more granular RBAC policy sample (gift) for them to use... There seems to be another catch that I am not understanding
18:27:23 <samuelms> ayoung, henrynash ++
18:27:48 <ayoung> so the smalles thing we have right now are the rules themselves, which are mapped to APIs.
18:27:49 <samuelms> what about introduce capabilities on keystone ?
18:27:49 <ayoung> things like
18:27:56 <ayoung> identity:check_token
18:28:03 <ayoung> or compute:boot
18:28:08 <henrynash> ayoung: indeed….I think we should separate service capabilities (which are kind of our roles today) and the “real roles” which are collections of those capabilities
18:28:19 <ayoung> henrynash, so that is what I am driving towards
18:28:22 <samuelms> henrynash, ++
18:28:25 <samuelms> henrynash, domain-roles
18:28:27 <morganfainberg> samuelms, i think that comes down to further work on this thought path.
18:28:42 <ayoung> so we also need to "not break things"
18:28:42 <morganfainberg> samuelms, this would be the start and wouldn't preclude moving to much more granular stuff
18:28:51 <ayoung> and that is what lead to this approach geting so granular
18:28:51 <topol> Needs to be clear what extra work the projects need to do to take advantage (more pep points?)   and needs to be clear what benefits they will see
18:29:04 <ayoung> so,  look at the rules, los of them assume "user has some role on the project"
18:29:13 <morganfainberg> topol, ++ clear additional PEP benefits is key
18:29:22 <samuelms> morganfainberg, k
18:29:32 <ayoung> and we used to have the idea of "user is a member of a proejct" as a separate concept from roles...which we changed into :"uuser has the member role on a projct"
18:29:33 <dolphm> topol: ++ i'm not clear on what we're asking of other projects, if anything
18:29:51 <ayoung> so  we could look at the existing roles as  admin and member
18:29:57 <ayoung> there are few other one offs,
18:30:06 <morganfainberg> dolphm, i think the goal is we're aiming to make it so other projects don't really need to "do" much of anything except maybe removing is_admin
18:30:21 <ayoung> like server etc, but really  the other projects care about admin  (can do anything) and member(can do something)
18:30:36 <ayoung> so...lets say that "admin" is composed of "member"  p[lus other capabilites
18:30:53 <ayoung> we can reflect this in the policy file rules like this:
18:31:08 <ayoung> ...
18:31:24 <ayoung> "owner"                                      : "( user_id:%(user_id)s or user_id:%(target.token.user_id)s ) or rule:domain_admin",
18:31:34 <ayoung> yeah, that is not member
18:31:58 <ayoung> but the rule is composed of "( user_id:%(user_id)s or user_id:%(target.token.user_id)s )  and domain admin
18:32:05 <ayoung> and then domain admin is defined as
18:32:23 <ayoung> "domain_admin"                               : "(role:admin and rule:domain_matches and scope:domain) or rule:cloud_admin",
18:32:35 <ayoung> and yes, henrynash you have concerns about domain matches.
18:32:41 <ayoung> lets put them aside for the moment
18:32:58 <ayoung> and then cloud_admin is our power user
18:33:12 <ayoung> "cloud_admin": "role:admin and domain_id:admin_domain_id and scope:domain",
18:33:34 <dolphm> so you're basically just rewriting the rules to compose roles together as much as possible?
18:33:39 <ayoung> dolphm, yes
18:33:43 <ayoung> dolphm, the goal is this:
18:33:45 <dolphm> ++
18:33:49 <henrynash> ayoung: yes, right now I’m tryingto make sure I grasp the essence of this change to the policy file…I’m always with you up to this point…then the little doubting bird starts chipring in my ear
18:33:59 <ayoung> at the API level, the writer should specify as little as possible, hopefully just the role
18:34:12 <bknudson> where does scope come from?
18:34:21 <dolphm> henrynash: it might help if there was a diagram of the hierarchy that ayoung is producing? ayoung: sorry to make you diagram.
18:34:24 <bknudson> I don't think we have that now.
18:34:38 <ayoung> bknudson, it was something I added to the rules enforcement, but its in the token
18:34:43 <ayoung> dolphm, I have that
18:34:46 <dolphm> ooh
18:34:50 <ayoung> 1 sec
18:34:58 <ayoung> pauses due to gerrit slowness
18:35:08 <lbragstad> (cloud-admin) -> (domain_admin) -> (owner)?
18:35:28 <ayoung> dolphm, https://review.openstack.org/#/c/125704/7/specs/kilo/hierarchical-roles.rst,cm
18:35:38 <ayoung> the diagrams start at line 78
18:35:56 <ayoung> lbragstad, yes
18:36:00 * dolphm needs to review specs.
18:36:05 <lbragstad> so, each project would need to define what their 'admin' can do
18:36:13 <ayoung> lbragstad, right
18:36:21 <ayoung> lbragstad, so we have a unified policy file
18:36:25 <topol> so whats gonna really help here is a sample of a new policy file where we can see the benefits of the new approach (composability, whatever)  and then once the value is clear selling it will be easier
18:36:36 <morganfainberg> dolphm, hehe this is why there was a housekeeping item at the start of the meeting
18:36:41 <ayoung> samuelms, you have that?
18:36:42 <morganfainberg> dolphm, :)
18:36:46 <stevemar> topol, i think thats in the patch chain
18:36:56 <ayoung> https://github.com/samuel-ms/os.unified.policy/blob/master/src/policy.json
18:37:04 <samuelms> ayoung, the unified policy?
18:37:21 <ayoung> so that will need to be rewritten once we have the  basic rules cleaned up
18:37:28 <topol> stevemar, thanks. is it annotated so its new benefits are clear?
18:37:33 <ayoung> but,  then the goal is to be able to go more granular
18:37:43 <dolphm> but that's up to the projects
18:37:54 <ayoung> topol, read the hierarchical spec, its the centerpiece
18:37:57 <henrynash> ayoung: so I guess my real issue with this is that I don’t see teh defintion of “logical” roles (i.e roles that specify some meangful role to a domain admin) as being something that exists in the policy file…
18:37:58 <dolphm> or you mean more granular roles?
18:38:02 <jamielennox> ayoung: so last i heard was that you wanted to do all this within policy.json - is that no longer the case?
18:38:14 <ayoung> dolphm, up to the project to go more granular?  Well, the default is, yes
18:38:30 <ayoung> jamielennox, ok...so the end state is this
18:38:34 <stevemar> topol, nope, it's all json so no comments
18:38:57 <ayoung> we have in the keystone roles database the relationships between the roles.  That info is used to generate a section at the top of the policy.json file
18:39:04 <ayoung> that shows the inheritance chain
18:39:09 <stevemar> topol, i think this is it: https://review.openstack.org/#/c/123509/
18:39:18 <jamielennox> because you should be able to define a rule that says one role is composed of these others and have that recursive
18:39:19 <ayoung> stevemar, we can find some way to make comments if we need to
18:39:26 <ayoung> "comment": "This is not really a rule"
18:39:28 <jamielennox> the concept of parent shouldn't need to be stored
18:39:32 <topol> thanks stevemar
18:39:47 <morganfainberg> ayoung, ok i think we need to continue this in -keystone and on the specs [we have some other topics we need to hit today here], but this i think has helped a lot socialize the concepts and what you're aiming for (so wrap up if you don't mind)
18:40:01 <morganfainberg> ayoung, i know it's helped me understand the bigger goals as well.
18:40:03 <henrynash> ayoung: unless we are going to have domain-specific policy files….then surely the policy file is “owned” by a service and might have a) a set of raw capabilities, and (optionally) some generic groups of those capabilities….(although I always struggle with the later since I always feel these groups will end up domain-specific)
18:40:14 <ayoung> morganfainberg, thanks for the time.  I just wanted people to be aware of the scope of what I was proposing, and the relationship between all this mini specs
18:40:18 <dolphm> henrynash: ++
18:40:23 <morganfainberg> ayoung, exactly
18:40:31 <samuelms> henrynash, ++
18:40:41 <ayoung> henrynash, a service should specify just the cpabailites and the roles for that capability
18:40:58 <ayoung> its up to Keystone to manage the higher level of composition
18:41:22 <morganfainberg> ayoung, we need to add comment logic to the policy rules engine anyway
18:41:23 <ayoung> ideally, a user should be able to delegate to someone else only a subset of their capabilities
18:41:29 <morganfainberg> ayoung, something the rules engine *should* support cleanly
18:41:44 <samuelms> ayoung, , with domain-roles being defined at domain level, and the fact that domain_roles contains other roles or capabilities
18:41:55 <samuelms> aysyd, make it possible to define access control at domain level
18:42:08 <samuelms> ayoung, without the need of having one policy file per domain
18:42:21 <ayoung> henrynash, samuelms I'm not certain if domain roles fall 100% into the same mechanisms as what I am proposing.  It seems to me that domain roles should be expanded prior to token creation
18:42:22 <morganfainberg> samuelms, i think that is more forward looking than this cycle, but something to keep in mind.
18:42:33 <ayoung> OK, I surrender the conch
18:42:38 <morganfainberg> #topic New Cloud Policy on Keystone
18:42:42 <ayoung> feel free to corner me for more questions
18:42:43 <henrynash> ayoung: (agreed)
18:42:52 <morganfainberg> #link https://review.openstack.org/#/q/status:open+branch:master+topic:bp/modify-policy,n,z
18:42:53 <morganfainberg> samuelms, afaranha o/
18:42:57 <samuelms> morganfainberg, ++
18:43:00 <samuelms> o/
18:43:20 <ayoung> I've butchered the hell out of their patch
18:43:31 <morganfainberg> as a heads up i'm going to keep this moving so we can cover the last couple topics, but these look to be straightforward.
18:43:33 <samuelms> so basically we're proposing spliting the global admin we have in cloud_admin, domain_admin, project_admin
18:43:46 <ayoung> ++
18:43:48 <samuelms> we have a spec and a patch proposing policy changes
18:43:49 <samuelms> https://review.openstack.org/#/q/status:open+branch:master+topic:bp/modify-policy,n,z
18:44:03 <samuelms> ayoung is working with us on this
18:44:13 <samuelms> and we just need more reviews on that stuff
18:44:15 <bknudson> deployers can use whatever policy they want to or provide their own.
18:44:29 <bknudson> what difference does it make what the default one is?
18:44:34 <samuelms> bknudson, yes, sure .. and they're doing this today
18:44:40 <henrynash> samulems: so the one conceptual change between this and the previous v3policsample is that in the one I origionally wrote I think cloud_admin was a superset of domain_admin…
18:44:42 <morganfainberg> bknudson, it matters so we show best practices
18:44:44 <samuelms> bknudson, we have something more 'real' as default
18:44:46 <afaranha> we are now working on policy refactor with Adam Young https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:policy-refactor,n,z
18:44:52 <samuelms> morganfainberg, ++
18:45:07 <morganfainberg> bknudson, the current model people use in production... because deployers don't want to or dont get (as per the summit session) how to write policy
18:45:12 <morganfainberg> with some rare exceptions
18:45:13 <ayoung> henrynash, so, one thing I was wondering was how to communicate the admin domain ID.
18:45:13 <raildo> bknudson, another this is this will be very useful for hierarchical multitenancy implementation
18:45:21 <dolphm> bknudson: i'd rather see something more powerful as the default starting point - i have my gripes with v3cloudpolicy but they're not resolvable in the short term.
18:45:26 <ayoung> if the file was autogenerated, we'd inject it
18:45:53 <samuelms> dolphm, ++
18:45:55 <henrynash> ayoung: could od
18:45:56 <bknudson> seems like a large spec for just saying we feel like the default policy should change.
18:45:57 <henrynash> do
18:46:11 <bknudson> git mv
18:46:42 <ayoung> We could do this: upload of policy file allows for template replacement, and then keystone gets its policy out of its store as opposed to from etc
18:46:42 <morganfainberg> bknudson, there is actually a chunk of work for tests and whatnot i think
18:46:49 <dolphm> bknudson: is it really a git mv? or did the policy need to change to become the default? i'm surprised there's no impact on tests.
18:46:59 <morganfainberg> dolphm, fairly certain there is.
18:47:02 <morganfainberg> and quite a bit actually
18:47:02 <samuelms> bknudson, well, after keystone accepts that , we plan to put such policies on every service
18:47:10 <samuelms> bknudson, and make that spec global
18:47:20 <bknudson> they'll need their own spec, or put it in the common specs.
18:47:25 <henrynash> we can’t just use v3policsample as is…it does need some changes
18:47:26 <morganfainberg> samuelms, you should propose this to the cross-project repo
18:47:27 <ayoung> I might well have messed up their tests.  Look at older revisions of the patch to see the degree of churn
18:47:28 <lbragstad> samuelms: do you know if the testing impact is documented in the spec?
18:47:56 <samuelms> morganfainberg, will do, we just want to have as much feedbacks as we can on keystone (at home)
18:47:59 <dolphm> there are also dependent patches that touch v3 cloud policy
18:48:01 <morganfainberg> samuelms, fair enough.
18:48:06 <dolphm> rather, required patches
18:48:18 <samuelms> lbragstad, will check
18:48:22 <morganfainberg> so i think we need eyes on the spec - please provide feedback
18:49:04 <bknudson> the cloud policy file requires hardcoding the admin domain id.
18:49:08 <morganfainberg> and offer to help solve issues with the v3 policy file as you see them ( dolphm, please vocalize your gripes if possible there with that policy file )
18:49:08 <samuelms> lbragstad, just a small subsection, need to make it clearer. please leave a review :)
18:49:15 <lbragstad> samuelms: will do
18:49:31 <samuelms> morganfainberg, ++
18:49:31 <morganfainberg> bknudson, something we should figure out if can be fixed with this process
18:49:43 <morganfainberg> ok since we have two more topics i'm going to say we continue on
18:49:51 <samuelms> yep
18:49:57 <morganfainberg> #topic Third-Party Dashboard Spec
18:49:59 <dolphm> morganfainberg: my gripe is mainly the dependency on another magical domain - because we don't have a better way to express service-level authorization
18:50:06 <morganfainberg> _sweston, o/
18:50:15 <morganfainberg> #link https://review.openstack.org/#/c/135170/
18:50:51 <morganfainberg> _sweston may not be here at the oment, so we can circle back if he does show up.
18:51:00 <ayoung> what is a Third Party Dashboard?
18:51:03 <morganfainberg> i think he wants some people to take a look at the spec, i don't have much more info
18:51:18 <morganfainberg> so, we can try again next week or i'll ask him to come to #openstack-keystone to discuss
18:51:19 <ayoung> CI
18:51:20 <henrynash> what is CI?
18:51:29 <bknudson> continuous integration
18:51:33 <morganfainberg> moving on
18:51:34 <bknudson> jenkins and stuff
18:51:39 <samuelms> k
18:51:42 <dolphm> what does this have to do with keystone?
18:51:45 <morganfainberg> #topic Assignment Split
18:51:46 <ayoung> OK..this is a Gerrit workflow issue...got it
18:51:48 <morganfainberg> #link https://review.openstack.org/#/c/130954/
18:51:52 <morganfainberg> henrynash, o/
18:52:12 <morganfainberg> ayoung, we'll get him to explain it in -keystone or next week.
18:52:15 <ayoung> so if we were to introduce external LDAP tests, for example
18:52:18 <morganfainberg> ayoung, and give details.
18:52:22 <ayoung> ++
18:52:26 <ayoung> good to go
18:52:29 <henrynash> ok, so question has been raised as to whether teh current patch is correct in having the split of roles into their own backend
18:52:31 <topol> 130954, also known as the beast :-)
18:52:46 <morganfainberg> (8min)
18:52:52 <ayoung> henrynash, I vote yes for roles in their own backend
18:52:57 <henrynash> morganfainberg and I have laid down a couple of arguments on each side in teh review commens
18:52:58 <bknudson> can we get a better name than "resource" for the backend? everything is a resource.
18:53:02 <samuelms> henrynash, ++ from me
18:53:08 <henrynash> really want others to weight in with theie views
18:53:13 <morganfainberg> as do i
18:53:15 <topol> bknudson+++ great point
18:53:42 <ayoung> question was whether to split projects and domains into two different backends, and then name the backends appropriately
18:53:56 <henrynash> bknudson: my only defence is a) noone coudl come up witha  better name and b) in fedration language “resource” is the object you act on
18:54:10 <gabriel-bezerra> bknudson: ++
18:54:13 <ayoung> leave the actual role assignements in assignements, everything else gets its own backend based on its name
18:54:24 <morganfainberg> ayoung, this question is do roles split from assignment, where assignment is the engine doing the <attr> -> role mapping, and roles would be isolated from that
18:54:26 <henrynash> ayoung: that’s a seperate discussion (I hope….)
18:54:35 <ayoung> henrynash, lets have it now
18:54:46 <ayoung> we suggested it back when splitting identity and assignements
18:54:46 <morganfainberg> ayoung, i think that is the next conversation
18:55:03 <topol> it would seem that roles and assignemnts would fit well together. whats the counter argument?
18:55:06 <ayoung> if we are having trouble with names, then lest call "resourece" the project backend
18:55:21 <henrynash> topol: see the latets commnest in the patch set
18:55:23 <ayoung> and if we end up splitting it, we'll put domains into their own.  K?
18:55:23 <dstanek> does splitting roles have to be in this patch anyway - seems like a follow on patch for splitting assignment and identity
18:55:32 <morganfainberg> ayoung, more splitting is def. on the table, but we've got this already in line - name of the backends for the context of this disucssion is bikeshedding
18:55:44 <morganfainberg> so ignore name complaints for now, put those on the review.
18:56:00 <ayoung> morganfainberg, the question was whether to split roles from projects and domains, right?
18:56:12 <morganfainberg> ayoung, no, roles from assignment, the mapping part
18:56:15 <dolphm> i'm just going to remind everyone that i regret making roles a first class resource in the API. i wish they were just arbitrary strings owned by the policy files and using as mappings in the assignment backend. </digression>
18:56:20 <morganfainberg> ayoung, domains and project split would be different.
18:56:32 <morganfainberg> dolphm, that is mostly my point
18:56:50 <samuelms> the main idea was to keep assignment.mapper and assignment.connector (what we need to do the assignment itrself, i.e the actual roles)
18:56:52 <bknudson> dolphm: if roles were their own backend you could do that.
18:56:52 <morganfainberg> dolphm, and arguments against splitting role from assignment (new assignment)
18:56:54 <dolphm> it's hard to find a place for them in keystone because they don't belong in keystone :(
18:57:07 <ayoung> dolphm, they start meaning something with the autogenerated policy,
18:57:23 <ayoung> they really are part of the policy language
18:57:36 <lbragstad> ~3 minutes left
18:57:36 <morganfainberg> samuelms, but that is just adding another abstraction that does what we do today - meaning the assignment backend needs to then be mapped pretty much like today
18:57:38 <henrynash> dolphm, morganfainberg: and my argument for having them separte is that they will eventually disappear…but while we have them as first class resoruces, we shouldn’t require an assignment mapping engine to be responsile for their management
18:57:50 <dolphm> ayoung: they're an artifact of the policy files
18:58:05 <samuelms> henrynash, ++
18:58:32 <morganfainberg> my only other point is extra splitting down the line is easier than unsplitting things
18:58:34 <samuelms> henrynash, I think having an example of how easy it should be to plug a new assignment backend would be help
18:58:49 <morganfainberg> i've posted my views as comments on the review, please read them, and weigh in on it.
18:58:51 <dstanek> morganfainberg: ++
18:58:53 <ayoung> henrynash, OK,  I'd argue that we should change "resource" to "proejct" and then if anything needs to be split off of that, they get their own backends
18:58:53 <samuelms> henrynash, like a simple poc
18:59:03 <morganfainberg> further splitting such as domains and projects will be a different conversation.
18:59:05 <ayoung> I'd like roles to be split, but I can work with it either way
18:59:12 <henrynash> my main goal is that i REALLY want to get the split patch merged immediately after we cut K1…it’s a huge rebase to maintain…and my fingers are tired!
18:59:20 <ayoung> I don't really need assignments split, but again, won't hurt to do it
19:00:03 <rodrigods> henrynash, ++
19:00:09 <dolphm> ayoung: that's kind of where i'm at
19:00:09 <ayoung> my feeling is that nay argument for splitting assignments really will be replicated in splitting the other pieces off.  But I'm not going to hold anything up
19:00:12 <morganfainberg> i am of the opinion this is a topic that no one person can answer - so everyone, core or not, should weigh in and we'll see where the conversation goes. this is a big shift
19:00:24 <morganfainberg> and has wide implications on what we're supporting in the future
19:00:29 <morganfainberg> and that's time
19:00:42 <morganfainberg> we'll keep this conversation going in -keystone and on that review
19:00:42 <dolphm> dun dun DUN.
19:00:46 <morganfainberg> #endmeeting