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