18:02:12 <morganfainberg> #startmeeting Keystone
18:02:14 <openstack> Meeting started Tue Jun 23 18:02:12 2015 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:17 <openstack> The meeting name has been set to 'keystone'
18:02:24 <morganfainberg> #topic Liberty-1
18:02:26 <henrynash> (sneaks in late)
18:02:32 <morganfainberg> Liberty-1 was tagged... seconds ago
18:02:50 <morganfainberg> this means... we're up against our spec proposal freeze deadline
18:02:52 <bknudson> yaay!
18:02:59 <iurygregory> o/
18:03:18 <ayoung> Pretty sure I've gotten 0 through the review process since the summit
18:03:20 <morganfainberg> if the spec isn't approved by the end of the week, we are likely going to need an email thread to just make sure we're on track.
18:03:35 <morganfainberg> just a "hey here is where we are with it, and this is reasonable to hit in liberty"
18:03:44 <morganfainberg> this is for API impacting changes
18:03:58 <browne> so what's the final word on https://blueprints.launchpad.net/keystone/+spec/role-descriptions.  are we okay without a spec?
18:04:01 <morganfainberg> non-api impacting changes can adhere to the previous l2 milestone
18:04:08 <morganfainberg> browne: sec.
18:04:09 <bknudson> is there anything that anybody really wants to get in for L?
18:04:25 <ayoung> browne, that is so low priority
18:04:39 <bknudson> I need to know what spec reviews to focus on.
18:04:40 <browne> yep agreed
18:04:44 <hogepodge> o/
18:04:52 <ayoung> bknudson, dynamic policy
18:04:58 <htruta_> bknudson: you'll soon have the reseller onw
18:04:59 <htruta_> one*
18:05:11 <morganfainberg> bknudson: i think the only outstanding specs that need love are around reseller (is_domain, etc) and dynamic policy related
18:05:17 <morganfainberg> bknudson: for the api-impacting freeze
18:05:26 <raildo> bknudson, we need to decide the token things... so henrynash  proposed this spec: https://review.openstack.org/#/c/193543/
18:05:36 <gyee> dynamic is a mother of all specs
18:05:40 <gyee> dynamic policy
18:05:51 <ayoung> https://review.openstack.org/#/c/192422/  POPlicy by URL is required
18:05:54 <morganfainberg> we have either already approved the other API impacting...or it can wait until the next release
18:05:54 <gyee> it has many childrens
18:05:59 <bknudson> sounds like if I start looking at dynamic policy I'll never finish
18:06:09 <morganfainberg> bknudson: i'll let you take that up with ayoung
18:06:26 <ayoung> bknudson, I had an overview spec, but it was deemed "not a spec"
18:06:36 <gyee> ayoung, can you prioritize the ones that are *realistic* for Liberty?
18:06:50 <dolphm> i have a substantially simpler groups-in-tokens draft that i should have up by tomorrow, assuming barbican folks are okay with a slightly different approach on their end
18:06:56 <ayoung> gyee, my current state of mind says none of it.
18:06:57 <morganfainberg> dolphm: ok.
18:07:03 <ayoung> I'm freaking depressed
18:07:06 <bknudson> I wouldn't approve an overview "spec"
18:07:14 <morganfainberg> dolphm: sounds good, lets keep that one on that one
18:07:19 <morganfainberg> bknudson: that was why i -2'd it
18:07:20 <samueldmq> gyee: we're still in the priorization process for L, we'll have a point on it later in this meeting
18:07:35 <samueldmq> ayoung: shhh plz, don't be depressed :-)
18:07:39 <morganfainberg> bknudson: the overview spec was not really useful for us. samueldmq did a great job of moving it to the wiki
18:07:50 <morganfainberg> bknudson: it is much much much better where it is now.
18:07:57 <morganfainberg> samueldmq: what was the link for the page?
18:07:57 <samueldmq> morganfainberg: thanks :-)
18:08:03 <samueldmq> #link https://wiki.openstack.org/wiki/DynamicPolicies
18:08:05 <marekd> samueldmq: can you link this wiki page?
18:08:06 <morganfainberg> thanks
18:08:06 <henrynash> morganfainberg: in terms of policy, I’d like to prioritise ensuring we can avoid the use of domain scoped tokens in L
18:08:11 <marekd> samueldmq: oh, thanks
18:08:21 <morganfainberg> henrynash: that falls under reseller afaict
18:08:36 <morganfainberg> henrynash: and yes, that is on the list
18:08:40 <henrynash> ok
18:08:41 <ayoung> morganfainberg, and I think that all specs should be moved to the wiki and specs as they exist now should die, but I really don't feel like we are capable of making progress here
18:08:54 <morganfainberg> ayoung: different conversation.
18:08:59 <samueldmq> ayoung: plz :(
18:09:16 <morganfainberg> ayoung: i'm not opposed to it, but that is not something we can cover with what we have on the agenda today (we can discuss in -keystone as well)
18:09:23 <htruta_> henrynash, morganfainberg hope we have some room to define the project scoped token today
18:09:24 <morganfainberg> but i'm inclined to want that to be a ML topic
18:09:29 <david8hu> better if this is a face to face discusion
18:09:39 <morganfainberg> ok
18:09:44 <ayoung> we need to have the discussion with sdague before I can tell you what is worth pushing for
18:09:54 <morganfainberg> ayoung: and that will be soon :)
18:10:00 <samueldmq> we have a point for that
18:10:00 <morganfainberg> ok moving on:
18:10:01 <samueldmq> yes
18:10:08 <morganfainberg> #topic Review of Keystone Blueprints for No-Spec Required
18:10:24 <morganfainberg> #link https://blueprints.launchpad.net/keystone/+spec/role-descriptions
18:10:26 <morganfainberg> no one said this needed a spec
18:10:31 <morganfainberg> it is minor
18:10:39 <bknudson> it changes the api so it needs a apec
18:10:41 <bknudson> spec
18:10:45 <morganfainberg> does it change the API?
18:10:49 <gyee> yes
18:10:50 <henrynash> hruta_: see my comemnt in gerrit on https://review.openstack.org/#/c/193543/ as the proposal for L
18:10:55 <morganfainberg> uhm
18:11:01 <morganfainberg> i think roles already have extra support
18:11:06 <bknudson> should be a short one
18:11:10 <morganfainberg> this just amkes it a first class
18:11:15 <gyee> bknudson, nah, just use 'extra' :)
18:11:26 <morganfainberg> ok so, anyway browne: ^ this needs a spec.
18:11:41 <htruta_> henrynash, nice. was on my read list
18:11:42 <morganfainberg> please do a minimal one - there should be a lot of N/A in your spec.
18:11:47 <bknudson> gyee: with extra you could store anything you want!
18:11:51 <bknudson> policies!
18:11:54 <morganfainberg> since it isn't security, performance, etc
18:12:16 <morganfainberg> jamie is not here
18:12:21 <morganfainberg> skipping his topic for the moment
18:12:24 <browne> morganfainberg: ok, thanks, np
18:12:34 <morganfainberg> on to the big one
18:12:38 <ayoung> browne, I'm going to say no to role descriptions
18:12:38 <morganfainberg> #topic Dynamic Policies: current status, scope for L, cross-project requirements and next steps
18:12:41 <samueldmq> o/
18:12:45 <ayoung> roles should not even have ids.
18:12:45 <morganfainberg> ayoung, samueldmq, sdague o/
18:13:00 <browne> ayoung: no in general or no for liberty?
18:13:02 <sdague> o/
18:13:04 <samueldmq> so ... overview spec is now a wiki, as we said earlier
18:13:10 <samueldmq> #link https://wiki.openstack.org/wiki/DynamicPolicies
18:13:19 <samueldmq> this is a first try and still have some points to be clarified/defined, including
18:13:20 <ayoung> OK,  so DYn Policy has stalled trying to make sure we can handle sdague 's concerns ...specifically about microversions?
18:13:25 <samueldmq> i) how to represent nova microversions, what support is needed on oslo.policy
18:13:29 <samueldmq> ii )whether we should unify the policy files or not
18:13:37 <morganfainberg> samueldmq: any service microversions (nova is just the first)
18:13:41 <samueldmq> those are the two points we'd like to address in this initial discussion :)
18:13:51 <sdague> ayoung: I think that's a pretty unfair characterization honestly
18:13:56 <samueldmq> morganfainberg: ++
18:14:03 <ayoung> I think that was the crux of what you were concerned about:  that if a new version of Nova came out with new microversioned APIs, it would need to have the default policy embedded?
18:14:11 <ayoung> sdague, I',m trying to understand your concern
18:14:15 <breton> why do we even have policies as json and not as python functions?
18:14:22 <sdague> breton: ++
18:14:37 <sdague> see my initial mailing list thread about embedding base policy in code
18:14:47 <ayoung> breton, policy was designed as something that is tweakable in deployment
18:14:52 <sdague> http://lists.openstack.org/pipermail/openstack-dev/2015-June/065496.html
18:14:54 <morganfainberg> at some level we need some amount of customization. but there is no reason we can't embed base policy in code (no technical reason)
18:14:56 <ayoung> sdague, so, I thin I actually agree with you
18:15:00 <morganfainberg> #link http://lists.openstack.org/pipermail/openstack-dev/2015-June/065496.html
18:15:03 <ayoung> but not quite as you might have seen it:
18:15:03 <breton> having them pythonic would lets us use classes hierarchy and stuff
18:15:16 <gyee> breton, not all security auditors know how to read python code
18:15:21 <ayoung> gyee, stop
18:15:24 <ayoung> that is not helpful
18:15:34 <samueldmq> breton: gyee that's a separate conversation I think ... how to represent it
18:15:36 <morganfainberg> gyee: lets leave that out - no one knows how to read policy.json either
18:15:36 <ayoung> the real issue is whether they are customizable buy the end user
18:15:51 <ayoung> and I think the complaint is that the current policy mechanism is too brittle
18:15:59 <ayoung> you can easily break things, etc
18:16:00 <bknudson> from what I've seen of the default policies they're a long ways from what they should do.
18:16:06 <ayoung> bknudson, agreed
18:16:28 <bknudson> as far as giving you a deployment that prevents users from doing what they shouldn't
18:16:48 <ayoung> and that is what I've been trying to solve.  sdague is also trying to solve a comparable problem with microversions, and I think the two have the possibility of conflicing, which is why I startexd with that
18:16:50 <bknudson> e.g., the "nova" service user has "admin"
18:16:56 <samueldmq> I think two main points we should be addressing here should be
18:17:04 <samueldmq> i) how to represent nova microversions, what support is needed on oslo.policy
18:17:10 <samueldmq> ii )whether we should unify the policy files or not
18:17:16 <ayoung> samueldmq, hold on
18:17:35 <morganfainberg> ayoung: i agree with samueldmq
18:17:46 <ayoung> the main point, samueldmq as we said before, is to try to get to "common meaning of policy"
18:17:50 <morganfainberg> but inverting the order
18:17:56 <ayoung> morganfainberg, I don't disagree, just he's jumping ahead
18:17:56 <samueldmq> morganfainberg: ++
18:18:01 <morganfainberg> ayoung: ok
18:18:05 <ayoung> let's define the problem:
18:18:07 <morganfainberg> ayoung: just making sure we're still on track
18:18:47 <ayoung> so we start with but 968696.  That is due to the admin role being origianlly defined as a global role
18:19:09 <ayoung> that pattern spread, but we were working towards scope
18:19:31 <ayoung> all roles should be scoped to some project or domain
18:19:48 <ayoung> lets just use the word project to mean both for now
18:20:21 <bknudson> why should all roles be scoped to a project?
18:20:22 <ayoung> so  lets say that we first just want to get it so that all of the policy enforcement can deal with "admin on a project"  as the primariy sdope of control
18:20:43 <ayoung> bknudson, I think you are misunderstanding
18:20:51 <ayoung> roles are defined as assigned to a project
18:21:06 <bknudson> you said "all roles should be scoped to some project or domain" and I asked why.
18:21:19 <morganfainberg> ayoung: defined as an assignment of a user with X role on Y Project? or are you saying something else?
18:21:20 <ayoung> what I think you are asking is "should the power that implies be limited to resources in that project"
18:21:41 <ayoung> bknudson, we don't have global roles in Keystone anymore.  dolphm did away with them several releases ago
18:21:46 <ayoung> pretty sure it was dolphm
18:21:54 <ayoung> morganfainberg, yes  that is correct
18:22:03 <samueldmq> groups/domains ...
18:22:19 <ayoung> samueldmq, users don't have roles in groups
18:22:20 <morganfainberg> ok so i have a silly question.
18:22:29 <ayoung> and we are treateing domains as projects for this discussion
18:22:41 <morganfainberg> ignoring keystone [we're special in this case]
18:22:55 <samueldmq> I think we should go directly to the points we're trying to address ... we won't have enough time to talk about all the details
18:23:22 <samueldmq> I'd prefer to say ... an approach is to unify policies, which has those advantags .. but there are  some issues, as pointed out by sdague
18:23:31 <ayoung> so...lets address the point that sdague and breton brought up
18:23:41 <samueldmq> so people would be aware on the points we're diverging, and we could try to find solutions on the hard points
18:23:46 <ayoung> "why is policy in json and not in python"
18:25:08 <ayoung> breton, I think the answer is that policy is really a cross cutting concern, and it was designed to be based on the role that comes in the token.  What has happend, though, is that the scope of policy has been slowliy increasing to cover things beyond role based access control
18:25:36 <ayoung> breton, sdague here is what I was thinking would match your concerns:
18:26:03 <ayoung> each API has a scope check.  That check says "make sure the scope of the token matches the scope of the API"  and that logic is done in python
18:26:21 <bknudson> what's the scope of an api
18:26:37 <ayoung> bknudson, in the case of, say, a VM, it is the project that the VM is inside
18:26:53 <ayoung> bknudson, since the API actually has the Project ID in the URL, it is easy for Nova
18:27:07 <ayoung> bknudson, for KEystone it is trickier, as the resources are referecned by ID
18:27:24 <ayoung> and then we need to fetch the actual resource out of the backend prior to enforcing policy
18:27:46 <ayoung> what Nova needs to do is just confirm that the project ID in the URL matches the project_id on the resource
18:27:54 <bknudson> does nova still have the project embedded in the URL?
18:28:03 <ayoung> bknudson, it did on the APIs I saw
18:28:12 <ayoung> bknudson, I am not assuming that to be the case everywhere
18:28:15 <bknudson> although with microversioning I guess they could get rid of it
18:28:24 <morganfainberg> sdague: did we get rid of the project id in the requests?
18:28:28 <morganfainberg> sdague: for nova?
18:28:31 <sdague> it does, though the intent once upon a time was to deprecate it
18:28:41 <david8hu> nova has a admin_or_owner.  owner check is based on project_id
18:28:43 <morganfainberg> ayoung: but the scope (project id) is still in the auth_context
18:28:43 <sdague> it's still there, this seems kind of deep in the weeds though honestly
18:28:44 <ayoung> bknudson, and, it really doesn 't matter;  it is up to the project to ensure that the scope of the request is correct, within the terms of the API
18:28:44 <morganfainberg> so ...
18:28:48 <morganfainberg> it doesn't matter
18:29:00 <ayoung> so...lets say that we were to try and pull that out of the current policy
18:29:06 <ayoung> that should not be changed by end users
18:29:06 <sdague> because, part of the set of concerns that I'm bringing up are what you are going to get from a lot of projects
18:29:13 <morganfainberg> can we move beyond this point as we can determine scope from what is passed from middleware
18:29:33 <sdague> the end game and what problems are trying to be solved aren't really clear anywhere
18:29:34 <ayoung> sdague, what I am saying is, that part matches the concern you had.
18:29:35 <morganfainberg> and move back on track - what sdague is bringing up specifically
18:29:48 <ayoung> The part that we want dynamic is what role to give the user in order to execute the API
18:30:21 <bknudson> with the default policy it doesn't matter what role you have, you can boot an instance as long as you have any role on the project
18:30:27 <sdague> * users should be able to discover their allowed permissions for a service in advance - that's at thing that wants to be solved
18:30:43 <ayoung> sdague, OK,  let me address that;
18:30:46 <sdague> * projects would like to be able to ensure sane defaults are enabled with new code
18:30:47 <ayoung> there are two views
18:31:05 <ayoung> one is that you ask each endpoint "what policy..." and the other is that we centralize
18:31:19 <ayoung> the first is kindof what you suggested with ad /polcy URL
18:31:30 <ayoung> a   /policy URL
18:31:53 <sdague> sure, that was a way to address the discovery of policy by users or other services in a way that scales in the big tent
18:32:05 <sdague> because the list of all things that connect to keystone is an unbounded unknow
18:32:16 <morganfainberg> sdague: ++
18:32:35 <ayoung> sdague, well, no, not unbounded.  We have a list of registered endpoints
18:32:39 <ayoung> and each endpoint has a service
18:32:39 <bknudson> so I'd do http://localhost/compute/policy?
18:32:47 <sdague> bknudson: that was my thinking
18:33:22 <samueldmq> and get the policy for a service, it doesn't matter its version and exposed APIs
18:33:24 <sdague> if you are a user you get something that looks like a policy.json over the wire that was customized to your user. If you were admin you could get a more global definition.
18:33:41 <morganfainberg> FYI: we're going to timebox this to 11:45 for this discussion
18:33:52 <ayoung> sdague, so here is where that idea starts to conflict with dynamic policy
18:33:56 <bknudson> what's an admin?
18:34:01 <morganfainberg> so 12 more minutes (so we can hit the other topics) - we can come back after if needed
18:34:12 <sdague> all the semantics would need to be worked out for such an interface, as it would be a contract that any service would need to implement that wanted to participate in dynamic policy
18:34:24 <ayoung> right now, a role is not specific to a service or endpoint.  But each endpoint has their own way of interpreting it
18:34:37 <sdague> bknudson: tbd, there should be some kind of admin that can get this
18:34:54 <ayoung> lets give two possible approaches
18:35:00 <ayoung> 1.  COmpletely static policy
18:35:07 <ayoung> 2.  dyanmic policy centralized in Keystone
18:35:27 <sdague> ayoung: sure, I think moving services to service scoped roles is a good first step
18:35:39 <bknudson> we don't have static policy now. If you change the policy the server starts using it.
18:35:52 <ayoung> if we go with 1, then to customize, the operator needs to write their own, distribute via puppet and make sure the policy is sane
18:36:02 <ayoung> bknudson, what we have now is static
18:36:03 <sdague> I don't think you'll find much resistance in moving nova from using admin to compute_admin
18:37:05 <morganfainberg> sdague: if there is significant resistance to that i don't know what to say :P
18:37:08 <ayoung> sdague, yeah, I think we all want to enable service scoped roles, and a few other ways of namespcaing them too
18:37:33 <ayoung> so..even if we do that, we need to deal wioth workflows like nova boot that hit multiple services...
18:37:41 <ayoung> and making sure that the roles are sane across those
18:37:51 <henrynash> are we confusing the teh fact that a) we want to make it easy to “distribute policy” by have differnet mechanism to  puppet (i.e. ceentralised in keysone, and all servcies get their policy from there), and b) the ability for a user to ask “what can I do on endpoint X”….to be me, these aren’t in conflvt
18:37:51 <bknudson> seems like the resistance would be just in getting it merged since I assume there's no nova spec for it
18:38:13 <sdague> ayoung: and, moving to scoped admin (and possibly other) roles would be a lot easier to move in with sane deprecation if we had the base policy in code, and we could realize the user was still specifying admin when they should have meant compute adming in their policy.json
18:38:14 <ayoung> now...lets say an end user has customized tjheir policy in a statci deployment, and a new microversion comes out,,,then what
18:38:29 <ayoung> I see two options
18:38:35 <ayoung> 1.  have a decent default
18:38:45 <ayoung> 2.  merge in the new stock policy with the modified policy
18:38:56 <bknudson> I hope real deployments aren't using the default policy.
18:38:57 <ayoung> both kinda suck, but in different ways
18:39:02 <ayoung> bknudson, most are
18:39:05 <morganfainberg> ayoung: i think the sane default would be the one i'd pick here.
18:39:19 <ayoung> morganfainberg, so...I would too
18:39:20 <morganfainberg> ayoung: strictly because merging policy has a bigger surface area of "what can go wrong"
18:39:38 <browne> bknudson: i think most real deployments use the default policy because it's too hard to customize
18:39:40 <morganfainberg> not because one is clearly better - the failures in merging are more likely
18:39:41 <sdague> right, which was another reason why base policy in code was something we wanted
18:39:49 <ayoung> I would say "If I don't have a rule that covers thiss you need to be an admin (as Nova defines it) to execute this API"
18:39:57 <bknudson> scary
18:40:08 <morganfainberg> ayoung: or whatever nova defines the base rule as.
18:40:22 <samueldmq> sdague: and then updating the policy in keystone via /policy
18:40:23 <sdague> bknudson: it's not scary, it's bad on us all for providing terrible defaults
18:40:35 <ayoung> morganfainberg, we should probably allow namespaced defaults.  I  muigjht even have a spec for that already
18:40:48 <ayoung> so compute::default  versus image::default
18:40:59 <morganfainberg> ayoung: sure - i think we can alredy do that fwiw
18:41:02 <ayoung> but..that preuspposed we have one policy file that covers both nova naglance..still up for debate.
18:41:03 <sdague> samueldmq: so, honestly, I think a realistic set of L goals would be the namespacing and the /policy interface, and leave it at that
18:41:14 <ayoung> sdague, I don't like /poliucy
18:41:18 <sdague> with those components, in M you could start building the dynamic bits on top
18:41:25 <samueldmq> sdague: and supporting microversions in oslo
18:41:25 <ayoung> it means we are dependent on a change going in to every single project
18:41:27 <morganfainberg> sdague: would that include policy-in-code work? or still straight static
18:41:33 <ayoung> we won;t get that for several releases
18:41:51 <sdague> morganfainberg: it should include policy-in-code
18:41:53 <morganfainberg> ok
18:41:57 <morganfainberg> just defining scope
18:42:00 <morganfainberg> :)
18:42:04 <sdague> because I don't see how to deprecate out admin sanely to users without it
18:42:16 <morganfainberg> sdague: i could come up with a scheme, but i think pure code makes it easier
18:42:32 <morganfainberg> ayoung: what is inherently wrong with /policy
18:42:33 <samueldmq> 2 minutes left .. any decisions on the scope ?
18:42:36 <sdague> ayoung: so, I get this means that projects need to do a thing to be in the dynamic policy pool
18:42:41 <sdague> but I think that's a good thing
18:42:41 <samueldmq> for sure we need to address microversions in oslo.policy
18:42:48 <ayoung> sdague, no
18:42:50 <morganfainberg> ayoung: especially if that lets you ask the question of "what does nova let me do"?
18:42:58 <morganfainberg> samueldmq: thanks for watching the clock
18:43:06 <ayoung> sdague, fetching dynamic policy is going to be part of keystone middleware
18:43:13 <ayoung> or it is oslo.policy
18:43:30 <ayoung> morganfainberg, what if there are 15 nova endpoints?  Horizon is going to go and query each one?
18:43:38 <samueldmq> what do we do when we upgrade a service ?
18:43:40 <bknudson> what's a sane default for a new api? it could be "admin-only", but that doesn't seem right.
18:43:53 <sdague> bknudson: it's going to be decided by the project
18:44:01 <samueldmq> if keystone owns unified, does keystone need to update unified for every api change in any other servce ?
18:44:01 <morganfainberg> ayoung: you have the same issue with centralizing it... what version does nova run.. what is that endpoint's policy
18:44:08 <sdague> that domain knowledge is back in the project
18:44:08 <morganfainberg> ayoung: it's the same question just spun differently
18:44:09 <ayoung> sdague, I think, instead of /policy, it would make more sense to let the projects push their updated policy to Keystone itslef
18:44:32 <morganfainberg> ayoung: does it hurt us to have /policy today and push to keystone tomorrow?
18:44:40 <morganfainberg> ayoung: i could see benefit to /policy in *any* case
18:44:44 <sdague> ayoung: if it's a REST api that keystone can call, I don't understand why that's no ok
18:44:46 <ayoung> morganfainberg, Horizon doesn't know about the endpoints until they get the token...It is in the service catalog
18:44:53 <bknudson> sdague: are you going to need some more default roles?
18:45:20 <ayoung> sdague it further fragments policy, instead of getting us a common view of it.  It reinforces 968696, not fixes it
18:45:21 <samueldmq> time's over ... decisions ?
18:45:25 <sdague> because I imagine the end game is keystone goes and collects and merges those and makes that information available to users from a single point
18:45:37 <morganfainberg> samueldmq: let this last topic close, thanks
18:45:38 <ayoung> sdague, hear me out...here is what I propose instead
18:45:53 <ayoung> we split policy.  The ojnly part that is dynamic is the RBAC part
18:45:53 <morganfainberg> ayoung, sdague: 1 minute
18:45:57 <bknudson> do you still have a weekly meeting for this?
18:46:06 <samueldmq> morganfainberg: sure, putting more time on it is your decision, thanks
18:46:10 <ayoung> RBAC will provide a namespaced default
18:46:33 <ayoung> Nova fetches its modified policy for the roles (olnly) from Keystone via oslo/meystonemiddleare
18:46:49 <ayoung> if we want hierarchical roles, we can do thiose in policy generation
18:46:50 <samueldmq> bknudson: no, I think we could have, but ML can be enough for now ?
18:46:55 <morganfainberg> ayoung: the fetch part seems like it could come as a followup
18:47:19 <ayoung> if we do the /policy thing..itis hugely static, we ;ve just made it back to a Puppet function, with no way to tie the roles teogther etc within the system of record
18:47:40 <sdague> ayoung: I don't understand why you think that, it's not static, it's federated
18:47:47 <morganfainberg> sdague: ++
18:47:55 <samueldmq> /policy is just an alternative from uploading the policy.json which is shipped with the code
18:48:04 <samueldmq> that's how I see it :)
18:48:05 <morganfainberg> ok so here is my proposal: /policy now
18:48:13 <morganfainberg> the fetching from keystone follows
18:48:27 <morganfainberg> we can enhance keystone to be smarter being able to answer the questions as we go
18:48:35 <morganfainberg> directly, so horizon et al don't need to ask the endpoints
18:48:44 <ayoung> -2
18:48:45 <morganfainberg> in steps, /policy still does the same thing
18:48:57 <morganfainberg> but when it fetches from keystone (future) it now is dynamic
18:49:09 <ayoung> it does not address any of the issues other than "how do we query"
18:49:12 <morganfainberg> and you can query both sides "what does keystone think" and what "nova thinks"
18:49:57 <ayoung> so we toss hierarchical roles?
18:49:59 <morganfainberg> ok anyway
18:50:09 <ayoung> and we make bug 968696 a won;'t fix  Or reassign top Nova?
18:50:10 <openstack> bug 968696 in Keystone ""admin"-ness not properly scoped" [High,Confirmed] https://launchpad.net/bugs/968696 - Assigned to Adam Young (ayoung)
18:50:15 <morganfainberg> we can enhance /policy to do hierarchical roles
18:50:20 <morganfainberg> the thing is it is not strictly static
18:50:27 <morganfainberg> it's building on work
18:50:30 <samueldmq> ayoung: nova still needs to get the modified policy back using middleware
18:50:34 <morganfainberg> it can't be an all encompassing solution day 1
18:50:36 <samueldmq> ayoung: /policy just provides the stock policy
18:50:37 <morganfainberg> it will never get done
18:50:38 <samueldmq> ayoung: that's all
18:50:49 <sdague> right, /policy is "seed of truth"
18:50:54 <morganfainberg> sdague: ++
18:50:57 <sdague> dynamic would layer on top of it
18:51:01 <samueldmq> yes, taht's the only difference
18:51:02 <ayoung> is /policy stock only...taht is...you guys are not thinking this through
18:51:12 <ayoung> either it is stock only, in which case it gets out of date
18:51:19 <ayoung> or it is dynamic, in which case it is redundant
18:51:36 <morganfainberg> this sounds like perfect being the enemy of better-than-the-crap-we-have-today
18:51:45 <ayoung> morganfainberg, no.
18:52:03 <ayoung> morganfainberg, we don;t need to publish /plocy
18:52:09 <ayoung> that gets shipped with the code
18:52:15 <bknudson> if we're going to fundamentally redesign policy then let's not even try to fit it in with what we've got now
18:52:15 <samueldmq> sdague: /policy only provides the initial source of truth, right ?
18:52:17 <ayoung> that can be uploaded to Keystone at any point
18:52:24 <morganfainberg> ayoung: i think this is how we bridge to what you want
18:52:32 <sdague> samueldmq: that was my original thinking
18:52:43 <samueldmq> ayoung: so yes, /policy is just the stock policy
18:52:46 <morganfainberg> ok we're losing sdague and we need to continue on
18:52:46 <sdague> it would be the composite of policy in code + policy in json files from the services
18:52:54 <david8hu> bknudson, +1
18:52:54 <morganfainberg> we'll need to table this for further discussion
18:52:59 <ayoung> sdague, is /policy stock?  So idf I then fetch dfynamic policy from Keystone it is ouyt of sync?
18:53:51 <morganfainberg> sorry moving on.
18:53:52 <ayoung> Ok, if this is what you guys agree oon, I iwll abandon my specs
18:53:56 <morganfainberg> #topic Make bandit jobs voting?
18:54:02 <morganfainberg> #undo
18:54:02 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x95d6350>
18:54:10 <morganfainberg> #action Further discussion on policy needed.
18:54:24 <morganfainberg> #info Dynamic policy or /policy, or something in the middle?
18:54:30 <samueldmq> /policy provides the source of truth to keystone, customizations occur in keystone, keystone provides customized policy back to services thorugh middleware
18:54:46 <morganfainberg> #topic Make bandit jobs voting?
18:54:50 <morganfainberg> bknudson o/
18:54:52 <bknudson> hopefully this is quick...
18:54:59 <bknudson> the bandit jobs have been running for several weeks
18:55:01 <bknudson> non-voting
18:55:11 <bknudson> and was wondering if they could be made voting?
18:55:13 <morganfainberg> i'm ok with them becoming voting
18:55:18 <morganfainberg> unless someone has issue with it
18:55:24 <bknudson> if so I'll propose the changes to -infra
18:55:52 <bknudson> need to sync the keystoneclient auth feature branch first.
18:55:55 <morganfainberg> any issues with bandit? concerns?
18:56:09 <morganfainberg> bknudson: ok i think go ahead
18:56:15 <bknudson> great, thanks
18:56:20 <morganfainberg> bknudson: ping me and i'll +1 the change so -infra will push it through
18:56:38 <morganfainberg> skipping KSA and other repo stuff (since we're still missing jamie)
18:56:41 <morganfainberg> #topic Service providers by domain
18:56:45 <morganfainberg> rodrigods: o/
18:56:47 <rodrigods> this *can* be quick :)
18:56:52 <rodrigods> spec: https://review.openstack.org/#/c/188534/
18:56:58 <rodrigods> so, with reseller we will enforce domains as an administrative boundary - our proposal is to add the possibility to create service providers in the domain scope (basically, add the domain_id to service_provider table and filter the service_provider list in tokens based on its scope). Service providers with domain_id = null are available for all users in the cloud (as it is today)
18:57:26 <rodrigods> It will only change the API to create service_providers by including a new field in the request body and change its rule in the policy.json file
18:57:28 <marekd> so you can burst to cloud X only if you are a member of domain D ?
18:57:34 <rodrigods> marekd, yes
18:57:43 <morganfainberg> marekd: i think we initially wanted to solve that with endpoint filtering
18:57:47 <marekd> endpoint filtering cannot do that?
18:57:54 <morganfainberg> i'd rather not lock us into only 1 domain can do it
18:57:59 <morganfainberg> but only domians that see the SPs can
18:58:32 <morganfainberg> rodrigods: so i think lets put this into the filtering
18:58:34 <marekd> morganfainberg: exactly, does endpoint filtering in todays scoped are enough to give what rodrigo wants?
18:58:39 <morganfainberg> if the SP isn't in the catalog, we don't issue saml for it
18:58:50 <morganfainberg> rodrigods: but otherwise *yes* this is a good direction and way to go
18:59:04 <morganfainberg> marekd: will need an added check to not issue saml for an endpoint not in the SP list
18:59:07 <rodrigods> morganfainberg, yeah... today service providers are not "inside" the catalog
18:59:24 <morganfainberg> rodrigods: they are part of the catalog - lets enhance filtering to cover them too
18:59:31 <marekd> ++
18:59:33 <morganfainberg> rodrigods: but your idea is sound
18:59:40 <rodrigods> morganfainberg, makes sense
18:59:42 <morganfainberg> rodrigods: cool
18:59:46 <marekd> we were planning on that either way.
18:59:52 <rodrigods> morganfainberg, should this fit in L?
18:59:56 <morganfainberg> #action rodrigods to enhance filtering to cover Service Providers
19:00:01 <morganfainberg> rodrigods: please try to
19:00:02 <morganfainberg> it's worth it
19:00:17 <morganfainberg> last topic
19:00:20 <rodrigods> morganfainberg, marekd, great! thanks for the feedback
19:00:22 <morganfainberg> and we're out of time
19:00:29 <raildo> :(
19:00:29 <morganfainberg> henrynash: your is_domain question - part of reseller
19:00:41 <morganfainberg> henrynash and domain scoped tokens
19:00:43 <henrynash> I have posted an updated spec: https://review.openstack.org/#/c/193543/
19:00:48 <morganfainberg> henrynash: and yes it should be included in the L cycle
19:00:54 <morganfainberg> #endmeeting