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