18:00:12 #startmeeting keystone 18:00:13 Meeting started Tue Jun 21 18:00:12 2016 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:17 o/ 18:00:17 The meeting name has been set to 'keystone' 18:00:17 o/ 18:00:20 hi 18:00:27 o/ 18:00:31 ٩(●̮̮̃●̃)۶ 18:00:31 hello 18:00:46 o/ 18:00:53 #link agenda https://etherpad.openstack.org/p/keystone-weekly-meeting 18:01:08 o/ 18:01:11 * stevemar has a full cup of tea in front of him and ready for a long meeting 18:01:32 hello 18:01:52 #topic release status 18:02:15 just wanted to give a status here, we're in R15 of the schedule http://releases.openstack.org/newton/schedule.html 18:02:15 (hi) 18:02:18 (it counts down) 18:02:48 R-15 18:02:48 yes 18:02:48 We're between the proposal spec freeze (R18) and spec freeze (R13) 18:02:49 \o 18:02:58 \o 18:03:07 so start reviewing keystone specs :) 18:03:14 (which i also have to do...) 18:03:16 stevemar: ++ 18:03:23 for the first sentence 18:03:27 :) 18:03:36 #link https://review.openstack.org/#/q/project:openstack/keystone-specs+status:open 18:03:45 handy link for open keystone specs ^ 18:04:11 thats all I have to say about that for now, thanks for listening :) 18:04:28 any qs? 18:04:57 next topic 18:04:59 #topic keystoneauth entry points for Kerbers and SAML2 18:05:13 kerberos* 18:05:15 ayoung is not online o_O 18:05:31 dolphm with the quick -1 18:05:38 stevemar, just appeared 18:05:38 so i think this is mostly done 18:05:45 ayoung: o/ 18:05:59 ah had not reconnected 18:06:01 I was sitting here wondering where everyone was 18:06:05 So quick one here...I think most of the auth plugin issues are solved 18:06:29 there was one with KC, have not checked with Auth, but the unscoped SAML2 plugin could never have worked. 18:06:39 jamielennox did some fancy stuff with loading extras, crinkle made the kerberos stuff available and jamielennox refactored the saml bits last night 18:07:15 yep, so i unploaded a new version of the saml refactor that i was just setting up an environment to test 18:07:24 it exposes a v3samlpassword 18:07:31 which feels like a bad name 18:07:41 So the question was...if we enumerate the entrypoints, and the plugin is not loadable due to package dependencies, is that OK? Or should we wait until the user tries to load the plugin and then say "sorry, dependncy unmet" 18:07:55 jamielennox: ^ 18:08:11 ayoung: we added a thing for that 18:08:22 load on-demand? 18:08:28 jamielennox, so enumerate will always work? 18:08:37 ayoung: there's an "available" property on loaders that can short circuit whether the plugin appears in the listing 18:08:40 jamielennox ayoung i believe it'll enumerate only the available ones 18:08:55 why bother to load if user never intend to use that plugin 18:09:11 ayoung: so you do like ImportError checking on your dependencies, and if they are not available then you set available false on the plugin and it will get ignored 18:09:23 gyee: there are times you enumerate every plugin on the system 18:09:28 jamielennox: nice 18:09:45 hopefully you can also avoid enumerating every plugin 18:09:46 jamielennox, why? 18:09:55 plugins should be loaded on-demand 18:09:56 ayoung: example: https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/extras/kerberos/_loading.py#L24 18:10:11 gyee: it's rare, but OSC does it for options and help building 18:10:28 jamielennox, so to test that you need a SAML provider? 18:10:38 ayoung: pretty much 18:11:04 OK so I need to update the installer we have to work with the DLRN code, which should mirror master 18:11:05 jamielennox: ayoung it'll be nice to get that refactor in early enough in the release cycle so we can fix things that may go boom 18:11:22 mirror master o_O, that's a bold move 18:11:23 stevemar, yeah, and we might need some backporting, too 18:11:37 well...I will need to backport 18:11:53 ayoung: yeah, our backport policy may not allow for that :\ 18:12:05 stevemar, hmm isn't a bug? 18:12:13 what does 'enumerate' a plugin mean ? 18:12:14 since we ship a version of KSA that syncs with what went out with Mitaka. 18:12:16 or is too huge to backport? 18:12:21 rodrigods: it's a huge refactor 18:12:25 ok 18:12:26 rodrigods, yeah, but we don't backport KSA and KC changes 18:12:42 we just tell people to upgrade to the latest 18:12:53 ayoung: sure we do, but not if they are huge refactors :) 18:12:55 I am more concerned with the Federation support for scoped tokens VIa SAML 18:13:08 that was broekn last summer, Jamie tells me it is fixed. I need to test that. 18:13:15 Anyway...I think we are good, and can move on 18:13:32 rgr 18:13:35 we support SAML to scoped token directly?! 18:13:43 gyee, nope 18:13:45 samueldmq: basically get a list of them 18:13:52 gyee, there is a provider that does this 18:13:59 uses saml to get unscoped token 18:14:09 ayoung, we need to 18:14:09 then scopes that based on what the user sets for project 18:14:19 certificate for token 18:14:22 dstanek: ah ok, so just listing all of them vs listing available ones (with what jamielennox added) 18:14:24 dstanek: thanks 18:14:24 but it was broken, expected a token to be passed in, not doing the rescoping itself 18:14:40 gyee: i think dolphm's spec allows for that, can you help with the code or reviews? 18:14:49 stevemar, sure, will do 18:14:51 https://adam.younglogic.com/2016/06/saml-federated-auth-plugin/ 18:15:06 gyee: https://review.openstack.org/#/c/324055/ 18:15:16 thank you Sir 18:15:21 gyee: you haven't reviewed it yet, i think you'll like it ;) 18:15:37 alright, next topic forreals 18:15:42 #topic Swift ACLs and keystone 18:15:53 #link http://lists.openstack.org/pipermail/openstack-dev/2016-June/096712.html 18:16:08 if anyone is familiar with swift ACLs, feel free to reply to that ML, it needs some love 18:16:29 that's all i really have to say about it, i don't know enough about the topic to reply 18:16:32 YAML instead of JSON 18:16:40 if no one else does, i can research it and reply 18:16:41 Swift ACLs are for human consumption 18:17:07 I think this is embedding JSON in the URL 18:17:27 whaaah? 18:17:41 Swift ACLs are conveyed in the headers no? 18:17:49 o/ 18:18:53 bknudson_: gyee we can chat about it in -keystone, it's not super urgent 18:18:56 so i don't understand swift ACLs, but yea the follow up message - don't use names for describing users, use ids 18:19:13 just wanted to bring it to the attention of the team 18:19:16 correct, names are deprecated 18:19:27 as they are 1) not globally unique, and 2) mutable 18:20:01 henrynash_: you ready sir? 18:20:06 yep 18:20:07 next topic time 18:20:10 #topic Project name constraints & project hierarchical naming 18:20:10 get yer tomatoes ready 18:20:22 we had a long discussion about it at Paris if I remember correctly 18:20:23 * rodrigods gets the popcorn 18:20:24 ok (ducks) 18:20:26 http://replygif.net/thumbnail/149.gif 18:20:36 so latets proposed spec is: https://review.openstack.org/#/c/318605/ 18:20:53 key summry block around line 150 in there that summarizes the compatibility 18:21:14 dolphm: I know youjust sent out some comments 18:21:33 “ The idea of asking clients to specify project names depending on both the version of the client they're using and the microversion of the server they're using does not seem tenable in the wild, especially when there are so many custom clients out there." 18:21:44 henrynash_: i appreciate the additional effort documenting the compatibility - i think it does a good job to highlight just how confusing this change will be for end users and operators :-/ 18:22:36 dolphm: so the no name would ever change underneath you, form a server microversion chnage 18:22:40 I'm not sure how nova, etc. handles microversions in their python library. 18:22:47 it feels like HMT will never end :( 18:22:59 you have to opt-in to microversions. 18:23:09 stevemar: can we just remove it? [only sort of joking] 18:23:11 so if you don't opt-in you'll never see this 18:23:12 bknudson_: they do 3 - 5 round trips to determine the version. Then they make calls based on said version 18:23:23 dolphm: but change client versions, would cause the name to now include thepath 18:23:49 3 -5 roundtrips? ouch! 18:23:54 gyee: yeah 18:24:02 this proposal represents a staggering amount of complexity with questionable, IMO, benefits 18:24:05 shaleh: does the novaclient API change based on the version the server reports? 18:24:09 gyee: they are meant to cache it, but not sure they do 18:24:27 dolphm: i am still pretty much in the camp of "don't bother" and not relax the uniqueness requirements 18:24:31 bknudson_: options become relevant as the version shifts 18:24:53 * gyee is in the same camp as dolphm and notmorgan 18:24:57 dolphm: and I guess that’s the issue…if we EVER want to change this, this is about as good (?) as it gets 18:25:07 henrynash_: the question is then, do we expect a customer using these names to also be using mixed version clients. 18:25:08 henrynash_: that might be true 18:25:15 notmorgan: stevemar: I like HMT, but it seems to me we're going so quick that other services can't follow (they're still adopting hierarchical projs) 18:25:29 henrynash_: so what's the end goal here? we're adding a complex naming spec and microversions for ... ? 18:25:38 samueldmq: it's a question of where we set the goal post 18:25:43 can we add some usecases to the spec explain why it's necessary? 18:25:46 samueldmq: not how fast we get there. 18:25:47 if a user is NOT using HMT are they affected by this? 18:25:49 notmorgan: IN SPACE 18:25:55 dstanek: that's what i was trying to get at :) 18:26:07 stevemar: get to the point! 18:26:14 so i'm still not sure this gets around the problem, if you create a project with a 3.7 client then fetch it with a 3.6 client then does the unique constraint hold? 18:26:15 dolphm: actually, i hear it's in Brazil ( olympics reference? ) 18:26:18 notmorgan: even worst if we go fast and haven't defined the goal ? :-) 18:26:20 is it going to break cinder? for example/ 18:26:32 i think henrynash_ is drumming up like 6 responses 18:26:32 stevemar: the goal is t get us out ofthe limitation befiore it’s too late! 18:26:55 shalel: and no, it won\’t affect anyone unless they are using hierchies 18:26:56 right now it says we do X and to do Y we must ... and it breaks these things, but not why Y 18:27:12 henrynash_: what benefit does removing this limitation provide to end users? 18:27:28 I still don't understand why this can't be a config swtich, and, if a user has two projects withthe same name (but different parents) that only is allowed if the feature is enabled 18:27:37 ayoung: ++ 18:27:46 ayoung: no more config switches for drastically different behaviors 18:27:46 the hierarchical naming is also only allowed if enabled 18:27:48 dolphm: it enables a common deployment pattern of having duplicate hierchies for stages of a products deployment (as desciubed in the spec) 18:27:54 ayoung: /me puts on TC/defcore-thinking hat 18:27:57 ayoung: no. 18:28:02 notmorgan, yes. Please don't tie our hands for arbitrary rules 18:28:11 ayoung: this designs for non-interoperable clouds 18:28:16 notmorgan, nope 18:28:17 ayoung: absolutely not -2. 18:28:21 not even a little 18:28:29 ayoung: yes it does, explicitly. 18:28:29 ayoung, notmorgan: agreed, we should move the whole project, it's a PITA not knowing if a server has something enabled or not 18:28:34 * ayoung proposes palace coup 18:28:42 henrynash_: i wasn't aware that we had a pattern around consuming entire hierarchies at all 18:28:49 ayoung: a cup of what? :-) 18:28:53 config management tools would have a hard time dealing with different deployment types like that 18:28:56 shaleh, tea of course 18:29:04 crinkle: ++. 18:29:06 meh...I'm going back to Java 18:29:09 dolphm: it’s how lots of internal development structures work….you just can do that in OPenSTack today 18:29:17 ayoung: you just said tea.... 18:29:20 sorry, “ can’t do that" 18:29:37 henrynash_: i can have a "staging" project and a "production" project in the same domain today 18:29:46 Programming ... make one mistake and support it for the rest of your life 18:30:08 ayoung, no, just deprecate it :-) 18:30:23 dolphm: what henry is proposing is an "accounting" project and "dev" project, each wanting a "production" and "Staging" proiject under them 18:30:35 dolphm: that is, afaict, the whole reason for this. 18:30:51 notmorgan, they are really two different domains 18:30:59 notmorgan: right, i follow. i'd name them "accounting-production" and "accounting-staging" and so on, personally 18:31:01 gyee: that has been my argument 18:31:03 which sounds totally reasonable. We just need to work out how. 18:31:05 dolphm: yep, but to be able to have a banch of the tree per preojct (so quotas can work), means you need, say /staging and /prod under muliple product branches of teh treee 18:31:06 dolphm: ++ 18:31:11 and the real issue is that we can't have "domain":"foo", "project" :"bah" where "bah" exists twice under the domain 18:31:20 or have different domains for "accounting" and "dev" 18:31:29 dolphm: +++++++++ 18:31:34 so hierarchcial naming is going to be done Database style: with underscores 18:31:51 ayoung: with dashes and hyphens, obvs 18:32:01 stevemar: ascii bell characters, duh 18:32:05 stevemar, and nonprinting non asciii unicode characters 18:32:08 dolphm, notmorgan: so we have to expose domains to teh rest of the projects so they can do quotas to cover up our restictiorns 18:32:23 henrynash_: i'm fine with other projects becoming domain aware tbh. 18:32:28 * gyee imagines how to enter the entire HMT in Chinese 18:32:34 (┛✧Д✧))┛彡┻━┻ 18:32:35 i think we're trying to walk backwards to avoid that 18:32:49 sorry that should be 18:32:56 just like we have test_backend_endpoint_policy and test_backend_endpoint_policy_sql -- use _ instead of / 18:32:59 the only thing that I have to say (as part of the team who implemented HMT) HMT was not our last goal, it was one of the first steps to provide better and bigger use cases, like nested quota, reseller. So, this point that henrynash_ is trying to explain will open the doors for this usecases... 18:33:01 domain="(┛✧Д✧))┛彡┻━┻" project="(┛✧Д✧))┛彡┻━┻" 18:33:21 raildo: ++ 18:33:25 this pretty much is solved if we change our stance and let services be domain aware 18:33:37 and we've basically been headed that way for a while anyway 18:33:40 why hide domains? What was the logic? 18:33:43 notmorgan: we have a fundamental restrciotn based on a pre-domain model… 18:33:46 shaleh: simplicity 18:33:47 they are stupid shaleh 18:33:52 domains are projects 18:33:59 just we decide to call them something else 18:34:05 how is it possible to do hierarchical quota without other projects knowing about the hierarchy? 18:34:06 ayoung: oups. 18:34:09 and force a two level hierachy 18:34:14 unless it's keystone doing the quotas. 18:34:17 ayoung: talking to other service teams they still say "tenant" 18:34:18 headachy 18:34:19 ayoung: predates me :( 18:34:28 notmorgan, does not predate gyee 18:34:29 if it walk like a duck, quack like a duck, then it must be a duck 18:34:32 ayoung: i'd argue they should have all been realms. :P 18:34:41 gyee, it is not a flipping duck! 18:34:43 * notmorgan stops snarking 18:34:45 bknudson_: in the current solution, the service calls keystone API to the get the hierarchy 18:34:46 bknudson_: services do an additional call to keystone to know the hierarchy of the project in question 18:34:49 and it is certainly not a domain according to DNS 18:34:55 i would also prefer not to expose domains to services - they shouldn't care 18:34:56 bknudson_: you're assuming that no one puts underscores in their project names already? 18:34:58 which is what really messes with the naming 18:35:18 are we getting to working points/decisions here ? 18:35:27 samueldmq: nope :( 18:35:27 (I don’t think so) 18:35:28 but if we could get back to the topic? 18:35:45 jamielennox: what is the reason behind that? i mean, nova being able to let a domain admin act upon all the vms in it's subprojects with one token? 18:35:46 jamielennox: ++ 18:35:50 jamielennox: is that not a valid usecase? 18:35:56 henrynash_: i think it's on you to better convince us that all this work is going to result in a huge benefit 18:36:04 jamielennox: and similarly, domain X,Y,Z all share a pool of quota? 18:36:08 ϵ( ‘Θ’ )϶ 18:36:18 cause ATM, dolphm has a similar problem and fixes it in a different way 18:36:33 stevemar: dolphm has a simpler, similar problem 18:36:50 it'd be simpler to enumerate the projects a token can act on in a "multi-project scoped token" (that way, other services don't have to care how keystone generated the list, nor do they have to store the project hierarchy" 18:36:51 ) 18:36:52 ayoung: you have the better emoticons 18:36:52 closest I could come to a duck gyee 18:36:53 and, what exactly are the alternatives -- services becoming domain aware, etc 18:36:55 notmorgan: we've pushed all this way with HMT for that, i'd prefer to not leave it half done 18:37:10 shaleh: I don’t see it as simpler….I see it as a bandaid 18:37:22 henrynash_: agreed 18:37:26 jamielennox: i think domains are fundamentally still something services should be able / willing to act on 18:37:31 jamielennox: right, i totally agree 18:37:31 dolphm, bring back service-scoped tokens! 18:37:38 dolphm: like adding the subprojects in the token ? 18:37:53 gyee, a service shoulkd be a project 18:38:01 dolphm: did you just say v4 /slap 18:38:10 notmorgan: and right now with users being tied to domains, making multipel domain system work as one will likely be also complex 18:38:13 gyee: it never went away! https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens 18:38:21 ++ 18:38:26 jamielennox: i hope not 18:38:41 ayoung, I am not disagreeing 18:38:42 so...lets get to what we want to have...even if it is impossible 18:38:51 ayoung: ++ 18:38:52 a scope should be specified like this 18:38:53 jamielennox: the tricky part is not the keystone API in my mind, it's the auth context interface between auth_token and underlying services 18:38:59 domainname/p1/p2/p3 18:39:00 notmorgan: henrynash_ representing domains as proejcts should help other services adopting domains 18:39:25 dolphm: interesting you should say that - next topic 18:39:35 that should fully specify the project. 18:39:54 i think we all need to review the spec henrynash_ has authored (https://review.openstack.org/#/c/318605/12) only raildo and dolphm have commented on the most recent rev 18:39:54 we have no human friendly way of specifying a proejct deep in a hierarchy 18:40:00 samueldmq: yes, although we know have to do things like…..replicate my ldap domain configurations for one enterise becaue they want to add a new project tree 18:40:15 stevemar: ++ 18:40:23 (because teh domain has the ldap config) 18:40:32 stevemar: i have a minor thing to toss on the end. will be a last-minute spec possibly 18:40:41 stevemar: if we have time. 18:40:44 notmorgan: -2 in advance 18:40:45 :P 18:40:51 I’ll need cloud admin rights to do that hat od thing 18:40:57 notmorgan, so you will -2 anything that lest us fully specify a project that way? 18:40:58 henrynash_: ++, ldap providers should have been given an idp_id you could share 18:41:21 ayoung: i am going to -2 a proposal to make this a config switch. 18:41:36 ayoung: i've not -2'd the current proposals except where they break api contract 18:41:41 notmorgan, OK...so it has to be something enabled by default, and backwards compatible 18:41:56 ayoung: that's usually what we hope for :) 18:41:57 how's that possible? 18:42:05 ayoung: yep. after that, I'm going to as the UX question - but that is a -1 from me at most 18:42:08 if it sucks. 18:42:20 there were several other options we floated. Some of the them suck, but maybe suck less 18:42:34 looking at the JSON, we can specify a project name as an array 18:42:37 ayoung: but the -2 is very much incompat changes here *or* design for different experiences per cloud. 18:42:47 dolphm, notmorgan: if we are going to use domains for this, then we will absolutely need nested domains 18:42:48 that was unfriendly from an env var 18:42:56 (which I know you love) 18:42:59 but I actually think it is nicer from a JSON perspective 18:43:09 henrynash_: and we then we run into this exact same argument with nested domains. 18:43:13 project_name=['dom','p1','p2',p3'] 18:43:28 don't we already support nested domains? 18:43:31 ayoung: that doesn't break API compat? 18:43:32 option #23578: make project names non-uqique, and 401 if people try to auth by name but the specified name is ambiguous. force auth by project id 18:43:34 gyee: ha! 18:43:35 stevemar, nope 18:43:37 gyee: nope 18:43:37 henrynash_: so, put this to rest first before we open that convo - because my answer is going to be the same with domains... except they still need to be globally unique 18:43:46 stevemar, it is "in addition to" 18:44:01 dolphm: backwards incompat? 18:44:05 the question stevemar is what happens when we have 2 'p2' projects under a domain 18:44:14 I thought we agreed on nested domains? 18:44:16 notmorgan: only if you start using conflicting project names? 18:44:17 dolphm: problem is ambiguous can happen after the fact, so it worked until someone else added a projec with the same name 18:44:25 jamielennox: right, that's my point 18:44:36 project_name=['dom','p1','p2',p3'] versus project_name=['dom','p99','p2',p3'] 18:44:41 dolphm: that kindof just breaks our whole api contract ... 18:44:42 jamielennox: allow users to opt into this poor UX 18:44:45 gyee: nested domains in addition to nested projects? 18:44:47 i don't think we're going to figure this out in the next 15 minutes, please comment on the spec instead 18:44:59 until we had that, users could still do project_name='p2' domain_name='dom' 18:45:01 stevemar: Ok, let’s clsoe this c topic for now 18:45:02 stevemar: ++ let's move on 18:45:04 dstanek, right 18:45:08 \o/ 18:45:17 round and round we go 18:45:22 dolphm: that's not users, that's deployers, and we would always be surprising users with something that's very new 18:45:23 no not one yet 18:45:24 henrynash_: anything else you're looking for here before i switch? 18:45:25 faster, faster! 18:45:31 one last thing 18:45:36 let's continue on the spec 18:45:37 :) 18:45:40 stevemar: nope, that was …err.. fun 18:45:42 it can be a property of the domain, not of the overal server, whether to allow this 18:45:50 and it should be 18:45:55 ayoung: no 18:45:57 it should be disabled by default 18:45:58 ayoung: no. 18:46:00 dolphm, yes 18:46:02 notmorgan, yes 18:46:07 dolphm: was that 'faster, faster!' for me? :) 18:46:08 ayoung: same argument as before. NO. 18:46:13 notmorgan, no it is not 18:46:14 stevemar: for dstanek 18:46:33 1. on the domain is discoverable 18:46:39 it changes nothing by default 18:46:51 and once it is set, it does not break other domains 18:46:55 people don't do that discoverability - they never have 18:46:56 big difference is the last 18:47:00 jamielennox, does not matter 18:47:08 ayoung: and it can never ever ever ever be set after a domain is created 18:47:10 ayoung: ever 18:47:16 matters hugely, it's also another request i need to make on every auth 18:47:18 notmorgan, why not? 18:47:21 ayoung: unless it has no children 18:47:29 ayoung: you just broke working auth. 18:47:49 notmorgan, it cannot be "unset" once there is a conflict 18:47:54 13 mins left 18:47:57 jamielennox: how much time do you need ? 18:48:02 ayoung: it should immutable.. anyway move on 18:48:04 I'll step down 18:48:08 i don't think this is going anywhere here. 18:48:11 stevemar: it's mostly a please go look 18:48:14 * ayoung returns the conch 18:48:22 stevemar: 5 min 18:48:25 * stevemar takes the conch 18:48:28 #topic Reservations Spec 18:48:36 * stevemar hands the speaking stick to jamielennox 18:49:02 reservations are the approach we should have taken for ever 18:49:09 notmorgan will, of course, hate them 18:49:09 ok, so the service user permissions spec i was pointing everyone to a few weeks ago got poo-pooed by the mailing list and security groups 18:49:18 nope, i really like this spec 18:49:20 the new version is tentatively called reservations 18:49:25 notmorgan, AWESOME! 18:49:30 #link https://review.openstack.org/#/c/330329/ 18:49:37 notmorgan, I was really afraid we would be at loggerheads over this...cool 18:49:37 i like the ephemeral nature of the passed on info 18:49:39 isn't trust reservations? 18:49:41 sorta 18:49:45 not to toot my own horn - but i really like this and what it can open up in future 18:49:48 gyee, really similar 18:49:49 i like that it happens behind the scenes 18:49:59 reservations have a limited lifetime? 18:50:07 and i like that it opens us to validate the user's authz at the edge and possibly offload down the line. 18:50:17 gyee, so, a trust is recorded. A reservation is like an ephemeral trust based on a "fill in the blanks" template 18:50:20 it is most everything [with better details] I've wanted for a while 18:50:21 bknudson_: reservations are only for the lifetime of a single user request 18:50:33 "I, state your name, do grant to party of the first part..." 18:50:39 it immediately solves the token expiration problem 18:50:42 jamielennox: you'll need [impl. detail] define what that "lifespan" enforcement is 18:50:43 how to enforce that? nova might save the reservation to the database. 18:50:46 ayoung, oh, like a school permission slip 18:50:51 and long term can solve dynamic and centralized policy 18:50:57 school field trip permission slip 18:50:59 Can we brainstorm a better name? 18:51:00 dolphm: and possibly multi-project tokens 18:51:07 jamielennox: but that is something i'm willing to punt on as this is wayyyyy better than today. 18:51:18 jamielennox, so...where did the name "reservation" come from? What was the inspriation 18:51:29 notmorgan: yea, there are going to be a lot of details to figure out 18:51:46 jamielennox: i also like that this is another opaque blob we deconstruct 18:52:03 jamielennox: so people can't reach in and "figure things out" and make the data in the blob a contract. 18:52:05 ayoung: i did a bit of a pondering section - basically if i was starting from scratch i would combine authn/authz/quota etc into a pre-check, and basically what you have there is a reservation of resources 18:52:09 * ayoung just realized this will play really nicelt with caching 18:52:10 we can encode what we need in it.. and change as needed 18:52:19 ayoung: it applies less without quota - but i have no better names 18:52:27 jamielennox: anyway i'm a fan of this spec. 18:52:44 jamielennox: i need to read the spec, but in general i like it 18:52:46 jamielennox: how do you enforce that reservations can't be replayed? 18:52:51 told you guys, if we have PKI token, we won't need this reservation business 18:53:02 dstanek: i think that is future looking. 18:53:02 dstanek, it can be replayed 18:53:09 gyee: those are deprecated :) 18:53:13 so my goal is to get people reviewing because there's a lot of follow on that i want to make sure we get right and not have like a HMT naming issue 18:53:15 dstanek: it is still a bearer token, but it's just internal only 18:53:16 why is it better than a token then? 18:53:20 (sorry henrynash_) 18:53:24 the idea is that the scope of the reservation is longer lived than the users origianl token 18:53:30 dstanek: the token expires 18:53:34 can we call these...resource-tokens? 18:53:36 or is invalidated by the user 18:53:41 dstanek: so it will still expire, but it's only created by the service 18:53:45 > Keystone then issues a reservation to the service. The reservation contains the majority of data present in the token however is only valid for a specific operation. 18:53:46 dstanek: it's not passing the user's authz around, no expirations. it's service to service communication isolation 18:53:49 > A reservation is entirely a service side concept and will never be exposed to users. 18:53:50 users will never see this 18:54:04 I don't get it. Will it be a REST API call? 18:54:06 so it's a token with no definitive expiration 18:54:21 dstanek: tbd on how that happens. 18:54:23 dstanek: no, it's an authorization for one operation with an expiry 18:54:27 and it's still a bearer token? 18:54:32 oh 18:54:38 auth-token middleware gets the reservation when it gets a token? 18:54:44 it's not a token that can be reused for arbitrary things 18:54:59 so what happens if its compromised? 18:55:00 looks like we all have reading and a chat about it next week 18:55:04 bknudson_: auth_token exchanges user token for a reservation to confirm they can perform the operation 18:55:08 shaleh: ++ 18:55:22 how do we enforce that only a service can use it? 18:55:33 dstanek: policy, is the best we can do. 18:55:35 yep - but please ask questions cause it makes sense in my mind, but i'm not particularly good at getting this stuff out 18:55:36 jamielennox: thanks for getting the ball rolling on this 18:55:42 dstanek: service only operations 18:55:47 auth_token could check the roles on the service token 18:55:48 notmorgan: so only a service user can use it? 18:55:54 dstanek: that is the idea 18:56:00 is it signed by the service client? 18:56:04 dstanek: yep - completely transparent to users 18:56:09 dstanek: and only a service user shyould be able to validate it. 18:56:18 dstanek: it's not "auth" token validation. 18:56:22 lbragstad: i put signed as an option - more likely it'd be fernet style and validated by keystone 18:56:26 dstanek: it'd be something different. 18:56:29 and what about lbragstad's question? 18:56:35 does auth_token have to go to keystone to validate the reservation or can it validate locally? 18:56:59 bknudson_: worth asking, if you don't mind distributing keys, auth_token could validate it. 18:57:03 bknudson_: same thing, if we think we can do it via signing it's worth a try but i'm gunshy on that 18:57:03 that would require a distributed fernet repository if we build it on fernet, right? 18:57:11 #implementationdetailsarefun 18:57:15 this seems similar to what i've been saying about scoping a token to a particular operation 18:57:16 lbragstad: no, same as today, keystone would validate 18:57:18 lbragstad: yeah it's impl details. 18:57:21 do we want to invalidate a reservation if the user is disabled? 18:57:28 jamielennox: shouldn't we be going toward removing service users instead of reinforcing them 18:57:31 why do we need user tokens then? 18:57:38 bknudson_: i'd say no. not middle of the operation 18:57:43 just to pass it from keystone to keystonemiddleware? 18:57:47 breton_: user -> service communication 18:57:49 bknudson_ would we expect a service to keep doing something for a user if that user was disabled? 18:58:02 stevemar: we will always need the concept of an operation being performed internally vs externally - whether we do PKI or service users of whatever there i don't care 18:58:17 lbragstad: if the user requested an action, aka boot a vm, i'd expect that to continue if the user was disabled 18:58:19 getting a large image from glance can take a long time, so user might be compromised in that time. 18:58:21 PKI is just a service user with another name 18:58:44 (2 minute warning) 18:58:45 bknudson_: no, reservations are fairly short lived (one user operation) so they will disolve when the op is finished 18:58:46 no, PKI is a way to validate the data independently 18:58:59 jamielennox: you assume that user operations are short. they are not always. 18:59:03 is this effectively similar to a service ignoring the expiration on a token if it's used by a service user? 18:59:09 stevemar: 1 minute left 18:59:28 oh no, morgan had something 18:59:30 maybe the server that got the request could invalidate the reservation when it sees the operation is complete. 18:59:31 bknudson_: i'm aware but i can only be used for that operation however long it is 18:59:32 we're out of time 18:59:41 go comment on jamie's spec :) 18:59:46 dstanek: no, we validate expiry once - at the time of the initial request 18:59:49 really quick then. 18:59:56 notmorgan: chat in -keystone? 18:59:58 jamielennox: that's what i mean 19:00:04 i'm going to propose a way to remove paste.ini 19:00:13 notmorgan: sounds diabolical 19:00:15 out of time :( 19:00:16 but not lose the functionality 19:00:22 #endmeeting