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