18:00:32 <heckj> #startmeeting
18:00:33 <openstack> Meeting started Tue Jun 19 18:00:32 2012 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:46 <heckj> who's here?
18:00:49 <heckj> o/
18:00:55 <ayoung> o/
18:00:55 <rafaduran> o/
18:01:10 <dolphm> o/
18:01:16 <heckj> rafaduran - did you have some bugs you wanted to review today?
18:01:30 <rafaduran> yes, a couple of them
18:01:49 <heckj> Perfect - let's hit them at the top today.
18:01:52 <heckj> #topic hot issues
18:01:59 <rafaduran> #link https://bugs.launchpad.net/keystone/+bug/1012381
18:02:00 <heckj> rafaduran - have at
18:02:00 <uvirtbot> Launchpad bug 1012381 in keystone "Memcache token backend eventually stops working" [High,Triaged]
18:02:13 <rafaduran> #link https://bugs.launchpad.net/keystone/+bug/1012326
18:02:15 <uvirtbot> Launchpad bug 1012326 in keystone "Deleting service tenant breaks 'auth_token' middleware " [High,Triaged]
18:02:43 <rafaduran> As you can read I've got new bugs that can break the whole stack
18:03:06 <rafaduran> One breaks the memcache token backend and the ohter tue auth_token middleware
18:03:36 <heckj> deleting the service 'tenant' is expected to break auth_token, as the services won't be able to validate tokens. What do you suggest there? (bug 1012326)
18:03:37 <uvirtbot> Launchpad bug 1012326 in keystone "Deleting service tenant breaks 'auth_token' middleware " [High,Triaged] https://launchpad.net/bugs/1012326
18:04:05 <dolphm> I think the second one can be filed under "Doctor, it hurts when I poke myself in the eye."
18:04:39 <rafaduran> heckj: I'm no really sure how consider that, since can break the whole stack, but, so far, i could reproduce it only after deleting service tenant
18:04:42 <ayoung> dolphm, should we issue eye-guards?
18:04:46 <heckj> dolphm: ++
18:05:29 <ayoung> ie.  prevent the deletion of certain protected entities like that one?
18:05:36 <rafaduran> anyway, we might want check the error message and see if the error is anything but a token not found and discard the the service token in that case
18:05:39 <heckj> ayoung: I think it's potentially worth including in a deployment doc, but I'm hesitant to encode something more in the implementation that is a guard against a specific deployment mechanism
18:08:10 <ayoung> anything else on that?
18:08:33 <heckj> rafaduran - your other one looks like a nasty issue from a glance at it, but I'll need to dig further to have any sense. Do you have a recommendation on a fix? (bug 1012381)
18:08:34 <uvirtbot> Launchpad bug 1012381 in keystone "Memcache token backend eventually stops working" [High,Triaged] https://launchpad.net/bugs/1012381
18:09:12 <rafaduran> heckj: that bug can be fixed just monkey patching thread
18:09:22 <rafaduran> as nova does
18:09:39 <heckj> rafaduran - excellent. Thank you.
18:09:49 <heckj> rafaduran - are you going to submit a patch for that?
18:10:18 <rafaduran> I plan to do thtat, but I don't know if there is a good reason to not being  already monkey patching it
18:10:46 <termie> o/
18:11:25 <heckj> rafaduran - not that I'm aware of - I'll assign the bug to you, please patch it in!
18:11:31 <heckj> ola termie!
18:11:36 <rafaduran> heckj: ok
18:11:56 <heckj> Any other new/hot issues?
18:12:10 <ayoung> I have one.
18:12:18 <ayoung> https://review.openstack.org/#/c/7754/
18:12:28 <ayoung> Signed tokens is posted for review
18:12:35 <termie> ayoung: yeah i saw :)
18:12:48 <ayoung> Jenkins is showing an error on each test,  which lead to my question about openssl.
18:12:57 <ayoung> Unit tests run 100% on my machine
18:13:04 <heckj> #link https://review.openstack.org/#/c/7754/ <-- reviews please
18:13:23 <ayoung> the variations between Ubuntu and Fedora for openssl are less than a mino0r version number apart
18:13:23 <heckj> ayoung: just got a poke from mtaylor that openssl *is* installed on the jenkins hosts
18:13:40 <mtaylor> yeah. just verified by hand
18:13:55 <heckj> ayoung: I'll give it a shot under ubuntu and see if I can spot what's gone awry
18:14:03 <ayoung> hmm...not getting enough info from the error log to diagnose the problem
18:14:10 <ayoung> heckj, thanks
18:14:14 <heckj> np
18:14:54 <ayoung> BTW  Kudons on the unit tests for Keystone. This would not have been possible if they were not so thorough
18:15:03 <ayoung> Kudons are very big Kudos
18:15:29 <heckj> heh
18:15:49 <heckj> Okay - next topic
18:15:53 <heckj> #topic V3 API
18:16:01 <heckj> draft 2 is available - posted to the list this weekend
18:16:12 <heckj> #link https://docs.google.com/document/d/1_TkawQIa52eSBfS4pv_nx1SJeoBghIlGVZsRJJynKAM/edit
18:16:21 <ayoung> heckj, for Signed tokens,  I added two minor APIs.  I wonder if they should go in that doc?
18:16:23 <heckj> Have some good feedback from gabriel hurley in there now
18:16:32 <ayoung> one is for fetching the CA,  the othter for fetching the signing cert
18:16:32 <dolphm> With lots of little updates this morning
18:16:57 <heckj> ayoung - yes, please. I'd like to incorporate them. Can you email me a a description of the APIs you added and relevant details?
18:17:04 <ayoung> heckj, will do
18:18:17 <rafaduran> heckj: looking at draft2 it seems you are not considering moving querying to something like /{resuource}/search?whatever, aren' t you?
18:18:21 <heckj> termie: since you're here, I had a largish question re: the policy pieces: what do you think about sticking with just basic CRUD for that file in the CORE, and enabling anything additional (such as dolph is suggesting) as an extension at this point?
18:18:51 <heckj> rafaduran: I'm leaning far away from that and instead focusing on trying to keep it to query parameters to "plural" resources
18:19:41 <dolphm> heckj: I'm down with that, btw
18:20:10 <dolphm> /policy is an easier deliverable
18:20:25 <heckj> dolphm: yeah - significantly easier I think
18:20:58 <heckj> I haven't' dug up the details of how the whole "/version" resource/API thing works in previous versions yet.
18:21:37 <rafaduran> heckj: I would like as separate path because searching capablilites depend on the backend and thus it might be useful being disabled for some backends (the same as CRUD)
18:21:40 <heckj> I've never quite groked the whole extensions mechanism I'm afraid - just need to dig in and try to understand it. It's left me more confused than anything in using the APIs so far
18:22:36 <heckj> rafauran: for all of the API calls, returning a 501 NotImplemented is a possible result. I don't see how making it a separate URI path makes that easier.
18:22:41 <heckj> rafaduran: ^^
18:23:25 <rafaduran> hekj: keeping it into an extension thant can disable at configuration file
18:23:46 <heckj> rafaduran: I'm totally for the internal python API being reasonably separated out per back-end, but I'd prefer to have the resource URIs for the REST interface be as consistent as possible
18:25:12 <heckj> rafaduran: that's the point. I want to see these as defined in a core API, not as an extension. Having a back-end that refuses to implement portions of the CORE api is acceptable - hence the 501 NotImplemented.
18:26:06 <rafaduran> heckj: if we want support complex queries everything can get messy, but it's just my opinion
18:26:43 <heckj> rafaduran: agreed, these are for simple filtering based on feedback I got from the horizon team and a couple other folks trying to do UI for this
18:27:32 <heckj> rafaduran: more complex query/search is quite possible under a different URI with an extension - nothing is stopping that. I didn't have clear use cases on those situations though, so I haven't tried to include that in this API release
18:27:39 <heckj> anything else on the APIs?
18:27:54 <rafaduran> heckj: ok simple filtering shouldn't be an issue, a if someone need something more complex, can add its own extension
18:28:29 <heckj> #topic Folsom-2 milestone
18:28:35 <heckj> milestone is in two weeks
18:28:48 <heckj> I've been updating a few of the blueprints and such to match what I'm seeing on progress
18:28:50 <heckj> #link https://launchpad.net/keystone/+milestone/folsom-2
18:29:09 <heckj> Anyone seen or heard from everett toewes re: having quota data in Keystone?
18:30:05 <heckj> dolphm_: what's your intended outcome from https://blueprints.launchpad.net/keystone/+spec/rbac-keystone?
18:30:42 <heckj> I just added https://blueprints.launchpad.net/keystone/+spec/rbac-keystone-api to cover implementing policy and such in keystone itself
18:30:50 <heckj> #link https://blueprints.launchpad.net/keystone/+spec/rbac-keystone-api
18:31:02 <dolphm_> heckj: my goal was to have an implementation in review, but i suppose having rbac solidified in v3 is the real goal
18:31:44 <heckj> dolphm_: wasn't sure how to represent the progress on it for the project. There's two related things that I was confusing
18:32:04 <heckj> 1) implementing a policy.json and relevant pieces within keystone instead of the current isAdmin() checks and
18:32:09 <dolphm_> heckj: if we go with /policy, then the service implementation is easy, and the only slightly tricky part is delivering the policy through middleware to the underlying service
18:32:40 <heckj> 2) consolidating the various policy.json files and suggestions for a deployment set of roles for an implementation
18:32:52 <dolphm_> heckj: i wouldn't be addressing keystone consuming it's own rbac, at least within this blueprint
18:33:40 <heckj> dolphm_: cool - I'll update the blueprint and kick it to Folsom-3 if that's OK with you. I'd like to get the API consensus wrapped up by the middle of next week to begin implementation, but that leaves almost no time to implement.
18:33:57 <ayoung> can we please get    https://review.openstack.org/#/c/8233/  in? It will really speed up the unit test runs.
18:34:27 <dolphm_> heckj: side note -- i wanted to throw default tenancy on the agenda for today -- we have two different understandings/implementations floating around
18:34:36 <dolphm_> heckj: sure
18:34:41 <heckj> kk -
18:34:42 <dolphm_> heckj: agree
18:34:47 <heckj> #topic open discussion.
18:34:49 <liemmn> heckj:  I can help with defining the policy for keystone... since I think that will help me answer some questions as to who can do what in Keystone...  (domain admin, super admin, etc...)
18:34:51 <heckj> dolphm_: take it away
18:35:05 <liemmn> Is that under the bp you created?
18:35:06 <heckj> liemmn: Ok - I'll make a blueprint and assign to you if that's acceptable
18:35:17 <dolphm_> so, i believe the implementation for default tenancy changed between legacy and redux
18:35:19 <liemmn> sure... I can take a stab at it :)
18:35:33 <dolphm_> in legacy, default tenancy was enforced in the keystone server during the authentication call
18:36:07 <dolphm_> if the user had a default tenant id, but did not specify a tenant during auth, that tenant was added to the token and included in the response
18:36:16 <dolphm_> keystone doesn't do that anymore
18:36:42 <dolphm_> as of today, the service appears to have no awareness of "auto-scoping" or whatever we call it
18:37:22 <heckj> @liemmn: https://blueprints.launchpad.net/keystone/+spec/document-deployment-suggestions-policy
18:37:31 <dolphm_> instead, the behavior is assumed by auth_token ... because several tenant ID's *could* be returned in an authentication response, auth_token looks through them in a priority order (starting with the token) and eventually falls back on the user's tenant
18:37:32 <liemmn> thanks, heckj
18:38:02 <dolphm_> the first tenant ID found is what is passed down to the underlying service by auth_token via the X-Tenant-Id and X-Tenant-Name headers
18:38:11 <dolphm_> first tenant id/name *
18:39:24 <dolphm_> so, A) anyone know if I'm just insane?, B) is this change an issue for anyone? i'm not clear on whether it was an intentional shift or not
18:39:45 <dolphm_> termie: ^^
18:41:55 <dolphm_> i think auth_token's behavior is fine, as it's really intended to handle the various historical keystone authentication responses (pre-diablo, diablo, essex, etc), so i'm more concerned about the intended public api behavior
18:42:42 <heckj> dolphm_: My sense is the following:
18:42:58 <ayoung> define "first"
18:42:58 <heckj> 1) tenant_id on a user object is a suggestion (optional) of a default tenant
18:43:13 <dolphm_> ayoung: first?
18:43:26 <heckj> 2) when it's available, it can be used as a default - primarily for the use case of username+password request for a token
18:43:27 <ayoung> "the first tenant ID found is what is passed down "
18:43:45 <ayoung> LDAP doesn't guarantee order,  so I might need to put something in there to deal with it
18:44:07 <heckj> If tenant_id isn't defined on a user, an auth using just user+pass should fail.
18:44:28 <dolphm_> ayoung: ah, 2 sec, i'll link to the impl to explain
18:44:55 <dolphm_> ayoung: https://github.com/openstack/keystone/blob/master/keystone/middleware/auth_token.py#L411
18:45:43 <dolphm_> ayoung: you can see how it iterates through each potential response format until one doesn't raise a KeyError, that's the "first" one found, and therefore what is passed down through the wsgi env
18:46:11 <dolphm_> heckj: you just described the current behavior, FWIW
18:46:18 <dolphm_> heckj: mostly implemented by auth_token
18:46:20 <heckj> dolphm_: yeah!! :-)
18:46:42 <heckj> dolphm_: would you prefer a different mechanism?
18:46:49 <ayoung> OK,  that should be fine by LDAP
18:47:03 <dolphm_> heckj: not necessarily, i just want to make sure we're all on the same page (i sure wasn't!)
18:47:40 <heckj> dolphm_: cool
18:47:42 <dolphm_> i'm also curious sure if this "new" behavior is incompatible with the legacy behavior, *from a client's perspective*
18:47:56 <ayoung> are we deprecating diablo functionality in the future?
18:47:57 <dolphm_> or is somehow different from a security perspective
18:48:27 <heckj> dolphm_: dunno - the only client usage I have direct feedback on is the horizon team, who are all lurking around me, ready to pounce.
18:48:38 <dolphm_> ayoung: that's a big question :)
18:48:45 <dolphm_> heckj: lol
18:50:07 <heckj> ayoung: I was expecting to support diablo responses through Folsom release - beyond that I'm happy to deprecate.
18:50:28 <dolphm_> heckj: another topic... in the v3 draft, you have the "User" entity described as having a "name" attribute, but through most of the API it appears you call that attribute "username" instead
18:50:41 <ayoung> can we tag them as deprecated now with the goal of removing them in Gollum
18:50:45 <heckj> dolphm_: my fuckup - that was supposed to be description
18:50:46 <dolphm_> heckj: in v2, the only place "username" is used is during auth ("username" + "password")
18:50:57 <dolphm_> heckj: can i change them to name + description throughout?
18:51:04 <heckj> dolphm_: yes, please
18:51:11 <dolphm_> heckj: np
18:51:27 <heckj> ayoung: I'm fine with that - not quite sure *how* we mark API or responses as deprecated
18:51:40 <heckj> ^^ anyone know appropriate mechanics for the APIs in OpenStack
18:51:40 <uvirtbot> heckj: Error: "^" is not a valid command.
18:51:43 <ayoung> #action figure out how to deprecate
18:51:43 <dolphm_> heckj: that's in the multiple choice response, actually
18:52:08 <dolphm_> heckj: each version has a "status" attribute which could return things like "alpha", "beta", "stable", or "deprecated"
18:52:21 <dolphm_> heckj: i think the possible responses are defined in the versions.xsd
18:52:22 <heckj> all I had to do is learn the versions API eh?
18:52:27 * heckj is shamed into learning that stuff
18:52:29 <dolphm_> heckj: ;)
18:54:38 <ayoung> #action tag diablo specific attributes as deprecated
18:54:49 <ayoung> Not sure if I am allwoed to #action or not
18:55:06 <dolphm_> #action heckj re-action previous action
18:55:07 <heckj> ayoung:go forward with it
18:55:21 <heckj> #action tag diablo specific attributes as deprecated
18:55:28 <heckj> tada!
18:55:49 <liemmn> Another topic on the api...  I am thinking to fold the access key admin api into the credentials api (after all, it is just another user credentials)...  What do you guys think?
18:55:51 <liemmn> https://blueprints.launchpad.net/keystone/+spec/access-key-authentication
18:56:14 <dolphm_> liemmn: sounds good to me :)
18:56:15 <liemmn> so, we will have a type called "access-key" or something like that
18:56:20 <dolphm_> liemmn: if it fits that's awesome
18:56:21 <ayoung> liemmn, I like that approach
18:56:28 <heckj> liemmn: sounds excellent - tried to bring in your feedback on draft1 to enable it
18:56:35 <heckj> liemmn: anything still missing to enable?
18:56:35 <dolphm_> if it doesn't fit, credentials api is broken
18:57:04 <liemmn> cool... I added some feedbacks on draft#2 in the credentials api to support access keys too (all optional attributes of course :) )
18:57:35 <ayoung> Of course,  there is something wrong with posting the Secret keys across the wire,  but that is a detail we can argue about later
18:58:50 <liemmn> ayoung:  You're talking about the auth part?  Not sure if there is value in that...
18:59:21 <liemmn> IMHO, we should be using signature auth, not token auth with secret keys :)
18:59:38 <ayoung> who am I to argue with that?
19:00:57 <ayoung> dolphm_, can you reapprove https://review.openstack.org/#/c/8233/  as it speeds up running the whole body of unit tests.  Pretty much any SQL based test runs faster,  the suite goes from 10 minutes down to 3 or something....
19:01:13 <heckj> Opps - lost track of time
19:01:18 <heckj> wrapping this up
19:01:21 <heckj> #endmeeting