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