18:02:52 <jamielennox> #startmeeting keystone
18:02:53 <openstack> Meeting started Tue May 31 18:02:52 2016 UTC and is due to finish in 60 minutes.  The chair is jamielennox. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:57 <openstack> The meeting name has been set to 'keystone'
18:03:07 <lhcheng> o/
18:03:15 <jamielennox> hey everybody
18:03:33 <jamielennox> quick reminder as with last week that the spec proposal freeze is this week
18:03:51 <rodrigods> hi jamesmcarthur
18:03:52 <rderose_> o/
18:03:53 <rodrigods> oops
18:03:53 <dolphm> ooh, damn, i have one to get up
18:03:57 <rodrigods> jamielennox,
18:04:03 <jamielennox> hopefully there is nothing still outstanding that wants to get up this cycle
18:04:10 <jamielennox> :)
18:04:36 <amakarov> week of new ideas: the new ideas growth is doubled this week :)
18:04:48 <jamielennox> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:05:05 <jamielennox> #topic Multiple datacenters
18:05:16 <jamielennox> agrebennikov, amakarov: all yours
18:05:21 <nonameentername> o/
18:05:33 <agrebennikov> jamielennox, I guess we discussed it last week after meeting
18:05:37 <dstanek> o/
18:05:37 <amakarov> I've created a spec for ayoung patch (see etherpad ^)
18:05:40 <nk2527> o/
18:05:56 <agrebennikov> and ayoung's comment was "create a spec if you need it "
18:06:04 <agrebennikov> amakarov, I believe it is there
18:06:23 <ayoung> does anyone really have a problem with a cloud admin being able to create a project with a specificID?
18:06:23 <amakarov> agrebennikov: https://review.openstack.org/323499
18:06:46 <ayoung> ACKing that we would need a microversion anyway?
18:06:49 <notmorgan> ayoung: no, not as a break-glass scenario as long as it conforms (uuid)
18:06:57 <amakarov> ayoung: I believe there were no complains in API v2
18:07:02 <henrynash> ayoung: microversion spec approved!
18:07:09 <gyee> done done
18:07:11 <jamielennox> ayoung: the only case i'm comfortable with is the restore a project so you can deleete its resources
18:07:12 <agrebennikov> heyhey!
18:07:20 <ayoung> henrynash, we were pretty close to microversion compliant thus far anyway
18:07:30 <ayoung> jamielennox, what about syncing two sites?
18:07:32 <jamielennox> personally i think that's a keystone-manage command but ok
18:07:34 <notmorgan> jamielennox: that would be the use-case imo. but you kindof open the door to lots of things.
18:07:49 <shaleh> vanity IDs for one
18:07:54 <jamielennox> ayoung: nope, there's a bunch of ways to do syncing that we shouldn't touch
18:07:58 <jamielennox> shaleh: nope
18:07:59 <notmorgan> jamielennox: and i am *ok* with the ability being added, not specific to where/how it makes it into the db.
18:08:01 <gyee> in that case, why stop at project, why not ALL IDs?
18:08:09 <shaleh> jamielennox: not saying I support them :-)
18:08:31 <notmorgan> gyee: honestly, i think this is a case of backing away from the remove the row on delete
18:08:33 <amakarov> so what are the objection?
18:08:33 <ayoung> are we limiting it to projects ?
18:08:38 <notmorgan> in general
18:08:47 <jamielennox> gyee: exactly, currently projects is all that is required because they can LDAP backend the rest - but that's just the current pain point
18:08:49 <amakarov> ayoung: this is the current need
18:08:55 <notmorgan> gyee: but....
18:08:57 <ayoung> not users, .... roles  ... meh the ids for roles should be the role names
18:09:00 <notmorgan> ok hold on
18:09:00 <ayoung> uuids are dumb there
18:09:06 <gyee> jamielennox, I worry about consistency
18:09:11 <gyee> special cases = magic
18:09:14 <notmorgan> "restore" is off the table as part of this discussion right now
18:09:15 <jamielennox> not sure why you can't LDAP backend the projects but whatever
18:09:32 <notmorgan> this is the API need amakarov is asking for
18:09:40 <ayoung> jamielennox, we killed that off
18:09:49 <amakarov> ayoung: ++
18:09:50 <notmorgan> to have consistent ids across different deployments in keystone
18:09:51 <notmorgan> so.
18:09:52 <henrynash> so let’s review the conceptual objection to this….since we now know of multiple requirements (which various of us may or may not think important)
18:09:58 <notmorgan> on that topic
18:10:02 <notmorgan> what is the feeling?
18:10:22 <notmorgan> this is clearly an API change.
18:10:24 <ayoung> what is the risk?
18:10:25 <gyee> I don't have a problem with it, I understand the objective, but the argument seem pretty weak
18:10:28 <henrynash> I think the conceptual objection was to avoid collisions across clouds?
18:10:43 <notmorgan> henrynash: no.
18:10:47 <ayoung> I go to a remote system, create a project with a deliberate UUID, and the thing already exists...
18:11:01 <ayoung> that was probably deliberately done
18:11:08 <notmorgan> henrynash: to have the same resources (projects, by id) in multiple deplyments
18:11:11 <ayoung> cuz...uuid clash... not too likely
18:11:20 <notmorgan> if a uuid collides
18:11:26 <jamielennox> notmorgan: more i don't like the precendent of having different subsets of data present in different keystones
18:11:28 <lbragstad> this allows for more than just making sure the same id exists in a single keystone - for that case wouldn't you just share the resource backend?
18:11:32 <notmorgan> i'll buy the next round of drinks for the entire keystone team at the summit
18:11:40 <gyee> if DB replication is not an options because 1) too expensive, 2) unreliable, and 3) error prone
18:11:44 <notmorgan> the whole team. (everyone here)
18:11:45 <gyee> then lets say it in the spec
18:11:54 <ayoung> notmorgan, like I said,  its probably deliberate
18:11:55 <rodrigods> you could be bolder notmorgan
18:11:57 <jamielennox> assuming that because you can create a project in another keystone that you can just use that keystone as if it was the original
18:11:58 <dstanek> jamielennox: ++ that worries me
18:11:59 <jamielennox> it's not
18:12:04 <rodrigods> everyone in -meeting maybe
18:12:11 <henrynash> notmorgan: that’s the specific requirement here….weve discused this on many occasions, but always felt uncomfortabtle…just trying to (re)flush out the ojections
18:12:11 <notmorgan> rodrigods: sure.
18:12:12 <jamielennox> it doesn't have the roles or any other information
18:12:17 <ayoung> but that could be done today with V2
18:12:20 <jamielennox> domains will suffer the same proble
18:12:42 <jamielennox> and it can be done today with either a custom backend or a working database sync
18:12:55 <ayoung> jamielennox, I feel that your new role is the "I say no to things" person.
18:13:10 <notmorgan> ayoung: someone has to do it
18:13:12 <jamielennox> but i don't want keystone to figure out how to provide keystone sync-ing via PAI
18:13:21 <jamielennox> API
18:13:47 <jamielennox> because i'm still not sure why project is special from other things that would need to be transfered to effective duplicate a keystone deployment
18:13:59 <gyee> jamielennox, ++
18:14:02 <ayoung> jamielennox, why not.  We really don't provide people with sufficient tools for K2K yet
18:14:06 <notmorgan> so specifically on this topic, there has been a lot of asking for this feature. because when a cloud has a new deployment they want to have the customer in the same project. and they don't sync keystones.
18:14:22 <notmorgan> i don't know if this is a usecase we need to solve?
18:14:34 <lbragstad> didn't we have an action item from the last meeting to see what about our federation implementation was preventing this?
18:14:48 <agrebennikov> jamielennox, because users are the same in the backend, and roles are pretty static
18:15:17 <notmorgan> jamielennox: and roles are referenced by name, not id, outside of keystone.
18:15:20 <jamielennox> agrebennikov: "same backend"? why not put projects in this same backend that works?
18:15:23 <gyee> lbragstad, right
18:15:41 <agrebennikov> jamielennox, I'd love to have them in ldap!
18:15:47 <lbragstad> gyee do you know if/where that list of short-comings is?
18:16:00 <jamielennox> notmorgan: i don't understand your use case
18:16:01 <ayoung> With K2K, we need some form of sync.  And we need to map from local to remote.  THat could be done by naming, or could be done by ID
18:16:01 <gyee> lbragstad, no, I was hoping to see them in the spec
18:16:03 <dstanek> agrebennikov: you can't assume that users are in LDAP
18:16:20 <ayoung> dstanek, why not?
18:16:30 <dstanek> so jamielennox's question is valid...how is project different from other data
18:16:42 <ayoung> projects in LDAP was based on an assumption that is no longer valid
18:16:43 <jamielennox> agrebennikov: so do it :) we may not provide the backend upstream but there's nothing stopping you from doing what works for your case
18:16:47 <dstanek> ayoung: like it or not we still support other backends
18:16:56 <ayoung> if we do resources in LDAP, we need to redesign, and I would not recommend that
18:16:57 <notmorgan> jamielennox: i'm just echoing what i've been asked for.
18:17:02 <ayoung> dstanek, that is not the same thing
18:17:09 <agrebennikov> dstanek, right, if they are not the rest of the stuff doesn't make any sense, since it will not be "clouds in sync" usecase
18:17:24 <ayoung> LDAP  users and groups  should not be tied to assignments in the LDAP backend
18:17:42 <jamielennox> notmorgan: i mean i'm not understanding what's being asked for, 'customer in the same project' why does this involve preset uuids?
18:18:03 <notmorgan> jamielennox: oh hold on. customer HAVING the same uuid (project) for ease of access
18:18:18 <ayoung> we go out of our way to be hostile to users...UUIDs are not pleasant things to work with
18:18:30 <ayoung> remember the whole Killer for dynamic policy?
18:18:37 <notmorgan> ok so.
18:18:43 <ayoung> "Don't make use add an endpoint, get the uuid, and stick that in the config fil"
18:19:08 <notmorgan> i think this feature is asking for something that opens weird edge cases and doesn't solve them.
18:19:23 <ayoung> notmorgan, that was already open
18:19:25 <notmorgan> basically there is nothing to prevent name collisions in domains if both are active.
18:19:34 <notmorgan> for domains*
18:19:40 <notmorgan> you have the same issues with domains.
18:19:43 <henrynash> ayoung: so although I wasn’t thinking about this use case, the spec I’m working on might help here: https://review.openstack.org/#/c/318605/4
18:19:45 <notmorgan> you have the same issues with user_ids.
18:20:00 <ayoung> henrynash, yep
18:20:10 <ayoung> notmorgan, I have the same issues with everything!
18:20:29 <notmorgan> i really don't think we can reliably say this is a good plan - creating specific ID'd resources across multiple installations that don't share the authoritative data backend
18:20:55 <henrynash> ayoung: this would certainy allow project scopig without eitehr domain ID or project ID
18:21:21 <notmorgan> you need far more syncronization than just project ids... to the level of "not something keystone should figure specifically" imo
18:21:29 <lbragstad> notmorgan that sounds like federation
18:21:35 <ayoung> notmorgan, you also need role assignments, etc
18:21:41 <dolphm> i think the spec i want to post for newton will actually address this rather elegantly -- what's the spec proposal deadline exactly, end of week?
18:21:44 <ayoung> you can do it with out IDs.  Just not via K2K
18:21:54 <ayoung> dolphm, yep
18:21:58 <notmorgan> lbragstad: federation would be the logical goal to solve this imo.
18:21:59 <henrynash> so to pick up on ayoungs: point, what if you didn’t need to use projectIDs to auth…would that solve this use case?
18:22:00 <jamielennox> dolphm: yes
18:22:00 <ayoung> dolphm, what's the gist of it?
18:22:23 <ayoung> notmorgan, then we need to seriously look at cleaning up the mapping mechanism
18:22:25 <agrebennikov> notmorgan, but is is allowed for users (since they may be inthe same backend), and All others Must be different. Or federation. No other options
18:22:28 <dolphm> ayoung: leverage shadow users and make the mapping engine way more powerful
18:22:31 <amakarov> lbragstad: there is a place on Earth where peaple are killing eachother for that word
18:22:48 <amakarov> people*
18:22:50 <jamielennox> notmorgan, lbragstad: federation is a difficult thing to set up here because you would need to map every project to every other project - and then assume things like horizon can make the jump
18:23:02 <jamielennox> it's not a transparent operation
18:23:23 <dstanek> that's what i think we are missing. that sort of project mapping.
18:23:25 <dolphm> ayoung: user presents keystone with a saml doc, keystone creates a shadow user, maybe creates a project, maybe even creates a role, then does a role assignment... all according to the mapping engine output
18:23:39 <gyee> we support project mapping today
18:23:42 <notmorgan> dolphm: that sound sreasonable
18:23:54 <notmorgan> at face value (i'd need to see more obviously)
18:23:54 <dstanek> i think talking about this as a sync is going down the wrong path
18:23:59 <amakarov> jamielennox: the strait-forward way is to allow usage of wildcards and aliases in mappings
18:24:04 <ayoung> dolphm, so..in order to makethat manageable, we need to limit "this is what you canmap TO"
18:24:05 <lbragstad> dolphm so building on our current mapping engine
18:24:08 <amakarov> I'm not sure we want that )
18:24:16 <ayoung> and make it so IdP admins can manage their own mapping files
18:24:18 <dolphm> lbragstad: ++
18:24:27 <notmorgan> ok so, going to call time box on this in 5 minutes.
18:24:30 <jamielennox> amakarov: yea, ew could improve the mapper to handle something like that properly i just don't think it will today
18:24:36 <henrynash> ayoung: we need that anyway, imho
18:24:41 <dolphm> ayoung: i'd like to see a stronger constraints around domains to manage that
18:24:41 <ayoung> henrynash, ++
18:24:58 <ayoung> idp to domain associations
18:25:04 <henrynash> ayoung: actually, i’ll raise a spec for that anyway
18:25:13 <dolphm> ayoung: basically yes. so a domain admin is also free to manage a mapping
18:25:14 <ayoung> this idp can map to domain X,y,z butn not p,d,or q
18:25:20 <agrebennikov> folks, don't you think federation setup will dramatically slow down the process of authorization in production?
18:25:22 <notmorgan> generally speaking, as an API, I am against user-provided IDs.
18:25:40 <amakarov> agrebennikov: ++
18:25:49 <ayoung> agrebennikov, nope
18:25:52 <notmorgan> ayoung, dolphm, henrynash: lets see what the federation spec looks like before we dive too far into it, but it sounds like an option
18:25:55 <dolphm> notmorgan: you don't love race conditions?
18:26:00 <dstanek> amakarov: are you alredy solving your usecase and just looking to upstream the idea? or have you not started to do it yet?
18:26:06 <notmorgan> dolphm: hehe
18:26:08 <ayoung> agrebennikov, look at the Federation via SSSD and Mod_lookup_+identity setup I did a few years ago
18:26:17 <ayoung> no slower than LDAP, and much cleaner
18:26:25 <ayoung> https://adam.younglogic.com/2014/05/keystone-federation-via-mod_lookup_identity/
18:26:33 <dolphm> amakarov: your use case on the mailing list is exactly what i have in mind
18:26:33 <dstanek> agrebennikov: it shouldn't
18:26:39 <amakarov> dstanek: I'm sticking to upstream wherever possible
18:26:58 <agrebennikov> ayoung, I mean if every time user tries to authorize in one cloud it has to call to remote keystone
18:27:07 <dolphm> s/wherever possible//
18:27:10 <dstanek> amakarov: ok, was just going to see about any experiments you've done
18:27:19 <amakarov> dolphm: thanks )
18:27:24 <dstanek> agrebennikov: not authorize, just authenticate
18:27:25 <jamielennox> ayoung: explain to me from before why you think you couldn't implent a custom LDAP resource backend?
18:27:40 <agrebennikov> dstanek, we are talking about projects, rigth?
18:27:46 <ayoung> jamielennox, OK, so when I first did LDAP Identity and Assignment were in a single backend
18:27:49 <notmorgan> amakarov: fwiw, this really sounds like db replication is the solution (or LDAP backend, or anything with replication)
18:27:54 <dstanek> agrebennikov: once you have a token for the cloud you want to operate on you won't talk to the other keystone
18:28:08 <ayoung> today, there would be no clean way to pull in users from federation etc via LDAP
18:28:23 <ayoung> I mean, you could put it in LDAP, but it would be Keystone only data
18:28:32 <agrebennikov> dstanek, but when you bring it to local keystone, does it have to verify the token against the remote one?
18:28:34 <ayoung> and not have the role assignments, as those really should be in SQL
18:28:36 <jamielennox> notmorgan: ++ to db replication, this stemmed from having problems doing reliable sync but i think something behind the scenes is still correct here
18:28:37 <amakarov> notmorgan: and db replication souns like an overkill :)
18:28:56 <dolphm> ayoung: the problem is that you want to manage user-specific authorization before there are users, right?
18:29:00 <ayoung> amakarov, you can never have too much overkill
18:29:04 <notmorgan> amakarov: it provides consistency and a shared authoritative data store
18:29:35 <jamielennox> ayoung: but for whatever reason they are not having to duplicate the assignments backend, just resources, so you could put that in LDAP ?
18:29:40 <agrebennikov> notmorgan, why do you always try to enforce third-party service to do the job which may be avoided? :)
18:29:42 <notmorgan> amakarov: allowing user-provided ids only solves a very small case and i am almost 100% sure you're going to need a lot more.
18:29:56 <ayoung> jamielennox, they would be aback asking for assignments once they realized....
18:30:05 <ayoung> you need the whole kit and kaboodle
18:30:07 <notmorgan> agrebennikov: because the NIH in openstack is strong.
18:30:11 <jamielennox> ayoung: i'm pretty sure that's going to happen here anyway
18:30:14 <ayoung> and it should not be in LDAP
18:30:23 <ayoung> jamielennox, so...I like dolphm 's approach
18:30:29 <agrebennikov> ayoung, please, bring it back to ldap))
18:30:30 <ayoung> or SQL sync
18:30:36 <ayoung> agrebennikov, Nope.
18:30:42 <ayoung> agrebennikov, not the right tool
18:30:55 <ayoung> LDAP is general purpose data, not app specific
18:31:17 <jamielennox> dolphm's approach being allow the mapper to create projects on first access?
18:31:24 <ayoung> why is ldap replication any better than SQL replication?
18:31:25 <dolphm> jamielennox: ++
18:31:44 <gyee> ayoung, because LDAP data is "highly static"
18:31:45 <ayoung> jamielennox, it also solves the long standing "autoprovisioning" feature request
18:31:47 <notmorgan> ok we have other topics to cover
18:31:47 <jamielennox> dolphm: i like that - but it still wouldn't let you specify a static project id output right?
18:31:53 <notmorgan> we should close up this one.
18:31:54 <dolphm> jamielennox: first authN, or on an authN when the mapping produces a new result (new attribute in SAML, or new mapping rules)
18:32:05 <dstanek> dolphm: would your approach deal with the project id issue so that users only have to know one?
18:32:09 <notmorgan> we can circle back at the end.
18:32:09 <dolphm> notmorgan: ++ let me get this into a spec, and we can resume next week
18:32:14 <jamielennox> yea, ok, allow for evolution of mapping
18:32:14 <dolphm> dstanek: yes, it could
18:32:16 <amakarov> notmorgan: what's the conclusion?
18:32:27 <notmorgan> so, in wrapping up
18:32:31 <notmorgan> lets see what dolphm proposes
18:32:36 <dolphm> amakarov: conclusion is i owe you a spec :P
18:33:12 <notmorgan> i personally am against supporting this in the API, what do the other folks feel (temperature) wise on the user supplied ids?
18:33:23 * amakarov writing down in a very special notebook "claim a spec from dolphm"
18:33:32 <notmorgan> #action dolphm to write up federation spec for next week.
18:33:38 <jamielennox> i'm still -1 on the whole idea, i feel like you need only projects because of a very specific deployment setup
18:33:49 <jamielennox> to do this properly would require access to a whole lot more
18:34:19 <jamielennox> and i think the answer should be db replication, because you are actually trying to horizontally scale keystone
18:34:19 <notmorgan> ayoung, henrynash, dstanek, shaleh, rodrigods, samueldmq ?
18:34:25 <notmorgan> lbragstad?
18:34:35 <agrebennikov> yeah, give me my custom project IDs! :P
18:34:48 <lbragstad> i'm not a huge fan of user defined IDs because it can cause weird edge cases
18:34:51 <ayoung> notmorgan, meh
18:34:57 <rodrigods> lbragstad, ++
18:35:04 <dstanek> generally i'm -1 on this idea. it seems like it would open too many corner cases
18:35:05 <amakarov> last time it was OK as an admin-only action, no
18:35:06 <ayoung> notmorgan, I want them for other reasons, see no reason to feat them
18:35:07 <henrynash> i remain skeptical of user defined IDs as well
18:35:07 <amakarov> ?
18:35:07 <dolphm> what is the reasoning behind avoiding DB replication? what's described on the agenda just sounds like a technical exercise rather than a use case
18:35:09 <ayoung> fear
18:35:10 <agrebennikov> you man check they are unique
18:35:26 <henrynash> dolphm: ++
18:35:29 <notmorgan> dolphm:  ok lets get an answer to that then close up the topic
18:35:33 <lbragstad> but if we can do it with something like the mapping engine and solve the auto-provisioning case that would be cool
18:35:37 <notmorgan> agrebennikov, amakarov^
18:36:12 <shaleh> notmorgan: via the API, not so keen. As say a keystone-manage so it was ensure for admins for special purposes. Maybe.
18:36:19 <dolphm> "Customer doesn't want to replicate databases between several geo-distributed datacenters" -- why not?
18:36:38 <amakarov> agrebennikov: ^
18:36:41 <notmorgan> dolphm: a low-volume of change, small dataset db.
18:36:53 <notmorgan> dolphm: keystone with fernet isn't crazy changing data.
18:37:05 * notmorgan narrows the case down a little
18:37:09 <dstanek> dolphm: last week it was said that they had a sync issue and they killed the DBs in multiple datacenters
18:37:11 <samueldmq> notmorgan: I am with other cores, don't like the idea of changing only the porject API for a very specific case
18:37:19 <ayoung> what about revocations
18:37:33 <rodrigods> samueldmq, another good point
18:37:33 <jamielennox> ok, we do need to move along
18:37:36 <ayoung> those would need to be replicated.
18:37:41 <notmorgan> ayoung: i know hold up.
18:37:52 <notmorgan> dstanek: ok. fair enough.
18:37:52 <samueldmq> sounds like an issue that should be solved at deployment level, like dolphm just mentioned
18:38:06 <agrebennikov> dstanek, that was exactly the issue they had
18:38:47 <jamielennox> so i'm going to take it as a -1 from most cores to the general idea but we can continue to discuss it all after the meeting
18:38:52 <notmorgan> jamielennox: ++
18:39:00 <dstanek> agrebennikov: is it possible that they were just doing it wrong or is this a problem with the sync software you use?
18:39:10 <notmorgan> jamielennox: that was the result here.
18:39:10 <jamielennox> #topic Return request-id to caller" and other meta values
18:39:18 <lbragstad> let's all resync after dolphm gets a spec up?
18:39:19 <jamielennox> breton_: yours
18:39:27 <breton_> as far as i remember, you guys decided to talk about the subject at the summit
18:39:35 <breton_> and choose which approach to use for adding properties to responses returned by ksc
18:39:44 <breton_> there were 2 possible ways:
18:39:57 <breton_> 1. Somehow add properties to default python types (eeryone boo here)
18:40:14 <notmorgan> breton_: euuuuwwww :(
18:40:15 <breton_> 2. Create a new class, "Response", and do things there
18:40:45 <notmorgan> breton_: generally speaking, working with a response object (imo) sounds more correct than wedging data onto python primatives.
18:40:51 <breton_> i am interested in this because i need to do something similar for horizon -- they want to consume flag "truncated" returned for list operations
18:41:01 <dstanek> breton_: i didn't just boo. i threw my laptop in a fit of rage
18:41:19 <breton_> and we decided that i'll do it the same way as "return request id to caller"
18:41:19 <gyee> dstanek, I can only imaging that :D
18:41:29 <breton_> https://review.openstack.org/#/c/261188/
18:41:50 <breton_> https://review.openstack.org/#/c/261188/ is moving but too slow, and i want finally some consensus on that
18:41:50 <jamielennox> ah, there it is, i couldn't find it
18:42:03 <jamielennox> #link https://review.openstack.org/#/c/261188/
18:42:09 <breton_> because i need to do my thing too
18:43:33 <breton_> did you discussed it? Also, please add your thoughts to https://review.openstack.org/#/c/261188/
18:43:34 <amakarov> breton_: maybe you contack the author and pick that up?
18:43:45 <breton_> amakarov: the author wrote to the mailing list today
18:43:57 <dstanek> breton_: isn't that review doing #1?
18:44:03 <breton_> dstanek: it is
18:44:38 <jamielennox> i'm not sure that request_id ever escapes keystoneclient doing it this way
18:44:45 <jamielennox> but they can be review comments
18:45:19 <dstanek> jamielennox: ++ i said that early on. that casting or type maniplation may give you a new python primitive without the request id.
18:45:34 <jamielennox> breton_: ok, so we need to get some eyes on that review - i think we need to look at a better response object, i'm not sure about wrapt-ing the whole thing
18:45:50 <dstanek> i think a response object is in order so that we can expose other meta data
18:46:20 <jamielennox> dstanek: right, so that response gets turned into a manager specific resource before returning to the user, so we should be able to figure out something there
18:46:32 <jamielennox> breton_: ok for me to move on?
18:46:48 <breton_> jamielennox: yes. Everyone, please comment on that review.
18:46:56 <jamielennox> #topic KeystoneAuth Release today
18:46:59 <shaleh> any chance this work could also assist with the cross project goal of having a shared request_id so a request can be tracked through the layers of OS?
18:47:15 <notmorgan> just an FYI, we're going to release ksa this week.
18:47:27 <jamielennox> shaleh: sigh - that's a long discussion
18:47:35 <notmorgan> it has new betamax support etc.
18:47:36 <shaleh> jamielennox: I know :-(
18:47:45 <jamielennox> so https://review.openstack.org/#/c/321814/ is the only outstanding review i would want to see in this review
18:47:52 <notmorgan> scream and yell if you're unhappy.
18:48:14 <jamielennox> there are a couple of +2s but no +A as ayoung has offered to test it for us :)
18:48:24 <notmorgan> ayoung: can you confirm/ upgrade to +2/+A today?
18:48:32 <notmorgan> ayoung: or tomorrow
18:48:33 <ayoung> jamielennox, was wokring on getting a setup running again
18:48:46 <ayoung> turns out I was running OSP 7...Pre mitaka stuff
18:48:47 <jamielennox> ayoung: yea, it broke for me too
18:49:08 <jamielennox> love to get a gate going on this stuff
18:49:11 <ayoung> but I should be able to test that on my laptop talking to it
18:49:16 <notmorgan> i'll hold the release until you've tested it/are ok (at least until wednesday)
18:49:22 <ayoung> will do
18:49:29 <notmorgan> ayoung: thanks. :)
18:49:34 <jamielennox> #action ayoung test and approve https://review.openstack.org/#/c/321814/
18:49:36 <shaleh> ayoung: you have 6 hours, run.....
18:49:54 <jamielennox> #topic Service user permissions
18:49:57 <notmorgan> s/wednesday/thursday
18:50:07 <samueldmq> ayoung: thanks
18:50:11 <jamielennox> #link https://review.openstack.org/#/c/317266/
18:50:42 <jamielennox> so i prompted everyone to think about the consequences of this last week (week before?) and so far have no reviews
18:51:10 <shaleh> on the face of it this sounds like a bad idea
18:51:19 <jamielennox> i'd really like everyone's impression of this because it's a big conceptual change that i would like people to be on board with or kill
18:51:38 <gyee> jamielennox, I suggest OSS folks take a look at it as well
18:51:48 <shaleh> "just trust me" is never good security
18:52:01 <jamielennox> gyee: good point - i need to ML it with [security]
18:52:35 <ayoung> yeah,  disagree
18:52:54 <ayoung> we don't want the token validated, we want the "user still has this allowed" validate
18:53:16 <notmorgan> ayoung: i disagree so much with that
18:53:28 <ayoung> two distinc things...a service user should not be tied to the token expiry, but they should only be able to do things a user has asked them...its like S4U2Proxy
18:53:44 <notmorgan> validating that every single step is crazypants imo.
18:54:18 <notmorgan> but then again i clearly am in the minority here.
18:54:24 <gyee> something to consider, if we are sharing memcache for token validation result, it will have similar issues, security-wise
18:54:36 <dstanek> notmorgan: validating the authz is crazypants?
18:54:49 <jamielennox> ayoung: that was my initial gut feeling here as well, still validate the credential headers for consistency at every step
18:55:15 <jamielennox> but i'm having a hard time coming up with what that solves rather than just trusting everything from another service
18:55:16 <notmorgan> dstanek: validating at every single stage in the chain is crazypants because we end up with the broken model of "oh we didn't know you cant do X 5 services deep"
18:55:16 <ayoung> notmorgan, if a user loses access to, say a Cinder volume, that she might have had a month ago, the service user should not be able to override
18:55:34 <gyee> I have two words, PKI tokens!
18:55:38 <ayoung> the service user should not be tied to token expiry, but the delegation should not be infinite, either
18:55:49 <ayoung> a service request should be good for , say, 24 hours
18:55:55 <notmorgan> ayoung: and if you're coming back a month later, you shouldn't be using the same request :P
18:56:03 <ayoung> and a token for 5 minutes
18:56:08 <ayoung> notmorgan, exactly
18:56:42 <jamielennox> yea,  i don't think a month is reasonable here, there is a certain level of trust we would need to put on the services to forward the right thing, but we have that anyway
18:56:43 <notmorgan> ayoung: within a specific scope/request validating permissions (not general auth) at every step is crazy. once you know you're allowed to do X, let them do it.
18:56:57 <notmorgan> ayoung: i think we're quibbling over some small details thugh, mostly we're on the same page.
18:57:09 <ayoung> jamielennox, so  what is proposed here is that nova would be able to do anything anywhere
18:57:25 <jamielennox> also unfortunately this doesn't fix the enforce policy only at the edge either, just token expiration
18:57:45 <dstanek> i'm generally +1 to this idea, but i have to admin i haven't read the spec yet
18:58:01 <jamielennox> ayoung: it has that effect - however conversely to make things work at all nova service user typically has admin already
18:58:08 <notmorgan> jamielennox: that is a big step forward
18:58:20 <notmorgan> jamielennox: the expiry check is a huge win for openstack
18:58:22 <ayoung> notmorgan, we are not 100% on the same page.  I do wantto check up front "can the user do, right now, everything they are erequesting" and return a 40X if they can't
18:58:24 <ayoung> there we both agree
18:58:29 <notmorgan> jamielennox: so, generally +1.
18:58:31 <ayoung> but there are 2 things I want byond that
18:58:43 <ayoung> 1.  that the servcie use does not have carcte blanche to do anything anywhere
18:59:06 <jamielennox> ayoung: that is a possible future thing
18:59:07 <ayoung> 2.  that the permission gets rechecked based on the delegation at the time of execution
18:59:09 <notmorgan> ayoung: fwiw, they already pretty much do :P most service users *are* admins.
18:59:13 <ayoung> I care far more about 1 than 2
18:59:20 <ayoung> notmorgan, I know
18:59:33 <ayoung> notmorgan, I'm the crazy person that came up wiuth trusts....remember?
18:59:44 <jamielennox> ok - were out of time again
18:59:51 <lbragstad> o/
18:59:54 <jamielennox> i'll send a ML this week
18:59:58 <notmorgan> jamielennox: ++
19:00:02 <jamielennox> lbragstad: ?
19:00:05 <notmorgan> that is the next logical step.
19:00:11 <jamielennox> quick
19:00:30 <jamielennox> please review
19:00:36 <jamielennox> #endmeeting