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