18:01:53 <stevemar> #startmeeting keystone
18:01:54 <openstack> Meeting started Tue Feb  9 18:01:53 2016 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:57 <openstack> The meeting name has been set to 'keystone'
18:02:11 <stevemar> #topic mitaka-3 release countdown
18:02:22 * notmorgan hides under a rock.
18:02:37 <topol> nowhere to hide notmorgan :-)
18:02:43 <stevemar> so we are about 3 weeks away from feature freeze
18:02:55 <notmorgan> topol: i'm so not talking to you for pointing out i can't hide here. :P
18:03:01 <stevemar> #link https://launchpad.net/keystone/+milestone/mitaka-3
18:03:09 <topol> notmorgan :-)
18:03:11 <stevemar> there are lots of bugs and blueprints to fix still
18:03:35 <stevemar> so please prioritize reviews that address blueprints and bugs
18:04:02 <stevemar> the following BPs need code reviews: domain-roles, totp, service providers and catalog, shadow users
18:04:04 <notmorgan> ftr: i'm hoping to have posted conversions for ~4-5 client libs this week to ksa/occ. so i wont be looking at those things.
18:04:13 <notmorgan> just a heads up. [for this week]
18:04:26 <dstanek> we still have a few high priority bugs that don't yet have fixes
18:04:29 <stevemar> notmorgan: boo
18:04:40 <stevemar> dstanek: that is also true
18:04:44 <notmorgan> stevemar: do you want KSA/OCC in client libs or not?
18:04:44 <samueldmq> notmorgan: good thing
18:05:18 * notmorgan already reviewed totp though.
18:05:22 <samueldmq> dstanek: yes true
18:05:27 <stevemar> there are a few bugs related to implied roles that ayoung needs to land
18:05:44 <dstanek> stevemar: the bugs have landed, but are there fixes?
18:05:53 <gyee> is domain-roles a go or no-go?
18:06:01 <notmorgan> i discussed the ocnfig file vs API "security" with him. he's going to fix the bug i opened by moving to a multistropt fwiw
18:06:02 <stevemar> dstanek: no fixes yet...
18:06:04 <notmorgan> stevemar: ^
18:06:32 <stevemar> gyee: was hoping henrynash would be online for that!
18:06:53 <lbragstad> notmorgan do you have a patch for that?
18:07:00 <samueldmq> notmorgan: this https://bugs.launchpad.net/keystone/+bug/1517037 ?
18:07:02 <openstack> Launchpad bug 1517037 in OpenStack Identity (keystone) "API-based Domain specific config does not check for type of option" [Medium,New]
18:07:24 <stevemar> samueldmq: no, https://bugs.launchpad.net/keystone/+bug/1541540
18:07:25 <openstack> Launchpad bug 1541540 in OpenStack Identity (keystone) "Implied role "root_role" config needs to be expanded" [High,Triaged] - Assigned to Adam Young (ayoung)
18:08:03 <ayoung_> That one is not too hard.  I should have it shortly
18:08:05 <samueldmq> stevemar: thx
18:08:13 <stevemar> ayoung_: cool
18:08:20 <ayoung_> going to change to MultiStrOpt
18:08:27 <notmorgan> super easy change.
18:08:29 <lbragstad> why not ListOpt?
18:08:30 <gyee> hah, looks like totp is not encrypting/decrypting the credentials
18:08:35 <notmorgan> lbragstad: roles can have ',' in the names
18:09:05 <lbragstad> the openstack-ansible project has been running into issues with multistropts
18:09:08 <ayoung_> lbragstad, also I can do it backwards compat
18:09:22 <notmorgan> ayoung_: this doesn't need to be backwards compat
18:09:26 <notmorgan> it just landed :P
18:09:35 <stevemar> notmorgan: we haven't released anything with implied roles yet
18:09:54 <notmorgan> stevemar: i just said that :)
18:09:59 <ayoung_> notmorgan, yeah, but this way I don't have to change and docs or tests, either
18:10:02 <ayoung_> smaller change
18:10:10 <notmorgan> ayoung_: you're going to have to change tests in either case really
18:10:11 <stevemar> so... please please please review blueprints!
18:10:13 <notmorgan> and docs.
18:10:14 <ayoung_> if I have problem with multistropt I'lll bail
18:10:27 <ayoung_> nah, should just be added test, but the exisitng ones should pass unchnged
18:10:40 <lbragstad> ayoung_ config generators will have problems with multistropts versus listopts
18:10:52 <lbragstad> ayoung_ you should swing by #openstack-ansible
18:10:55 <notmorgan> anyway. the ',' issue is bigger
18:11:01 <notmorgan> reason to do multistropt
18:11:09 <ayoung_> ++
18:11:17 <notmorgan> ayoung_: your tests should pass in both cases fwiw.
18:11:17 <ayoung_> I'll post it, and we can argue there.
18:11:22 <stevemar> getting off topic at this point :P
18:11:26 <stevemar> yes
18:11:28 <notmorgan> both end up [] in the conf
18:11:29 <notmorgan> anyway
18:11:48 <stevemar> #topic fixing the pipeline
18:11:51 <stevemar> notmorgan: ^
18:12:04 <notmorgan> so. lots of changes posted
18:12:06 <stevemar> maybe just debrief the team on what you've cooked up?
18:12:11 <stevemar> #link: https://review.openstack.org/#/q/topic:bp/extensions-to-core
18:12:35 <notmorgan> basically cleanup the entire paste pipline to be size_limit request_id [api_public|api_admin|service_v3]
18:12:52 <notmorgan> for each entry
18:12:58 <notmorgan> it finishes the work of making all extensions core
18:13:04 <notmorgan> and baking in our "required" middleware
18:13:17 <bknudson_> these weren't extensions
18:13:34 <notmorgan> this means we now are working in code for all the APIs and middleware required by keystone instead of fighting with paste + code
18:14:11 <notmorgan> basically it means keystoine is one app [like it should have been] instead of many things that could/might work as long as you don't touch it
18:14:17 <ayoung_> Docs and such can still go in post M3, right?
18:14:17 <dstanek> this makes me happy. anything we don't want the deployer to change should be in our code
18:14:33 <stevemar> ayoung_: yes, docs and tests
18:14:46 <notmorgan> there is one caveate, the AWS compat code has some added logic since there are orgs that need to remove it for legal reasons
18:14:50 <dstanek> we can still architect the system in terms of middleware, but it's not longer optional
18:15:05 <notmorgan> this is documented so it isn't going to be rolled in and break them
18:15:08 <dolphm> notmorgan: why not keep ec2 as a proper extension then?
18:15:17 <notmorgan> dolphm: because it wont be under authcontext
18:15:41 <dolphm> notmorgan: explain?
18:15:48 <notmorgan> authcontext is moved into the main app
18:16:09 <notmorgan> which handles all the token parsing validation, etc, as is url normalizer, and jsonbody
18:16:14 <dolphm> so, custom extensions can no longer take advantage of it?
18:16:42 <notmorgan> i'll work up a way to lead extensions in with authcontext more easily.
18:16:55 <notmorgan> but basically we shouldn't be using the paste pipeline for this
18:17:09 <notmorgan> true middleware can continue to work/filter
18:17:15 <dolphm> of those, auth context sounds like the only one that should have stayed in the pipeline
18:17:26 <bknudson_> sounds like we're reimplementing paste
18:17:30 <notmorgan> except if someone breaks it/moves it puts things under it
18:17:32 <notmorgan> we are horked
18:17:41 <notmorgan> so it can't really be in the pipeline.
18:17:53 <topol> the original pipeline reminded me of Garanimals (reference link for all you youngin's out there http://www.garanimals.com/how.htm)
18:17:54 <dolphm> notmorgan: we or they?
18:17:59 <notmorgan> dolphm: they.
18:18:05 <notmorgan> dolphm: "we" the devs here i trust
18:18:13 <dstanek> bknudson_: no, paste is just a way in config to do something like middleware(middleware(app()))
18:18:17 <ayoung_> topol, the issue iwth past is that it did not allow you to make reusaable chains of filters.
18:18:30 <ayoung_> I tried to make that work at one point, but it was too invasive
18:19:07 <ayoung_> So if you wanted to say "all theses sub pipelines need these five compnenets in this order" you couldn't...you have to duplicate
18:19:09 <notmorgan> it would be just as easy to wrap your extension in RequestHandler (i'll make it public) and benefit from it as well.
18:19:10 <dolphm> invasive?
18:19:40 <notmorgan> and pass the info down/handle the case the info has been pased down already
18:19:42 <ayoung_> dolphm, yeah...not sure if I still have the POC code, but it involved really changing how the pipelines were built
18:19:45 <bknudson_> we weren't even using the paste pipeline consistently -- https://review.openstack.org/#/c/198931/
18:19:54 <ayoung_> I still feel bad for not finishing it
18:19:59 <bknudson_> so we might as well get rid of it since it never really worked anyways
18:20:06 <ayoung_> it would have made paste much more usable...maybe I'll look again when I get time
18:20:06 <dolphm> ayoung_: i thought you were talking about just implementing a single filter
18:20:15 <ayoung_> dolphm, that was my fallback
18:20:16 <notmorgan> but basically this makes keystone an app not "a mix of randomly used things that some are required some aren't and might break if you change them"
18:20:18 <dolphm> it's pretty usable as is, imo
18:20:24 <ayoung_> dolphm, I like paste, I just wanted it to do more....
18:20:42 <dolphm> notmorgan: i agree with most of your changes, especially jsonbody (we don't have to worry about xml anymore!), etc
18:20:54 <bknudson_> does getting rid of paste make it easier to use falcon?
18:20:57 <topol> notmorgan is trying to bring us sanity to our world
18:21:03 <ayoung_> dolphm, yeah, which is why I felt this would have been a good next step.  Its so close
18:21:15 <ayoung_> you can do what I wanted to do manually, it just involved a lot of copy paste
18:21:22 <stevemar> notmorgan: what about folks that had custom middleware that relied on auth context?
18:21:38 <topol> stevemar good question!
18:21:44 <dolphm> but the auth context one will punt a big burden back on anyone writing custom filters that could otherwise use it, and directly rejects same architecture we offer to other projects with keystonemiddleware.auth_token
18:22:19 <notmorgan> dolphm: so, my argument will be to make them wrap their app in the request handler [and doc it]
18:22:33 <notmorgan> and then make sure we handle the case the handler was already called
18:22:43 <ayoung_> I wanted FILTER_PIPELINE=sizelimit url_normalize request_id build_auth_context  json_body ec2_extension_v3 s3_extension
18:22:45 <ayoung_> and then
18:22:47 <notmorgan> dolphm: it'll be a 2 line change
18:22:48 <dolphm> but we already support paste, and have forever...
18:22:53 <notmorgan> ayoung_: no. please no :(
18:23:03 <ayoung_> pipelinet = FILETER-PIPELINE service_v3
18:23:11 <ayoung_> notmorgan, I never got it to work
18:23:21 <notmorgan> ayoung_: because paste doesn't work like that :P
18:23:22 <dolphm> ayoung_: you're describing a contribution to paste itself, not keystone
18:23:36 <ayoung_> dolphm, rihgt, that is what I never got to work
18:23:42 <ayoung_> anyway...
18:23:57 <stevemar> notmorgan: what about folks that had custom middleware that relied on auth context?
18:23:58 <notmorgan> dolphm: anyway, if we as keytone rely on this code, we shouldn't have it in the paste-pipeline
18:24:06 <notmorgan> stevemar: ^ see above
18:24:19 <dolphm> notmorgan: counter proposal -- what if we rolled things up slightly differently than how you have
18:24:19 <ayoung_> The issue was that we could not make better use of paste, like having one pipeline for auth mechacnism without duplicating all of the middleware pieces that have to be on each one
18:24:20 <notmorgan> stevemar: i'll add another patch + doc that they wrap thier middleware with.
18:24:50 <notmorgan> dolphm: as long as authcontext isn't removable/baked in. this was the #1 reason for the work.
18:25:01 <bknudson_> maybe we need a spec for this?
18:25:14 <ayoung_> dolphm, if you dig in the IRC logs, I think you will find yo uand I had this exact conversation about 3 years ago or so
18:25:16 <dolphm> understatement ^
18:25:27 <notmorgan> i'm also happy to just drop the code if this direction isn't interested
18:25:30 <notmorgan> interesting.
18:25:49 <ayoung_> spec it, and we can consider for Newton?
18:25:55 <stevemar> notmorgan: it's something i want to see happen, but i think we need to double check we aren't screwing people over
18:26:08 <stevemar> newton is definitely a good candidate
18:26:09 <dolphm> notmorgan: actually, a lot of the things you put into core could have been rolled into a single, mandatory filter
18:26:26 <notmorgan> dolphm: no such thing as "mandatory" filters in paste
18:26:36 <dolphm> notmorgan: so the default pipeline would be something like mandatory_filter ec2_api_extension core_app
18:26:58 <notmorgan> dolphm: i simply disagree that a "mandatory" filter is good architecture
18:27:01 <dolphm> notmorgan: a nickname for components useful to not only the app, but also to api extensions and other middlewares
18:27:27 <ayoung_> Let me say the same thing I say at this point in each release cycle.  The most valuable time is approaching:  once Milestone 3 is out, we really need to start thining about what is going to get into the next release.  We can't discuss something big for the first time at  at the Summit and expect it to get in to the next release
18:27:38 <notmorgan> anyway it's a 4 line change to spin request handler out into it's own filter
18:27:41 <bknudson_> are you saying that because mandatory is in the name deployers will be smart enough to not remove it?
18:27:45 <dolphm> notmorgan: highly_reusable then
18:28:07 <notmorgan> since it really is that, just auto-wrapping the factories
18:28:11 <notmorgan> sorry 6 line
18:28:33 <notmorgan> but seriously, this was just another cleanup change that we'd talked about in the past
18:28:38 <dolphm> notmorgan: but you're disregarding almost all the utility of paste in the process
18:28:46 <samueldmq> was it possible to add a custom_middleware in the coded pipeline (extracted from paste to code) so custom extensions could still take advantage of current filters ?
18:28:49 <notmorgan> dolphm: i personally think paste needs to be removed.
18:28:57 <samueldmq> like a hook for their custom things ?
18:28:58 <dolphm> samueldmq: yes, definitely
18:29:05 <stevemar> gonna switch topics in 2 minutes
18:29:09 <dolphm> samueldmq: ec2 was an example of that, along with several others
18:29:41 <bknudson_> we did actually agree to stop having extensions and move them to core
18:29:42 <notmorgan> so i'm fine if someone wants to take this work and run with it if it's not that interesting. i really have committed the time to it i'm going to [was planning on letting it sit until steve put me on the spot for this meeting]
18:29:51 <jamielennox> i don't like a lot of the way our middleware is doing things like reaching into the db, but in deployers defence no-one is actually removing critical things from the paste pipeline - otherwise keystone would just not work
18:29:57 <stevemar> bknudson_: but these aren't really extensions
18:30:06 <notmorgan> s/not that interesting as it sits/
18:30:09 <samueldmq> dolphm: got it
18:30:12 <notmorgan> jamielennox: ++
18:30:23 <notmorgan> jamielennox: fair enough
18:30:31 <stevemar> switching topics
18:30:32 <notmorgan> jamielennox: but i agree the middleware should never reach into the db
18:30:34 <stevemar> lbragstad: get ready
18:30:35 <notmorgan> so.
18:30:40 <samueldmq> stevemar: looks like a small spec for holding discussions ?
18:30:45 <notmorgan> authcontext is broken in that regard
18:30:52 <ayoung_> notmorgan, I'd probably have just pushed for "a single middleware that does everythiung" and elliding the paste pipeline" but not remove it altogether
18:31:13 <topol> elliding?
18:31:16 <notmorgan> anyway, so run with it, don't i've got things to work on besides this and i wasn't going to push this agenda further except i was put on the meeting today
18:31:28 <notmorgan> review the locla cache tihg
18:31:28 <ayoung_> topol, ya know like ellipses?
18:31:29 <notmorgan> thing*
18:31:32 <notmorgan> that is more important
18:31:38 <ayoung_> ++
18:31:42 <stevemar> notmorgan: no decision on this one yet, thanks for the patches, please keep them online
18:31:53 <notmorgan> stevemar: i wont be rebasing them / folling them
18:31:59 <stevemar> thats fine
18:32:00 <notmorgan> stevemar: so i'll let others cover it.
18:32:05 <stevemar> y
18:32:05 <ayoung_> next topic is trusts.
18:32:10 <notmorgan> if they want the EC2/S3 ones should be reviewed
18:32:14 <stevemar> #topic trusts and v2.0
18:32:14 <notmorgan> just cause that is no-extension things
18:32:15 <ayoung_> My suggestion is that we leave them until we remove the V2 API
18:32:18 <lbragstad> v2.0 and trusts - do we support it official or can we not... http://lists.openstack.org/pipermail/openstack-dev/2016-February/086165.html
18:32:32 <stevemar> #link: https://review.openstack.org/#/c/274850/
18:32:36 * notmorgan doesn't care about v2 trusts.
18:32:38 <lbragstad> if we want to support is then isn't another thing we have to build into v2.0 fernet tokens
18:32:42 <stevemar> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086165.html
18:32:46 <ayoung_> 1.  they went in pre specs
18:32:48 <notmorgan> and i remember they didn't work well for a while.
18:32:51 <notmorgan> or at all
18:32:51 <ayoung_> there was no V3 only aspect to thenm
18:32:56 <ayoung_> and I think you will break Heat
18:32:57 <notmorgan> then they did then they didnt.. then they did
18:33:14 <stevemar> dolphm: do you remember what happened back then?
18:33:20 <lbragstad> ayoung_ it will only break heat *iff* they are authenticating against v2.0
18:33:24 <ayoung_> I never added them to the v2 api cus I nver figures out how to build the v2 docs.  I know, I suck
18:33:42 <bknudson_> wadl sucks
18:33:46 <stevemar> yep
18:33:51 <ayoung_> lbragstad, might not be Heat teams choice
18:33:52 <gyee> hey now :)
18:34:01 <samueldmq> trusts are a v3 concept right ?
18:34:14 <lbragstad> at the time they were an extension
18:34:17 <ayoung_> a site might still be set up V2 only.  We see a lot of tht, due to either malfeasance or incompetnace I wont say
18:34:19 <stevemar> lbragstad: whats the amount of work to get fernet tokens to play nice with v2 auth and trusts?
18:34:22 <ayoung_> no
18:34:35 <ayoung_> trusts are a token concept that came out areoun the same time as v3
18:34:46 <ayoung_> but they were v2 as well
18:34:55 <samueldmq> so nobody can say it's a v3 only thing
18:35:18 <dolphm> the /trusts api only exists in v3
18:35:25 <raildo> stevemar, it is breaking a couple of tests related to this.... and I didn't found a simple solution for it
18:35:28 <lbragstad> it's under the v3 route
18:35:40 <samueldmq> how was the route before moving to core ?
18:35:42 <dolphm> there is no documented impact of trusts on v2.0 that i'm aware of
18:35:47 <raildo> it's under v3 route, but we have code related on v2 =/
18:35:48 <samueldmq> uner /v3 already?
18:35:54 <dolphm> samueldmq: /v3/trusts
18:35:58 <ayoung_> dolphm, actually, that i recent.  It used to be under extensions.  So, no one has complained yet
18:36:08 <ayoung_> that either means that we are fine, or no one is running the new code
18:36:14 <samueldmq> ayoung_: ++
18:36:29 <dolphm> trust docs https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-trust-ext.rst
18:36:53 <ayoung_> so, any feedback on the mailing list post?
18:37:01 <topol> I dont recall any v2 trust docs
18:37:03 <stevemar> ayoung_: so that's why i asked lbragstad to send the note to the list
18:37:09 <samueldmq> in the worst case, we could deprecate trusts+uuid and document they aren't supported in fernet+v2?
18:37:19 <ayoung_> that just wnt out.  Cool.  Let's see, and I'll bug #Heat to respond
18:37:24 <lbragstad> also v3 routers were added on august 2 2014 - https://github.com/openstack/keystone/blame/master/keystone/trust/routers.py#L33
18:37:43 <stevemar> ayoung_: assuming there are no responses, are you okay with that patch that nixes support for v2 and trusts?
18:37:44 <lbragstad> or that's the last time it was touched
18:37:48 <lbragstad> it could have been done before that
18:38:26 <topol> I htought trusts was yet another carrot to get folks to v3?
18:38:30 <ayoung_> stevemar, its not me.  I really don't care.  I want all of v2 to die, so dieing incremenatlly is fine
18:38:32 <samueldmq> I think we should just deprecate, and document v2+trusts+fernet is a thing that doesn't exist
18:38:48 <ayoung_> I just think we are going to screw people, and won't find out for a while
18:38:51 <topol> samueldmq ++
18:38:56 <dolphm> lbragstad: gate tests pass if you remove support, right?
18:38:58 <ayoung_> but. if the anser is use V3...I can get behind that
18:39:37 <stevemar> *grumbles*
18:39:42 <ayoung_> I suspect we will be OK
18:39:53 <stevemar> let's bug heat after this
18:39:56 <ayoung_> if it is Fernet vs trusts , i side with Fernet
18:40:01 <raildo> dolphm, tests related to v2+trusts+fernet will pass
18:40:27 <ayoung_> you know what, yes...lets kill it.
18:40:38 <stevemar> ayoung_: comment on the patch
18:40:40 <ayoung_> its a risk, but the answer is "move to v3"
18:40:44 <ayoung_> will do
18:40:55 <ayoung_> can we have a vote on it
18:41:09 <stevemar> i think we all want it removed
18:41:11 <samueldmq> deprecating is the right way to ensure no one will be using upon removal :(
18:41:11 <ayoung_> can be "+1 the patch if yo usupport"
18:41:37 <samueldmq> at very least, I wanted to see a bug opened, and a release note
18:41:37 <stevemar> it's just a bit of uncertainty around it
18:41:46 <samueldmq> to let people say it was "supported" by mistaake
18:41:48 <samueldmq> mistake*
18:41:59 <ayoung_> samueldmq, so...lets see if there is any feedback on the mailing list for now
18:42:03 <stevemar> samueldmq: that's a good idea
18:42:07 <topol> if we deprecate wil that help flush out if anyon was using it?
18:42:31 <ayoung_> it wasn't a mistake.  But As pointed out, you need V3 to do anything interesting with trusts.  V2 Tokens alone don't buy much
18:42:51 <raildo> ayoung_, ++
18:42:54 <stevemar> topol: deprecations take 2 releases, we wanted to make fernet the default in M
18:42:56 <ayoung_> that was where we really changed things.
18:43:04 <ayoung_> yeah, Fernet is too important
18:43:09 <ayoung_> we can mea culpa this one
18:43:15 <samueldmq> stevemar: we could simply deprecate uuid+fernet+v2
18:43:31 <samueldmq> stevemar: sorry, I meant uuid+v2+trusts
18:43:35 <topol> samueldmq thats what I meant
18:43:40 <ayoung_> samueldmq, Id rather not
18:43:44 <samueldmq> and simply say v2+fernet isn't supported
18:43:47 <ayoung_> I want uuid and fernet to yuse the same mechanism
18:43:47 <samueldmq> ^
18:43:50 <lbragstad> samueldmq if we land fernet as the default then uuid is going to be deprecated anyway
18:43:54 <ayoung_> it cleans up the revoke story a huge amount
18:44:02 <ayoung_> keeping anything in the DB for uuid breaks that
18:44:15 <lbragstad> offline discussion? I know jorge_munoz has a ton of trust questions too
18:44:17 <lbragstad> stevemar ^
18:44:21 <stevemar> lbragstad: yeah
18:44:26 <lbragstad> i think we can carry this in the review
18:44:28 <stevemar> let's get jorge_munoz some time
18:44:45 <stevemar> #topic Trust workflow
18:44:50 <stevemar> jorge_munoz: you're up
18:45:09 <jorge_munoz> So my question are regarding trust workflow.
18:45:15 <jorge_munoz> Are redelegation and impersonation multually exclusive?
18:45:26 <jorge_munoz> Should it be allowed to create trust with both redelegation and impersonation set to true?
18:45:45 <amakarov> jorge_munoz, no and yes )
18:46:02 <amakarov> yes - to the last question
18:46:14 <jorge_munoz> So, I was thinking that maybe we need a new attribute in trust called allow impersonation
18:46:32 <lbragstad> jorge_munoz so make them mutually exclusive?
18:46:41 <amakarov> impersonation allows to mimic the trustor
18:46:45 <lbragstad> jorge_munoz is that what you're suggesting?
18:47:01 <amakarov> lbragstad, what for?
18:47:05 <dolphm> fernet hasn't supported v2 trusts since kilo, right?
18:47:07 <jorge_munoz> allow_impersonation would allow to impersonate at the end of a trusted chain
18:47:13 <ayoung_> jorge_munoz, nope
18:47:32 <ayoung_> it is not an element of a trust
18:47:42 <jorge_munoz> Currently one can only delegate a trust using impersonation throu out the chain
18:48:02 <ayoung_> if you do impoeronsation, and allow redelgation, the redlegated trust should be impersonation only
18:48:03 <samueldmq> dolphm: yes, so just keep doing that, make fernet default, and with the default v2+trust isn't supported anymore
18:48:16 <ayoung_> don't change the rules from layer to layer
18:48:29 <ayoung_> I would not do impoersonation one level and not have that carry on
18:48:30 <topol> samueldmq that makes sense to me
18:48:59 <topol> solve it with a release note :-)
18:49:07 <amakarov> ayoung_, btw I don't remember whether we have this validated somehow
18:49:11 <samueldmq> topol: o/
18:49:20 <jorge_munoz> So redelegation does not work in impersonation
18:49:40 <jorge_munoz> If impersonation is used a trust is just being created as the original trustor.
18:49:41 <amakarov> jorge_munoz, it works
18:49:58 <lbragstad> jorge_munoz right - you actually end up with a trust web, it's impossible to create a "chain" with redelegation and impersonation
18:51:24 <jorge_munoz> So trust can be created with impersonated tokens?
18:51:52 <jorge_munoz> Its currently allowed, but thats not really redelegated a trust.
18:51:52 <notmorgan> dolphm: fernet never supported v2 trusts
18:52:02 <jorge_munoz> redelegating*
18:52:04 <stevemar> jorge_munoz: i think so...
18:52:06 <amakarov> jorge_munoz, do you have a use case? I don't see how impersonation affects redelegation
18:52:09 <notmorgan> dolphm: but making fernet default means it has to support the baseline stuff... right?
18:52:24 <ayoung_> lets write up how redelegation should work, and make it work right
18:52:25 <dolphm> notmorgan: i vote to maintain status quo then, until we get an alarming bug report we have to act on
18:52:33 <lbragstad> amakarov jorge_munoz is just working on cleaning up the code because it was a rabbit hole in the clean up revocation events thing he was working on
18:52:35 <jorge_munoz> https://review.openstack.org/#/c/273279/7/keystone/tests/unit/test_v3_auth.py
18:52:38 <notmorgan> dolphm: i generally agree
18:52:40 * dolphm is sorry for still being on the previous topic
18:52:47 <notmorgan> dolphm: /me too
18:52:49 <dolphm> ayoung_: ++
18:52:50 <ayoung_> the way it works now is not right, andnot something we should work to maintain.
18:52:53 <jorge_munoz> line 3289
18:52:57 <lbragstad> ayoung_ ++
18:53:00 <stevemar> dolphm: you're given one warning
18:53:11 <topol> notmorgan, cant we just have release note to explain what doesnt work with the new default. I dont recall us ever saying things worked with v2
18:53:12 <notmorgan> stevemar: ooh do i get kicked out if i go past the warning
18:53:27 <notmorgan> stevemar: /me looks to go home from school!
18:53:34 <dolphm> jorge_munoz: do you think you could document the current state of redelegation behavior in our dev docs?
18:53:40 <stevemar> topol: yeah, lbragstad is gonna whip up a release note
18:53:45 <jorge_munoz> This are test written of how i believe trust worked
18:53:45 <ayoung_> redelegation should be a new trust, with the same or fewer roles as the previous trust
18:53:58 <dolphm> ayoung_: the tests illustrate the current behavior pretty well, too
18:54:03 <topol> lbragstad writes the best release notes.  We're good then
18:54:04 <lbragstad> ayoung_ between the new trustor and the new trustee
18:54:34 <ayoung_> and a new trustee.  The thing we don't track well now is intermediate trustees
18:54:47 <dolphm> ayoung_: the problem is when you redegelate with impersonation - impersonation is applied automatically and the second redelegated trust is created between the "wrong" two users ( jorge_munoz correct me if i'm explaining this wrong )
18:54:58 <ayoung_> with impersonation, the userid should stay the same of the original trustor
18:55:10 <dolphm> ayoung_: *should*?
18:55:11 <notmorgan> i think simply don't allow impersionation redelegate
18:55:14 <notmorgan> simple
18:55:27 <dolphm> notmorgan: ++ :P unless there's a real use case there, it sounds scary
18:55:30 <lbragstad> notmorgan so mutually exclusive - like what jorge_munoz says?
18:55:32 <notmorgan> it doesn't make sense for user X to delegate to Y, and then Y be allowed to make Z user X
18:55:36 <ayoung_> with redelegatio and non translation, the trustor for the new trust is the trustee of the old
18:55:43 <ayoung_> notmorgan, if we could drop impoersaontion al toegether I'd be happy
18:55:52 <ayoung_> the issue is that we probably need the two together
18:55:53 <notmorgan> you could redelegate non-impersonation roles
18:55:56 <jorge_munoz> dolphm: its not the wrong user, its just a user that was delegated a trust.
18:55:57 <stevemar> ayoung_: that won't happen for a while
18:56:06 <ayoung_> I'd love it if no access control was based on the userid
18:56:06 <notmorgan> but i would not allow impersionation
18:56:19 <ayoung_> notmorgan, neither would i,expcet that we had to
18:56:22 <ayoung_> swift and babican
18:56:24 <ayoung_> barbican
18:56:26 <notmorgan> AND i would make sure redelegation with impersonation to non-impersonation works
18:56:32 <notmorgan> between the right two users
18:56:35 <ayoung_> both have object ownership based on userid
18:56:47 <ayoung_> notmorgan, that I would drop
18:56:56 <ayoung_> no  redelegation with impersonation to non-impersonation
18:57:08 <ayoung_> I can't see a use case for it
18:57:09 <samueldmq> 3 minutes left
18:57:20 <lbragstad> so - i think we need to define the behavior want, right?
18:57:25 <stevemar> lbragstad: ayoung_: notmorgan dolphm take it up in -keystone
18:57:34 <stevemar> we're out of time
18:57:34 <samueldmq> lbragstad: ++
18:57:38 <lbragstad> continue in keysotne
18:57:49 <stevemar> please please please review blueprints and bugs this week!!!!!!!!!!!!!!
18:57:50 <jorge_munoz> another point is that redelegated_trust_id is not in its own column
18:58:00 <jorge_munoz> we need to move it out of extras
18:58:02 <stevemar> jorge_munoz: meh, implementation detail
18:58:25 <topol> stevemar which BPs are priority?
18:58:34 <dolphm> stevemar: link to things to review
18:58:43 <samueldmq> topol: https://launchpad.net/keystone/+milestone/mitaka-3
18:58:45 <samueldmq> #link https://launchpad.net/keystone/+milestone/mitaka-3
18:58:47 <stevemar> dolphm: https://launchpad.net/keystone/+milestone/mitaka-3
18:58:54 <topol> thanks!
18:58:54 <amakarov> jorge_munoz, -1 the test is buggy :)
18:59:05 <stevemar> the ones that don't say "implemented"
18:59:20 <stevemar> shadow users: https://review.openstack.org/#/c/262045/56
18:59:22 <samueldmq> it's easy, make them appear in 'implemented'
18:59:24 <samueldmq> that's all :)
18:59:28 <stevemar> service providers and catalog: https://review.openstack.org/#/c/269455/
18:59:33 <stevemar> domain roles: https://review.openstack.org/#/c/261870/
18:59:43 <stevemar> #endmeeting