18:01:52 <dolphm> #startmeeting keystone 18:01:52 <openstack> Meeting started Tue Aug 26 18:01:52 2014 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:56 <openstack> The meeting name has been set to 'keystone' 18:02:09 <dolphm> #topic Feature freeze September 4th 18:02:15 <lbragstad> hi 18:02:17 <dolphm> so, that's NEXT WEEK! 18:02:18 <topol> bknudson is free to vacation as long as that means spending all his time on keystone instead of most of it 18:02:48 <dolphm> and we're now in our review window where new features cannot be proposed, and we have a fixed list of reviews to land 18:02:49 <bknudson> that would be nice 18:03:02 <dolphm> which looks like this: 18:03:04 <dolphm> #link https://review.openstack.org/#/q/starredby:dolph+is:open,n,z 18:03:13 <gyee> NFL kick off on 9/4 18:03:26 <dolphm> that's 42 open review, 23 of which still require review/iteration 18:03:57 <bknudson> thanks for the link! 18:04:03 <grantbow> +1 18:04:15 <bknudson> otherwise I'd just use next-review 18:04:26 <dstanek> the validation stuff needs a little rework and some of the reviews will be abandoned today 18:04:42 <dolphm> yay, i'd love to shorten the list 18:04:47 <dolphm> even if it means cheating lol 18:04:59 <dolphm> dstanek: but there was some redundancy in that series? 18:04:59 <morganfainberg> a number of the non-persistent ones are gating 18:05:10 <dstanek> some patches have merged and others are no longer needed :-) 18:05:28 <dstanek> merged into other patches still under reivew... 18:05:44 <lbragstad> dstanek: just proposed https://review.openstack.org/#/c/111620/ which is the first in line 18:05:59 <dolphm> alrighty, as soon as they're no longer open they'll be dropped from that list (either merged or abandoned) 18:06:02 <lbragstad> and needed to do the rest of the testing on the different validation patches 18:06:30 <topol> dolphm, so they all need to be merged by 9/4 correct? 18:06:31 <stevemar> jsonhome and non-persistent are lookin real good! 18:06:41 <raildo> dolphm: I have some patches about hierarchical projects that need to be reviewed 18:06:47 <lbragstad> wait... sorry, wrong link https://review.openstack.org/#/c/116954/1 18:07:05 <dolphm> raildo: i'd like to get those into a feature for juno as well 18:07:30 <henrynash> dolphm, raildo: I’ll volunteer to give those a good review 18:07:45 <stevemar> while we're on the topic of pleading for reviews, can i get folks to look at the keystone2keystone stuff :) 18:07:47 <bknudson> are the hierarchical projects on https://review.openstack.org/#/q/starredby:dolph+is:open,n,z ? 18:07:51 <raildo> henrynash: great, i will send for you 18:07:53 <stevemar> i'll be more than happy to walk people through 18:08:01 <bknudson> and k2k? 18:08:15 <dolphm> bknudson: no, they're not targeted to juno-3 18:08:16 <dstanek> dolphm: can you star those too? 18:08:23 <bknudson> juno-4 ?? 18:08:32 <stevemar> bknudson, it needs love, we finally got our requirements patch landed 18:08:39 <topol> bknudson, we get ajun-4??? 18:08:41 <dolphm> bknudson: dstanek: no, i'd like to land them in a feature branch rather than master 18:08:48 <topol> juno-4? 18:08:48 <dstanek> dolphm: ah, ok 18:08:53 <raildo> henrynash: #link http://paste.openstack.org/raw/100590/ 18:09:07 <morganfainberg> dolphm, there are 2 more minor things to get in for FF if possible, in the non-persistent line, https://review.openstack.org/#/c/116961/ and https://review.openstack.org/#/c/116962/ mostly quality of life fixes no functional changes 18:09:27 <dstanek> raildo: the last time i looked i was pretty happy with how things were going 18:09:46 <bknudson> there's no keystoneclient in https://review.openstack.org/#/q/starredby:dolph+is:open,n,z ... 18:10:00 <morganfainberg> bknudson, ksc and middleware don't have FF in the same way 18:10:00 <bknudson> so I don't know if there's anything that we'd really like to have. 18:10:03 <raildo> dstanek: thank you, the code is almost ready 18:10:12 <dolphm> bknudson: the client falls outside the named release cycle, so it's not under feature freeze, etc 18:10:16 <morganfainberg> bknudson, they are released independent of the named cycles 18:10:31 <bknudson> I realize it's not the same but I assume there'll be a release at about the time of juno 18:10:48 <dolphm> bknudson: usually aim for a last release closer to rc1 18:11:00 <bknudson> ok, can focus on those then 18:11:41 <henrynash> dolphm: the endpoint-policy extenion is in godo shape…but queued up behind getting the endpoint/region/region_id fix in 18:11:43 <raildo> dstanek: henrynash We divided into several patches to facilitate the review,because the change is a little big 18:12:09 <dolphm> henrynash: that's what i've heard :) the Region ID fix looks pretty close last i checked as well 18:12:38 <dstanek> raildo: yes, i've been reviewing them periodically for a week or so 18:12:38 <henrynash> dolphm: indeed…I’ll working with KanagarajM to get that in (https://review.openstack.org/#/c/113183/21) 18:12:43 <dolphm> raildo: and impactful :) we'll need to work together later to get those same patches propoposed to a new branch instead of master 18:13:51 <raildo> dolphm: Ok, I think we can talk about this after the meeting :) 18:14:01 <dolphm> we also have two outstanding work items on https://blueprints.launchpad.net/keystone/+spec/deprecated-as-of-juno that were "assigned" to ayoung and jamielennox, but they appear to be out 18:14:06 <dolphm> oh jamielennox is back! 18:14:11 <dolphm> i stand corrected 18:14:20 <jamielennox> sorry VPN issues 18:14:25 <jamielennox> got here eventually 18:14:49 <dolphm> jamielennox: no worries 18:14:50 <morganfainberg> dolphm, i'll be working on the auth plugin test bits 18:14:58 <morganfainberg> dolphm, it's just refactoring some tests nothing more 18:14:59 <jamielennox> the /auth endpoints are merged in keystone 18:15:06 <jamielennox> the identity-api review is still up 18:15:06 <dolphm> morganfainberg: test bits? 18:15:17 <dolphm> jamielennox: oh we missed the api review?! 18:15:24 <morganfainberg> dolphm, yeah the support for loading auth_plugins by class name is the one from ayoung 18:15:38 <jamielennox> #link https://review.openstack.org/#/c/115423/ 18:15:45 <dolphm> morganfainberg: ++ it has a deprecation message, but doesn't say anything more than 'deprecated.' what's the state of tests? 18:16:12 <dolphm> jamielennox: damn, thanks 18:16:21 <jamielennox> dolphm: the identity-api part is mostly formality as the response format will be the same as existing responses 18:16:27 <stevemar> dolphm, i have a few reviews to move some specs to Kilo 18:16:29 <morganfainberg> dolphm, just need to do a little bit of work to register some config options and de-register them 18:16:30 <jamielennox> so yes we missed it, but not a big deal here 18:16:32 <dolphm> jamielennox: still, we need docs :) 18:17:24 <morganfainberg> dolphm, it's just stopping using the plugins='<class.path.in.keystone>,<other.plugin.class.path>' and going back to the (in my opinion awful), plugins = "name, name name", and separate options for each class 18:18:16 <dolphm> but there was a use case that the deprecated option didn't easily support - using the same plugin under multiple names 18:18:19 <morganfainberg> dolphm, since the class-name loading was not documented people went down the path of assuming it wasn't used and developed whole processes around plungins not "knowing" their method. 18:18:31 <morganfainberg> dolphm, yep. 18:18:50 <bknudson> You'd think we'd use stevedore for plugins 18:19:06 <henrynash> dolphm: did we ever mark the kvs backends for idenity and assignent as deprecated? If so, could we kill them? 18:19:11 <morganfainberg> dolphm, which is why i was willing to let that deprecated option go, and why i'll fix the tests to not use that method (the class-name-method was never documented) 18:19:28 <dolphm> henrynash: good question, not sure? 18:19:42 <morganfainberg> henrynash, no i don't think they've been marked as deprecated 18:19:46 <gyee> bknudson, can't, plugins are deployment-specific, unless we shipt the plugins in separate package 18:19:47 <henrynash> dolphm: I’m looking, but can’t see them marked 18:19:54 <stevemar> down with kvs backends! 18:20:09 <dolphm> henrynash: happy to deprecate them this cycle 18:20:17 <henrynash> dolphm: agreed 18:20:25 <morganfainberg> dolphm, henrynash, the initial thought was to do dogpile for them, but honestly, i don't see a big benefit 18:20:35 <dolphm> except morganfainberg's token backend? (morganfainberg?) 18:20:44 <morganfainberg> dolphm, please don't deprecate the tokne one :) 18:20:52 <henrynash> dolphm, morganfainberg: I’d swear I’ve seen logs saying their deprecate, but maybe in my dreams 18:21:02 <dolphm> henrynash: fantasies* 18:21:06 <morganfainberg> henrynash, the token kvs one will report deprecated 18:21:20 <henrynash> morganfainberg: ah, right…I think that was it 18:21:21 <morganfainberg> henrynash, i'll fix that by making a "test" one that doesn't log that 18:21:22 <dolphm> morganfainberg: but it shouldn't? 18:21:37 <bknudson> the one kvs backend we want to keep is deprecated? 18:21:44 <morganfainberg> oh oh wait 18:22:01 <bknudson> I think some kind of kvs backend is deprecated 18:22:12 <bknudson> like a base kvs backend or something. 18:22:35 <dolphm> we should have a centralized list of everything that's deprecated, sorted by when it'll be removed :( 18:22:40 <morganfainberg> the base key-value-store is deprecated 18:22:59 <bknudson> http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/kvs/legacy.py#n49 18:23:06 <bknudson> remove in J 18:23:15 <morganfainberg> https://github.com/openstack/keystone/blob/master/keystone/common/kvs/legacy.py#L48 18:23:19 <morganfainberg> yes 18:23:32 <morganfainberg> but the KVS identity backend, and assignment backend were not explicitly marked 18:23:44 <morganfainberg> as the initial thought was to re-implement with dogpile 18:24:15 <dolphm> the token backend is the only one i'd appreciate having a kvs option for 18:24:27 <dolphm> dogpile or not, but preferrably dogpile 18:24:29 <morganfainberg> dolphm, and that one uses dogpile 18:24:59 <dolphm> so using a KVS assignment driver **doesn't** log a deprecation warning for example, correct? 18:25:20 <morganfainberg> dolphm, it would log a deprecation message that keystone.common.kvs.KeyValueStore is deprecated 18:25:28 <morganfainberg> dolphm, not that assignment.kvs was 18:25:44 <morganfainberg> erm 18:25:48 <morganfainberg> keystone.common.kvs.Base 18:25:52 <morganfainberg> is deprecated 18:25:54 <morganfainberg> sory 18:26:23 <dolphm> hmm... and was that a +1 or +2 release deprecation? 18:26:27 <morganfainberg> probably not strong enough to remove assignment/identity kvs stores 18:26:34 <morganfainberg> it was a +1, deprecated in icehouse 18:26:36 <henrynash> dolphm: ICEHOUSE+1 18:26:59 <dolphm> maybe we should bump that to icehouse+2 and deprecate the actual drivers? 18:27:06 <morganfainberg> dolphm, sure 18:27:12 <dolphm> so for juno, it'll just be a stronger warning 18:27:14 <morganfainberg> dolphm, i'm on board with that 18:27:20 <henrynash> dolphm: me too 18:27:34 <henrynash> dolphm : and then we get to kill identity and assignment in Kilo 18:27:37 <morganfainberg> and K1 they can disappear... and lighten a ton of code out of our codebase (and tests) 18:28:00 <dolphm> henrynash: \o/ 18:28:09 <henrynash> dolphm: excellent!!! 18:28:21 <dolphm> and that's like next week or something assuming we have no bugs 18:28:31 <bknudson> we can spend more time keeping the ldap backend up with sql 18:28:35 <henrynash> dolphm: sign me up that one! 18:28:57 <dolphm> henrynash: sign up for tweaking the deprecation now, or removing it in kilo? 18:29:24 <henrynash> dolphm: removing in Kilo…but happy to do the dpreciation now too 18:30:34 <dolphm> henrynash: done https://blueprints.launchpad.net/keystone/+spec/deprecated-as-of-juno 18:31:03 <dolphm> morganfainberg: so, on the auth plugin naming thing - are you going to improve the current warning message, or something else? 18:31:30 <morganfainberg> dolphm, i'll improve the message but that method of loading plugins wasn't documented 18:31:48 <morganfainberg> dolphm, more importantly i'll fix the tests to not use that method of loading plugins (without going back to config files) 18:31:52 <dolphm> morganfainberg: the deprecated way wasn't documented? 18:31:56 <morganfainberg> nope 18:32:01 <morganfainberg> but all the tests used it 18:32:05 <dolphm> ah, gotcha 18:32:26 <morganfainberg> i'm not too worried about someone using that method. 18:33:04 <gyee> morganfainberg, but we can support both :) 18:33:38 <morganfainberg> gyee, no, we can't. if someone uses the plugins multuple times, with different names, you can't mix/match 18:33:55 <morganfainberg> gyee, so we'll just remove the load-by-classname support in K? L? 18:34:03 <morganfainberg> and go back to the old way. 18:34:30 <bknudson> I'd just write a plugin and have it report a different name. 18:34:35 <dolphm> so, i hope this isn't lofty with 23 remaining reviews (plus these little patches to improve deprecations), but my goal this week to have all juno-3 things approved and gating by CoB friday so we can have a few days to fight the gate 18:34:55 <bknudson> why would I have plugins multiple times with different names? 18:35:09 <dolphm> so *please* *please* *please* pitch in on reviews 18:35:20 <dolphm> bknudson: your solution was my solution as well 18:35:21 <morganfainberg> bknudson, mapped can be used for SAML, OpenID, K2K, etc 18:35:27 <morganfainberg> bknudson, my solution would be yours 18:35:31 <gyee> bknudson, difference is dynamic versus static 18:35:40 <dolphm> bknudson: which is why i think i re-prioritized a high/critical bug by ayoung to a wishlist 18:35:43 <morganfainberg> bknudson, but i gave up on the argument. 18:36:42 <morganfainberg> gyee, i think the dynamic is really sloppy in this case, but it is what people are using and it works. - there are more important arguments to be had 18:36:56 <gyee> mapped is generic by nature 18:37:25 <morganfainberg> gyee, the argument is i want to use "password" but call it "CoolPassword" instead but not break people using "Password" 18:37:37 <morganfainberg> (bad example, but it's really waht people are asking for) 18:37:57 <morganfainberg> so instead of subclassing and making a new "CoolPassword" plugin, just use the plugin twice with a different name 18:38:35 <morganfainberg> same argument for anything that uses mapped, might be a different name, but mapped is the core plugin code 18:38:59 <gyee> there's only *one* plugin to handle a given auth payload 18:39:21 <morganfainberg> gyee, right but if you want to use the same plugin for different auth payloads 18:39:37 <morganfainberg> the plugin doesn't care, it's just handed a payload 18:39:43 <bknudson> we could use a fancy format like class:plugin_name 18:39:54 <dolphm> morganfainberg: are all your patches in the check queue? 18:40:02 <morganfainberg> dolphm, yes. 18:40:05 <bknudson> can I pass options to the plugin? 18:40:18 <morganfainberg> dolphm, the rest of non-persistent will be a Kilo target :( 18:40:42 <bknudson> btw - were we going to make UUID tokens the default? 18:40:50 <morganfainberg> dolphm, too many roadblocks fixing revocation events etc to land the refactor of issuance/validate 18:40:57 <dolphm> morganfainberg: understood. i'm going to keep the bp on the juno-3 list until what made FF is merged - plus those two tiny patches 18:41:06 <morganfainberg> bknudson, that was -2'd by ayoung. 18:41:46 <morganfainberg> bknudson, there is a lot of detail on the discussion on that front in the IRC logs and on that patch 18:41:57 <morganfainberg> dolphm, ++ 18:42:40 <dolphm> if you'd like to vote for/against changing the default token provider from PKI to UUID https://review.openstack.org/#/c/110488/ 18:43:10 <morganfainberg> oh on that topic 18:43:40 <morganfainberg> results to the survey on token provider usage 18:43:42 <morganfainberg> #link https://www.surveymonkey.com/results/SM-LX589JF8/ 18:44:07 <bknudson> 30% are able to use PKI. 18:44:32 <dolphm> morganfainberg: i wish you could correlate the comments with responses 18:44:43 <jamielennox> morganfainberg: do you need to sanitize the long form answers before publishing that 18:44:46 <morganfainberg> you can 18:44:46 <morganfainberg> https://www.surveymonkey.com/results/SM-LX589JF8/browse/ 18:45:00 <jamielennox> dolphm: click the 'individual responses' link 18:45:10 <morganfainberg> jamielennox, eh, i don't think so. 18:45:22 <bknudson> they use PKI for security? 18:45:23 <dolphm> jameiooh thanks 18:45:25 <dolphm> morganfainberg: thanks 18:45:35 <dolphm> bknudson: that's the one i was wondering about actually. 18:45:45 <dolphm> PKI provides a completely false sense of additional security 18:45:48 <gyee> PKI token doesn't offer any more security 18:46:02 <gyee> I thought the main argument was performance 18:46:09 <morganfainberg> gyee, arguably in grizzly it provided LESS security 18:46:14 <dolphm> gyee: that is true 18:46:20 <dolphm> gyee: pretty sure our docs say that as well 18:46:28 <dolphm> morganfainberg: in ...every... release 18:46:31 <morganfainberg> dolphm, but people like "OMG CRYPTO" 18:46:34 <dolphm> 3 so far 18:47:00 <gyee> dolphm, I am fine with default it back to UUID 18:47:11 <morganfainberg> this one: We have a black box appliance that act likes a WAF but it only understands UUID token 18:47:24 <gyee> morganfainberg, crypto != security 18:47:26 <morganfainberg> meaning... it probably only understands v2 uuid. 18:47:38 <dolphm> gyee: tell our users that :( 18:47:44 <morganfainberg> gyee, what dolphm said 18:47:55 <gyee> yeah, +2 18:48:19 <dolphm> it's sort of silly that our default option is historically unstable and less secure even after 3 releases (and about to be 4)... and still not a realistic option in production 18:48:24 <morganfainberg> this one is interesting: 18:48:26 <morganfainberg> 1) PKI token -- Not user friendly ( Too dificult to use with CURL) 18:48:26 <morganfainberg> 2) Horizon by default converts PKI to UDDI internally ( this will not work, if someone change default hashing algorithim) 18:48:26 <morganfainberg> 3) Revoke token logic is not that reliable. We don't have system bus to collect revocation event. It is easy to say, use event, but it is difficult to setup and manage that infrastructure just for revocation events 18:48:42 <morganfainberg> i think that sums up the general view on PKI 18:48:48 <morganfainberg> that i've heard 18:49:20 * morganfainberg wonders if that was gyee 's response >.> 18:49:21 <jamielennox> also we keep having needs to put more stuff in the token (or auth response) and it's just not going to work with PKI 18:49:33 <jamielennox> lots of problems in there for PKI header size 18:49:41 <dolphm> morganfainberg: ++ 18:49:46 <gyee> morganfainberg, 4) all of the above 18:49:52 <Haneef> I know for sure, it is not from gyee 18:49:57 <dolphm> gyee: that was all in one response lol 18:50:02 <morganfainberg> Haneef, haha ok :) 18:50:25 <dolphm> jamielennox: as much as i'd hate to agree with adding more stuff to the token... ++ 18:50:38 <morganfainberg> dolphm, i think we can make uuid tokens *way* better 18:50:50 <jamielennox> dolphm: well the 'adding more stuff to the token' issue is primarily only a problem because of PKI 18:50:51 <dolphm> morganfainberg: me too 18:51:16 <jamielennox> morganfainberg: ++ 18:51:30 <dolphm> jamielennox: it's also a problem for us when we try to parse apart the token, and there's always new attributes etc... i wish we could simplify all that 18:52:03 <bknudson> we need to figure out at the summit how to get tokens to work... it shouldn't be this difficult. 18:52:07 <jamielennox> dolphm: right but our lack of good token format that people abuse is not a problem about the size and 'official' content in there 18:52:47 <gyee> jamielennox, are you advocating xml token? :) 18:53:01 <morganfainberg> bknudson, i think we can make tokens better, and if we focus on making uuid tokens better we could also move towards signed requests instead of x-auth-token (long term) 18:53:25 <jamielennox> gyee: i think you can get a token response as XML with UUID ? 18:53:29 <morganfainberg> bknudson, i've floated some ideas on the token improvements, but i know some people are against it. 18:53:37 <dolphm> morganfainberg: so just switch to oauth? 18:53:47 <stevemar> open id connect :D 18:53:49 <dolphm> jamielennox: yes you can 18:54:02 <bknudson> it seems like we shouldn't be inventing something when there must be an existing solution. 18:54:22 <morganfainberg> bknudson, i actually was thinking the EC2 model is pretty nice. 18:54:46 <bknudson> morganfainberg: I looked at it a little bit and it looks better than what we've got. 18:54:52 <dolphm> morganfainberg: how is it different from oauth? 18:55:11 <dolphm> real ec2, not our shared secret hack 18:55:30 <morganfainberg> dolphm, keypair and HMAC sign your request, then the endpoint does some backend lookup for extra auth 18:55:32 <gyee> morganfainberg, ++ 18:55:57 <morganfainberg> dolphm, they use a distributed fast store that the endpoints can lookup the data from afaict 18:56:04 <gyee> xacml, yay 18:56:17 <dolphm> morganfainberg: i said "different" from oauth? 18:56:23 <morganfainberg> dolphm, LOL 18:56:28 <gyee> wait, endpoint policy is sorta like xacml 18:56:28 <morganfainberg> dolphm, well oauth1 sucks :P 18:56:37 <morganfainberg> dolphm, oauth2 is closer to that 18:56:46 <morganfainberg> dolphm, i was thinking different than *out* oauth 18:56:50 <morganfainberg> our* 18:57:13 <stevemar> dolphm, morganfainberg fwiw, cloud foundry uses oauth2 and openid connect for their authZ, authN ... https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-APIs.rst 18:57:18 <stevemar> just tossing that one out there 18:57:56 <jamielennox> that's the format of oauth requests, but given that we don't want all the delegation stuff why would we call it oauth2 18:58:00 <morganfainberg> part of our issue is the keystone internal idp isn't a full featured idp and a lot of people use it 18:58:03 <topol> um yeah, that does kind of work and seems so standard :-) 18:58:24 <bknudson> we can steal their rest api 18:58:25 <gyee> big corporate = standard 18:58:26 <morganfainberg> dolphm, 2min left 18:58:46 <topol> gyee, you STARTUP guy :-) 18:59:01 <morganfainberg> i think we should plan to do a "fix the tokens... no really" summit session 18:59:23 <topol> fix the tokens .. no really we mean it this time 18:59:28 * lbragstad plans to attend 18:59:50 <morganfainberg> and be willing to assume uuid and PKI are off the table. 18:59:59 <morganfainberg> in their current forms 19:00:03 <dolphm> pretty sure i just dropped for a bit - just switched from wifi to not 19:00:23 <morganfainberg> we're at time 19:00:47 <bknudson> thanks! 19:00:50 * dolphm REVIEWS PLZ! https://review.openstack.org/#/q/starredby:dolph+is:open,n,z 19:00:52 <dolphm> #endmeeting