18:01:54 <dolphm> #startmeeting keystone 18:01:54 <openstack> Meeting started Tue Oct 1 18:01:54 2013 UTC and is due to finish in 60 minutes. The chair is dolphm. 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:58 <openstack> The meeting name has been set to 'keystone' 18:02:16 <dolphm> #topic Re-opening for icehouse! 18:02:18 <dolphm> #link https://review.openstack.org/#/c/48971/ 18:02:28 <dolphm> everyone should read the commit message here ^ 18:02:47 <dolphm> after this change merges, master becomes icehouse 18:02:50 <bknudson> is there a release of python-keystoneclient, too? 18:03:16 <dolphm> bknudson: i've been holding off on v0.3.3 due to a couple little blockers, but i'd like to do a coincidental release 18:03:19 <topol> cool 18:03:23 <dolphm> bknudson: there's nothing 'havana' about the client though 18:03:29 <bknudson> would be nice to get https://bugs.launchpad.net/python-keystoneclient/+bug/1195924 one in keystoneclient 18:03:32 <uvirtbot> Launchpad bug 1195924 in python-keystoneclient "expiration check is using different timezone other than UTC" [Medium,In progress] 18:03:53 <dolphm> bknudson: targeted to v0.3.3 18:03:59 <dolphm> bknudson: i'll make sure we follow up 18:04:13 <bknudson> dolphm: thanks! 18:04:16 <jamielennox> morning... 18:05:04 <dolphm> as of a few minutes ago, our last RC blocker merged 18:05:07 <dolphm> #link https://launchpad.net/keystone/+milestone/havana-rc1 18:05:14 <dolphm> well done, everyone! 18:05:17 <morganfainberg> yay! 18:05:39 <topol> congratulations! 18:05:39 <dolphm> morganfainberg: thanks for your help kicking the gate over the weekend :) 18:06:06 <bknudson> the gate was kicking us badly 18:06:18 <dolphm> bknudson: yeah, transient failures have been *bad* this release, IMO 18:06:21 <morganfainberg> we got it done, thats the important part. 18:06:30 <dolphm> morganfainberg: ++ 18:06:38 <dolphm> also on the thank-you front... 18:06:40 <dolphm> #topic OpenStack Identity API Documentation Kudos 18:06:45 <ayoung> w00t~! 18:06:49 <dolphm> i think this was on the agenda last week, but i totally glossed over it 18:07:07 <dolphm> for everyone that has contributed to openstack identity-api, you have an open letter thank you on the mailing list :) 18:07:09 <dolphm> #link http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg04761.html 18:07:16 <bknudson> we need this otherwise everybody will keep using v2 18:07:29 <dolphm> bknudson: ++ 18:07:37 <dolphm> docs win users, hands down 18:08:15 <topol> dolphm:++ 18:08:15 <ayoung> I started this http://adam.younglogic.com/2013/09/keystone-v3-api-examples/ 18:08:24 <lbragstad> dolphm: ++ 18:08:44 <ayoung> and it was pretty much a straight lift off the Identity API docs. 18:08:47 <bknudson> http://api.openstack.org/api-ref-identity.html 18:08:47 <dolphm> ayoung: cool! i've gotten several requests for more curl-based examples 18:08:55 <morganfainberg> ayoung, awsome! 18:09:01 <dolphm> apparently those were quite popular with v2 18:09:24 <ayoung> dolphm, yeah, I've fielded a couple myself. I'd like to get a wider array out there. I'll take shardy's recent ones for trusts ,for example 18:09:31 <morganfainberg> dolphm, ++ i still use the V2 ones when testing things or explaining it to my coworkers 18:09:32 <bknudson> I don't know what some of these are... HP-IDM-serviceId Extended Parameter 18:09:48 <topol> ayoung I like how you updated it for how to handle the big PKI tokens using the variable. very helpful 18:10:00 <ayoung> topol, thanks 18:10:21 <topol> dolphm, curl examples are hugely helpful! 18:10:31 <dolphm> topol: ++ we need to advocate that approach (and probably revise old docs) 18:10:35 <bknudson> what happens to those extensions if we deprecate v2? 18:11:01 <ayoung> if you guys have any others, send them to me and I'll add them to the post, or link to yours. I assume that annegentle will eventually come ask to have them officially documented up 18:11:36 <bknudson> one problem with the existing docs is that they reference keystone CLI a lot. 18:12:14 <bknudson> http://docs.openstack.org/admin-guide-cloud/content/ch-identity-mgmt-config.html 18:12:22 <bknudson> keystone user-create --name=alice ... 18:12:30 <bknudson> so do we change those to openstack ? 18:12:35 <dolphm> bknudson: i'm hoping to advocate for a *strong* shift there in a few openstack-manuals sessions at the summit 18:12:42 <dolphm> bknudson: yes 18:13:02 <bknudson> I'm not sure that openstack is even "supported" yet 18:13:21 <dolphm> bknudson: the goal was to have it in end user's hands around havana's release 18:13:22 <annegentle> dolphm: bknudson: I'm not sure the openstack CLI belongs in official docs yet 18:13:23 <bknudson> as in, a promise of backwards-compatibilty 18:13:48 <bknudson> so we could put curl examples in the docs. 18:13:54 <annegentle> that said it'd be great to document one CLI 18:13:58 <dolphm> annegentle: i'm hoping the project will be where it needs to be do land in docs :) 18:14:06 <ayoung> since we are talking client...did everyone see jamielennox 's post this morning..he's been working on this for a while. \ 18:15:02 <bknudson> ayoung: link? 18:15:24 <ayoung> bknudson, ugh...I have it in email...one sec 18:15:36 <dolphm> (i'm going to move on in the mean time) 18:15:38 <dolphm> #topic Havana release notes 18:15:47 <dolphm> #link https://wiki.openstack.org/wiki/ReleaseNotes/Havana#OpenStack_Identity_.28Keystone.29 18:15:59 <dolphm> i took a stab a couple weeks ago at documenting the big stuff from havana 18:16:01 <morganfainberg> ugh. that got caught by my spam filter. 18:16:24 <dolphm> i left several blueprints linked taht should probably be documented but that i haven't gotten to, anyone is welcome to replace those with actual notes! 18:16:44 <dolphm> i'm not very good at spelling taht today 18:17:14 <ayoung> #link http://lists.openstack.org/pipermail/openstack-dev/2013-October/015839.html 18:17:21 <dolphm> i probably lied or typo'd about something in there, or forgot about your feature completely, so feel free to append, revise, etc 18:17:45 <lbragstad> dolphm: I can revise the unified logging link with a description 18:18:10 <dolphm> lbragstad: thanks! i wasn't sure how to document the deployer-facing impact of that 18:18:28 <jamielennox> dolphm: token binding is missing - i can do it 18:18:56 <ayoung> Endpoint filtering has come up a couple times today. I'll take a swing at that one 18:19:31 <ayoung> #action ayoung add release not for endpoint filtering 18:19:37 <ayoung> argh... 18:20:01 <dolphm> thanks all ^ 18:20:07 <dolphm> #topic python-keystoneclient 18:20:40 <dolphm> as mentioned earlier, there's a few bugs targeted at v0.3.3- 18:20:41 <dolphm> #link https://launchpad.net/python-keystoneclient/+milestone/0.3.3 18:21:05 <dolphm> i'd appreciate everyone's help to start reviewing those changes so we can get the client released asap 18:21:41 <dolphm> there's also been some weird bugs, including a transient failure in auth_token causing a few rechecks 18:21:50 <dolphm> #link https://bugs.launchpad.net/python-keystoneclient/+bug/1217734 18:21:52 <uvirtbot> Launchpad bug 1217734 in python-keystoneclient "FAIL: setUpClass (tempest.api.compute.servers.test_server_rescue.ServerRescueTestXML Unauthorized) " [High,New] 18:22:07 <dolphm> added to v0.3.3 so we can at least investigate it ^ 18:22:27 <dolphm> but that may be dependent on this- https://bugs.launchpad.net/python-keystoneclient/+bug/1112784 18:22:29 <uvirtbot> Launchpad bug 1112784 in python-keystoneclient "openssl cms error does not raise an exception or log the problem" [High,Triaged] 18:22:56 <jamielennox> damn, hadn't seen that one yet 18:24:09 <dolphm> #topic open discussion 18:24:34 <dolphm> as we rapidly head towards icehouse, there's also a bunch of bp implementations already in review (linked in meeting agenda) 18:24:34 <gyee> dolphm, can you add this one to keystoneclient 0.3.3 if possible? https://review.openstack.org/#/c/47661/ 18:24:37 <dolphm> https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:24:44 <dolphm> those will need attention 18:25:19 <dolphm> i'll also be taking a pass to unblock a bunch of -2'd reviews from feature freeze, as soon as we're open for icehouse 18:25:22 <jamielennox> gyee: i still don't think that is the right approach 18:25:45 <ayoung> dolphm, I can take https://bugs.launchpad.net/python-keystoneclient/+bug/1112784 18:25:48 <uvirtbot> Launchpad bug 1112784 in python-keystoneclient "openssl cms error does not raise an exception or log the problem" [High,Triaged] 18:26:18 <jamielennox> i'm not sure how to do it better without a fairly significant refactor, but it seems wrong to need another config option for that 18:27:05 <gyee> jamielennox, what refactoring you have in mind? 18:27:29 <jamielennox> gyee: many things, but mainly just don't request a token until you need a token 18:27:46 <ayoung> gyee, shouldn't admin_token be an additional auth method under keystone/auth/plugins and so it can be removed from the list? 18:27:53 <jamielennox> unfortunately we need a token for fetching revocation lists so both PKI and UUID tokens still require an admin token 18:28:25 <gyee> I am just making admin_token request optional 18:28:27 <ayoung> jamielennox, well, no 18:28:35 <ayoung> jamielennox, that can be done with RBAC, too 18:28:41 <ayoung> and probably should be done with RBAC 18:29:02 <ayoung> the token needs to grant admin privs, but that is different from an ADMIN_TOKEN config option 18:29:17 <gyee> its not even an admin token per say 18:29:18 <jamielennox> ayoung: but nobody is doing it with RBAC because that's not how we tell people to set it up 18:29:31 <ayoung> gyee, why is the current option of removing it from the config file not sufficient? 18:29:32 <dolphm> gyee: (i don't really want to block a point release on a new feature unless it's actually causing a blocker for another project) 18:29:33 <gyee> token which have the roles to validate another token 18:30:08 <gyee> dolphm, 0.3.4 then? 18:30:13 <ayoung> gyee, I think we can do what you are describing there within the existing mechanisms. 18:30:20 <dolphm> gyee: features are done when they're done :) 18:30:35 <dolphm> gyee: if it was merged, i'd be happy to do a release to get it out there 18:30:46 <gyee> dolphm, k, that's fine 18:31:13 <ayoung> jamielennox, so education of the user base is a big topic. So far, we've identified that devstack is the first step....maybe we should BP up a bettter RBAC setup for that. Does devstack use the cloud policy file yet? 18:31:26 <dolphm> this one is essentially a wishlist item that's a blocker for heat https://review.openstack.org/#/c/48462/ 18:31:33 <gyee> ayoung, how do I use existing mechanism to skip admin token? 18:31:55 <jamielennox> ayoung: i'm pretty sure they have admin service users 18:32:04 <jamielennox> as devstack is all v2 18:32:20 <topol> gyee++ I would love to know that as well. is that in an ayoung blog somewhere? 18:32:29 <gyee> technically, token validation token 18:32:31 <dolphm> gyee: using a known token and endpoint? 18:32:39 <jamielennox> gyee: you can't, i think he meant to request a non-admin token you just change user/pass 18:32:45 <ayoung> gyee, you need to have a Role, and that role needs to be used in the policy file in keystone. 18:32:59 <ayoung> the Nova user, instead of using an admin token, can use a regular token 18:33:10 <gyee> dolphm, that's my alternative, essentially putting a dummy token in there 18:33:21 <dolphm> gyee: dummy? 18:33:30 <gyee> yes 18:33:46 <dolphm> gyee: which would raise 401 from keystone? 18:33:52 <gyee> we use SSL certificate auth instead of admin token 18:33:59 <jamielennox> gyee: given that you need a validation token for revocation lists how is it going to work 18:34:09 <jamielennox> ah, right 18:34:13 <gyee> jamielennox, we use 2 way SSL 18:34:24 <dolphm> gyee: why not just configure admin_token with a artificially long-lived token? 18:34:26 <gyee> Apache then translate it into a service user context 18:34:47 <gyee> dolphm, our security call for service account rotation 18:34:59 <jamielennox> gyee: that's cool, i would love to get that into keystone proper 18:35:02 <gyee> we need to rotate the certs 18:35:03 <ayoung> gyee, so, really you want a way to tell auth_token to use SSL client cert. Now, that I can get get behind 18:35:06 <gyee> no hardcode passwords 18:35:31 <gyee> ayoung,, absolutely 18:35:41 <gyee> we are not allowed to have passwords in conf files 18:35:48 <ayoung> gyee, but...why not Client cert to get admin token, and then use token binding? 18:35:51 <dolphm> gyee: right, i mean underneath ssl 18:35:59 <ayoung> :) 18:36:07 <jamielennox> gyee: so is storing some fake data in AUTH_TOKEN a problem or just an inconvenience? 18:36:10 <gyee> ayoung, that's precisely what we are doing 18:36:16 <gyee> trade in ssl cert for a token 18:36:21 <gyee> at the server side 18:36:57 <gyee> I just need a way to turn off admin_token request at the middleware 18:36:59 <ayoung> gyee OK, I see what you are getting at... 18:37:27 <topol> gyee, ayoung, what you are describing sounds like an interesting pattern. Is this a to be statement to be written up in a blueprint? 18:37:39 <ayoung> gyee, but your code doesn't look right 18:37:54 <ayoung> topol, well, bascially, this is the problem that jamielennox was addressing in the client work 18:38:07 <ayoung> we need to make a client library that supports multiple auth methods 18:38:15 <gyee> ayoung, ++ 18:38:16 <ayoung> and we need to make auth_token, and the CLIs, both use that library 18:38:27 <jamielennox> ayoung: ++++++++++++ 18:38:28 <gyee> but a the meantime, I need something to turn off admin token request 18:38:37 <nachi1> ayoungL +1 18:38:38 <topol> ayoung, is there a blueprint for jamielennox work on this? 18:38:48 <gyee> we can remote that change once we have plugin support in keystoneclient 18:38:50 <ayoung> topol, multiple 18:38:53 <jamielennox> topol: there has been a few 18:39:00 <gyee> baby steps :) 18:39:10 <ayoung> gyee, why do you only support password? 18:39:24 <topol> jamielennox can you send me some pointers to the blueprints? 18:39:26 <jamielennox> the post that was mentioned earlier is describing the APIClient stuff - and at the moment i'm making everything hinge upon that 18:39:59 <ayoung> #link http://lists.openstack.org/pipermail/openstack-dev/2013-October/015839.html 18:40:06 <ayoung> to link it yet again 18:40:58 <jamielennox> topol: most aren't overly fleshed out, just areas or work at the moment: 18:40:59 <gyee> ayoung, what do you mean we only support password? 18:41:03 <jamielennox> topol: https://blueprints.launchpad.net/python-keystoneclient/+spec/consolidate-cli-auth 18:41:03 <ayoung> https://blueprints.launchpad.net/keystone/+spec/kerberos-authentication 18:41:11 <topol> thanks 18:41:16 <jamielennox> https://blueprints.launchpad.net/python-keystoneclient/+spec/auth-plugins 18:41:17 <ayoung> gyee, either the method is password or you raise an exception 18:41:30 <gyee> ayoung, just for now, we can expand it 18:41:34 <jamielennox> https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-auth-token 18:41:34 <ayoung> https://review.openstack.org/#/c/47661/3/keystoneclient/middleware/auth_token.py line 734 18:41:34 <gyee> see the code comment 18:41:57 <gyee> I am just paving a way for pluggable auth 18:42:04 <gyee> password is just a start 18:42:16 <ayoung> gyee, that is useless. I don't see how it serves your need, as you will still need custom code to fetch a cert. Make the code support the X509 use case and It will make a lot more sense. 18:42:21 <jamielennox> but pretty much every blueprint i've filed under keystoneclient (like version discovery) came from this problem 18:42:38 <gyee> code already support x.509 18:42:43 <gyee> you can configure SSL today 18:43:04 <jamielennox> client side SSL in auth_token? 18:43:10 <bknudson> gyee: you can tell auth_token to use a client cert? 18:43:11 <ayoung> gyee, I can't see that from the patch you submitted 18:43:14 <gyee> jamielennox, yes 18:43:21 <jamielennox> gyee: huh, didn't know that 18:43:22 <gyee> bknudson, yes 18:43:30 <bknudson> ok, interesting 18:43:32 <gyee> requests lib supports 2-way ssl 18:43:41 <ayoung> gyee, it sounds like, at a minimum, you need "none" or "no password" 18:44:19 <gyee> ayoung, if it makes sure a happier man, I can change it to a boolean, need_admin_token or something 18:44:29 <gyee> s/sure/you/ 18:44:31 <ayoung> gyee, with your patch, what would I set admin_token_auth_method to? 18:44:54 <ayoung> None? Ah..oh yuck 18:45:12 <gyee> ayoung, set it to an empty string to skip admin token request 18:45:19 <ayoung> ok...I see what you are doing...um...don't like the illusion of plugability there 18:45:41 <morganfainberg> boolean enable_auth_token 18:45:45 <gyee> I can change it to a boolean 18:45:47 <ayoung> gyee, but...that code never requests a token, then, right? 18:45:47 <bknudson> make it pluggable 18:45:48 <morganfainberg> erm enable_admin_token 18:45:51 <topol> "illusion of pluggability" :-) nice 18:45:56 <morganfainberg> make it pluggable in the future? 18:46:05 <gyee> that's what I was aiming for 18:46:10 <gyee> pluggable in the future 18:46:17 <jamielennox> gyee: so my main concern is having to support the config option over time, not that it is a hack - most of auth_token is a hack 18:46:21 <morganfainberg> depends on the timeline(s) we are talking about if it should be boolean or string 18:46:25 <gyee> at least the illusion of pluggable :) 18:46:32 <bknudson> but a plugin would be a module reference 18:46:39 <ayoung> gyee, what you should be saying is user REOMTE_USER to fetc h an admin token 18:46:39 <jamielennox> if i can get keystoneclient into auth_token i'm not sure how to deal with the config option 18:46:47 <morganfainberg> bknudson, aye, 18:46:48 <bknudson> keystoneclient.auth_token.password 18:46:56 <ayoung> I don't think that what you have there is supported without custom plugins on the Keystone side, is it? 18:47:06 <gyee> ayoung, no need to even fetch admin_token, its all done at the server side 18:47:07 <dolphm> jamielennox: ++ 18:47:22 <gyee> trade in client cert for admin token 18:47:23 <ayoung> gyee, I suspect you have custom code on the server side 18:47:34 <gyee> ayoung, yes, custom middleware 18:47:36 <ayoung> we don't allow admin calls without a token 18:47:41 <ayoung> gyee, BUSTED! 18:48:01 <gyee> guilty 18:48:15 <ayoung> gyee, um, yeah, I'm going to have to disagree with you there Bob 18:48:16 <dolphm> (havana->icehouse version bump is 6th in the gate! only about an hour left until it fails and we have to try again.) 18:48:41 <gyee> ayoung, what's the problem? 18:48:42 <ayoung> gyee, OTOH, I would love to see that custom middleware submitted as a contrib 18:48:46 <morganfainberg> dolphm, so optimistic 18:48:53 <gyee> ayoung, yes 18:48:54 <ayoung> gyee, you submitted code that only you can use 18:48:55 <dolphm> morganfainberg: hey, we have experience at this 18:49:08 <morganfainberg> dolphm, i didn't say unrealistic did i? :P 18:49:10 <dolphm> morganfainberg: p.s. i also wrote a tool called watch-review lol 18:49:11 * topol loving the office space reference 18:49:41 <ayoung> gyee, OTOH, I am headed in the same direction...I would love it if Keystone didn't need a token for operations, but instead used standard Web Auth methods for things that currently can be done unscoped...so 18:50:12 <ayoung> https://github.com/admiyo/keystone/commit/05d68559b548c6722a1d928e13919fe74ba5e13f 18:50:24 <topol> ayoung, ++ is there time at the summit to discuss? 18:50:40 <gyee> ayoung, sure, filter is pretty easy, just map the client ssl cert to a service admin account 18:50:41 <ayoung> that patch fetches a token based on basic-auth and stores it in a cookie. We want the same kind of thing from SSL Client cert auth 18:50:54 <jamielennox> gyee: so your middleware is doing what: taking client cert serial or hash and converting to a token header? 18:51:06 <gyee> jamielennox, precisely 18:51:26 <jamielennox> hacky, but a nice one 18:51:54 <ayoung> jamielennox, not hacky...it is how would should have done Keystone from the start. Using the standards as opposed to inventing our own. Sportsmanlike 18:52:08 <gyee> hey, works for me 18:52:13 <jamielennox> mmm, it's hacky having it used as a token 18:52:18 <topol> ayoung++!!! 18:52:23 <jamielennox> but a nice idea 18:52:43 <bknudson> the cert could be the token 18:52:52 <gyee> bknudson, yes 18:53:14 <jamielennox> bknudson: yes, and on the list for Icehouse was a client cert auth method 18:53:17 <ayoung> jamielennox, not really. The problem is the term toekn. A token is really a general purpose term. Our tokens are "remote references to authentication objects" 18:53:18 <gyee> bknudson, that how CERN is doing with their federation right? 18:53:24 <gyee> trade in SSL cert for token 18:53:25 <ayoung> and from that perspective, it makes a lot of sense. 18:53:43 <jamielennox> i'm just wondering if it's possible to ditch the token completely with client certs and i dont think so 18:53:46 <ayoung> gyee, and bind the token to the SSL cert 18:53:52 <gyee> ayoung, sure 18:54:00 <ayoung> jamielennox, no, they serve different purposes. 18:54:13 <ayoung> Client cert is "who are you" token is "what are you doing in my living room?" 18:54:37 <gyee> ayoung, so can we get that patch going now? 18:55:08 <jamielennox> ayoung: got that, but if you use client cert serial number, you're essentially using a UUID token 18:55:40 <bknudson> auth_token could send client cert to keystone token and get back roles 18:55:50 <bknudson> keystone token verify 18:56:06 <gyee> bknudson, yes, it would be one of the REMOTE_USER auth 18:56:07 <bknudson> like a UUID token 18:56:16 <jamielennox> bknudson: you can't forward a client cert, but you can forward the details like a UUID token 18:56:24 <gyee> REMOTE_USER allows you to map anything into a token 18:56:28 <gyee> we support that today 18:56:53 <bknudson> jamielennox: right, should have said client cert serial or DN or whatever. 18:56:57 <ayoung> gyee, and that is what your patch should specify 18:57:12 <Haneef> -Before going with client cert, we need to come up with supported platforms. Client cert header names are not same across all servers. Also it will vary depending on wheter u are offloading ssl in loadbalancer or it is configured as ssl brdige? 18:57:28 <jamielennox> gyee: my problem is that we are going to want to deprecate this config option relatively quickly 18:57:33 <ayoung> admin_token_auth_methods is in ['password','external'] 18:57:46 <gyee> ayoung, sure, I am down with that 18:58:08 <gyee> wait, external? 18:58:26 <jamielennox> ayoung: ? 18:58:29 <ayoung> gyee, the thing is, that could be used with the existing auth, doesn't need custom middleware. It will still cost you an additional round-trip unless you cache the returned token 18:58:30 <gyee> jamielennox, we are constantly refactoring anyway :) 18:58:43 <jamielennox> gyee: sure, but a config option has to be supported long term 18:58:45 <ayoung> gyee, I think that was what it was called inteh keystone/auth/controller.py 18:58:54 <gyee> didn't dolphm say disposable code? :) 18:59:18 <jamielennox> ayoung: external is not a thing in keystoneclient 18:59:20 <ayoung> gyee, https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L334 18:59:31 <dolphm> gyee: disposable implementations still need to maintain compatibility :) 18:59:34 <dolphm> #endmeeting