18:01:22 <ayoung> #startmeeting keystone 18:01:23 <openstack> Meeting started Tue Mar 12 18:01:22 2013 UTC. The chair is ayoung. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:26 <openstack> The meeting name has been set to 'keystone' 18:01:52 <ayoung> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:02:39 <ayoung> #topic High priority bugs or immediate issues? 18:02:56 <ayoung> 3 bugs marked critical 18:03:16 <ayoung> https://bugs.launchpad.net/keystone/+bug/1152801 18:03:19 <uvirtbot`> Launchpad bug 1152801 in keystone "V3 tokens do not show up in list_tokens_for_trust" [Critical,In progress] 18:03:35 <ayoung> https://bugs.launchpad.net/keystone/+bug/1131087 18:03:37 <uvirtbot`> Launchpad bug 1131087 in keystone "Roles lost in Folsom to Grizzly upgrade" [Critical,In progress] 18:03:45 <ayoung> As well as one with fix committed 18:04:09 <ayoung> Of course, both fixes step on each other for the 020 sql upgrade script 18:04:29 <henrynash> ayoung: anything we can do to help get these done? 18:04:30 <ayoung> I'm willing to rebase the Roles one if people are willing to ACK the trust one 18:04:55 <ayoung> https://review.openstack.org/#/c/24010/ 18:05:03 <ayoung> henrynash, ^^ is the fix for the trusts one 18:05:32 <ayoung> so, reviews needed there 18:05:58 <henrynash> ayoung: I'll give it a quick once over, but I was pretty fine on it last time round... 18:06:03 <ayoung> https://review.openstack.org/#/c/23979/ needs unit tests 18:07:22 <ayoung> anyone have anything else that needs review now? 18:07:57 <ayoung> We have a few out for Folsom stable that are important to us for an internal deadline, which I would like people to look at as well. 18:08:05 <ayoung> https://review.openstack.org/#/c/24079/ 18:08:08 <henrynash> ayoung: I am writing tests for : https://review.openstack.org/#/c/24078/ 18:08:13 <ayoung> https://review.openstack.org/#/c/23996/ 18:08:28 <ayoung> and https://review.openstack.org/#/c/23842/ 18:08:37 <ayoung> but those will require outside intervention as well 18:09:23 <ayoung> henrynash, please make sure that all those calls are using the delete token function from https://bugs.launchpad.net/keystone/+bug/1152801 18:09:25 <uvirtbot`> Launchpad bug 1152801 in keystone "V3 tokens do not show up in list_tokens_for_trust" [Critical,In progress] 18:09:41 <henrynash> ayoung: they are…..I saw your in-flight change 18:09:48 <ayoung> If needs be, we can move that up to the V3 Controller. 18:10:59 <henrynash> ayoung: do you have tests written that check if tokens are deleted? 18:11:42 <ayoung> henrynash, usually we just check that a token that authenticated in the past doesn't authenticate afterwards, but you can always do a list_tokens call for the user to ensure that it is not there 18:11:57 <henrynash> ayoung: ok, right, got it 18:12:00 <ayoung> Or, probably better, get_token 18:12:19 <ayoung> depends on if you are doing WEB API or core.py calls. 18:12:32 <ayoung> I tend to favor core, dolph goes more toward the API level. 18:12:45 <ayoung> both are good, but core calls are easier to debug and are more unit tests. 18:13:06 <ayoung> the other I see almost as integration/functional tests...but the slope is slippery 18:13:19 <henrynash> ayoung: ok, got it 18:13:28 <ayoung> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone,n,z 18:13:52 <ayoung> here are the open reviews. and for client 18:14:01 <ayoung> https://review.openstack.org/#/q/status:open+project:openstack/python-keystoneclient,n,z 18:14:50 <ayoung> Is anything burning on either of those two lists? 18:14:59 <ayoung> gyee? 18:15:16 <gyee> ayoung, I am reviewing them :) 18:15:38 <ayoung> Glad to hear it. I'll be hitting a few shortly as well. 18:15:54 <ayoung> and bknudson is always glad to tear a patch apart. Good work there, btw 18:16:06 <bknudson> ayoung: that's what I do. 18:17:17 <ayoung> BTW, gyee made a point of kicking back one of my patches due to it not having a unit tests, and I was all grumpy like...it turned out he was 100% correct, as the code I submitted, even though it was just replaceing what had been removed, was b0rjk3d. 18:17:26 <ayoung> So, no new code without unit tests. 18:17:41 <henrynash> ayoung: absolutely 18:17:45 <gyee> +1 18:18:02 <bknudson> should document the requirement so can point to it. 18:18:07 <ayoung> BTW, I will try to update the code coverage stats and post later this week. I bet we find that we've all missed covereage in recent patches. Especailly me with trusts. 18:18:25 <gyee> ayoung, https://bugs.launchpad.net/keystone/+bug/1153808 and https://bugs.launchpad.net/keystone/+bug/1153455 18:18:27 <uvirtbot`> Launchpad bug 1153808 in keystone "identiy-doc response format not conistent in token response and other responses" [Undecided,New] 18:18:27 <ayoung> #action ayoung to update code coverage and post 18:18:32 <gyee> can we confirm these two 18:18:46 <ayoung> gyee, will look after this 18:19:20 <ayoung> https://bugs.launchpad.net/keystone/+bug/1153455 does not look right 18:19:22 <uvirtbot`> Launchpad bug 1153455 in keystone "value of the field "links" in response is not correct. ( identiy-api-doc)" [Undecided,New] 18:19:51 <ayoung> "href": "http://identity.api.openstack.org/v2.0" looks wrong on a couple levels 18:19:55 <ayoung> which leads to.... 18:20:06 <gyee> ayoung, exactly, we need to correct the doc 18:20:22 <ayoung> #topic 18:20:26 <ayoung> #topic v2 vs v3 api versions 18:20:29 <gyee> there's also a bigger issue on how we provide these links 18:20:52 <henrynash> ayoung: I added this, so we could discuss the issues dan was reporting 18:21:07 <ayoung> henrynash, so first and foremost I want to update the bug report 18:21:29 <ayoung> If I didn;'t know dan and how right he tends to be about things I would mark a report written like that as invalid 18:21:46 <ayoung> So what was the actual problem he saw? 18:22:13 <henrynash> ayoung: I don;t know much more than you….other that using unversioned urls meant his stuff was failing 18:22:39 <ayoung> yeah...I don't know how there can be such a thing as "unversioned urls" 18:22:44 <ayoung> that is my first problem with the report 18:22:54 <henrynash> ayoung: to be honest, other than "Get versions", I didn't know we supported unversioned urls 18:23:10 <ayoung> second is how it jumps right to a solution without providing a problem other than "something is broken" 18:23:19 <henrynash> i.e. ' Get /' 18:23:28 <ayoung> right 18:23:59 <ayoung> henrynash, it sounds to me like the fetch of the token validation files is broken: either the certs or the revocation list 18:24:04 <ayoung> which is just a plain bug. 18:25:51 <ayoung> henrynash, I will open a new bug which says we should default to V3, and when you get more information on https://bugs.launchpad.net/python-keystoneclient/+bug/1154144 please get it updated to be accurate? I'll try to do so as well. We shouldn;'t accept a fix to Keystone without being told what is broken. 18:25:53 <uvirtbot`> Launchpad bug 1154144 in python-keystoneclient "auth_token middleware should default to v2.0 if version is not specified" [Critical,In progress] 18:25:55 <henrynash> ayoung: so plan is: a) patch it for now to default to v2.0, while we work out what the real fix is….then decide what we want for the grizzly release, in terms of default 18:26:10 <henrynash> ayoung: agreed 18:26:13 <ayoung> henrynash, with step 0 being a decent bug report, yes 18:26:30 <gyee> henrynash, what "real" fix you have in mind? 18:26:36 <zykes-> is v3 borked or ? 18:27:04 <ayoung> gyee, we'll know when we know what is broken 18:27:10 <henrynash> gyee: well, that somewhat depends if we are meant to support unversioned urls in general 18:27:13 <ayoung> but defaulting to V3 should be seamless 18:27:20 <henrynash> ayoung: agreed 18:27:38 <gyee> nice :) 18:32:28 <spzala> henrynash: ayoung: I wanted to verify with DolphM today that if #link https://review.openstack.org/#/c/22624/ can get into grizzly...it's out for review. In the last meeting, DolphM mentioned that he will be checking with ttx. 18:33:31 <topol> ayoung, I am starting to run _ldap_livetest.py It blows chunks in setup. I may just be missing stuff in my LDAP config mappings but not sure. I will start investigatting. Previously, has this test been run very often??? 18:33:53 <henrynash> spzala: hold fire on that, we'll get to it in other business (young is just chatting with dprince on the v2/v3 thing_ 18:34:19 <spzala> henrynash: :) OK, sounds good. 18:34:25 <topol> henrynash, OK 18:34:40 <ayoung> topol, it has bit rotted. I used it heavily back when I was doing my work, but it has been run infrequently since then. It is, however, imporantant that it run correctrly, as it exercises the main LDAP code. Setup problems are not a surprise, though. 18:34:58 <topol> ayoung, I will start digging 18:35:00 <crazed> topol: i'm actually working on that 18:35:06 <crazed> we should collaborate 18:35:21 <topol> crazed, sure. great minds think alike 18:35:48 <ayoung> ping me if you guys get stuck 18:36:58 <henrynash> ayoung: next topic? 18:37:23 <ayoung> #topic admin global role still exists in v3? 18:37:34 <henrynash> ayoung: so I put this on.... 18:37:54 <henrynash> ayoung: is there meant to be the 'special" admin role in v3? 18:38:32 <ayoung> henrynash, I would love to fix that now 18:38:46 <bknudson> I opened a bug that might be related to this: https://bugs.launchpad.net/keystone/+bug/1153080 18:38:47 <ayoung> admin should not be based on a role in a tenant er project 18:38:49 <uvirtbot`> Launchpad bug 1153080 in keystone "GET v2.0/tenants authority vs GET v3/projects" [Undecided,New] 18:39:06 <henrynash> ayoung: well the implementation as it stands does NOT have the same global admin role as we had in v2 18:39:27 <henrynash> ayoung: ask I think that is correct. 18:39:38 <ayoung> henrynash, excpet that...Keystone treats it like it does 18:39:46 <ayoung> if you have admin on a project, is_admin passes 18:39:57 <ayoung> I want to get rid of that, but we need to replace it with something better 18:39:57 <henrynash> ayoung: are you sure about that? 18:40:10 <ayoung> the somethuing better is, I think, policy and RBAC 18:40:20 <ayoung> henrynash, I'll paste a link 18:40:34 <gyee> ayoung, is_admin is only set if the ADMIN token is used 18:40:56 <bknudson> policy.json has mostly role:admin... 18:41:10 <ayoung> #link https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py#L274 18:41:23 <ayoung> #link https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py#L291 18:41:28 <bknudson> "admin_required": [["role:admin"], ["is_admin:1"]], 18:41:30 <henrynash> gyee: right….and the plain admin role will ONLY apply to those projects/domains for which the role has been pplied 18:41:39 <henrynash> ayee: in v2 18:41:46 <ayoung> Line 291 we look to see if a user has admin role in a tenant 18:41:46 <henrynash> gyee: sorry, in v3, Imeant 18:42:07 <bknudson> assert_admin got called a lot in v2, but v3 doesn't call it. 18:42:12 <henrynash> ayoung: so this is only called in v2 I think 18:42:26 <ayoung> we need to remove it everywhere, I think, and wrap those calls with policy 18:42:34 <henrynash> ayoung: for v3 we do 18:43:01 <ayoung> Good point...yeah, I think that is V2 only, but it needs to change or it will be a problem moving forward. 18:43:03 <henrynash> ayoung: and that means we insist you have admin on the specific target you are operating on 18:43:23 <bknudson> henrynash: what's a target? 18:43:48 <bknudson> henrynash: a project, or user, or group? 18:44:11 <ayoung> domain? 18:44:13 <ayoung> server? 18:44:20 <henrynash> ayoung: so my only point is….we HAVE changed this for v3, are we OK with this….and if so, we should probably document it somewhere as people might not understand why their policy file no longer works the way it used to 18:44:30 <ayoung> Adding a domain means you need admin on the server 18:44:39 <ayoung> adding a user means you have admin on domain 18:44:43 <henrynash> bknudson: either project or domain 18:45:27 <ayoung> keystone should probably not care much about project admins...maybe in order to add/remove a role for a user in that project, but that is about it 18:45:47 <ayoung> henrynash, want to take that as an action item? 18:45:48 <topol> ayoung, what does need admin on the server mean? 18:45:55 <henrynash> ayoung: sure 18:45:59 <ayoung> topol, I am glad you asked 18:46:05 <ayoung> because we don;t have that abstraction yet 18:46:08 <topol> :-) 18:47:35 <topol> ayoung, when do we start updating the docs with all this? All really good nuggets to communicate 18:49:19 <ayoung> topol, lets start by annotatuing it on that bug report. 18:50:01 <gyee> ayoung, what do we say about v3-v2 backward compatibility in generate in terms of perms? 18:50:39 <gyee> that statement will give us a base on what to do with the global admin 18:50:55 <ayoung> gyee, good question. 18:51:13 <ayoung> gyee, I think this is a place where, if we don't make a deliberate break, we are going to be haunted by it, but 18:51:23 <ayoung> if we do, we are going to break things for a lot of people 18:51:46 <topol> ayoung, any chance you could remove the red x from https://review.openstack.org/#/c/24023 we created a new bug with a more appopriate title. And I feel your red x will be a blemish on my permanent record :-) 18:51:56 <gyee> if we don't intend to be backward compat then we have a lot more flexibility 18:52:51 <ayoung> Right now, the only Keystone admin we have is tenant level. How do we remove that and still have people's scripts work? 18:53:40 <henrynash> ayoung: what do you mean by tenant level? 18:54:01 <ayoung> henrynash, user is assigned the role admin in a project 18:54:08 <ayoung> any project 18:54:18 <ayoung> and they have admin rights in v2.0 APIs 18:54:26 <ayoung> see the links above 18:54:45 <henrynash> ayoung: right, sorry, when you said "Right Now" I didn't realise you meant v2 18:55:05 <ayoung> henrynash, I mean before Grizzly goes GA. 18:55:27 <ayoung> er..I mean I want to fix it in V2 before Grizzly goes GA 18:55:33 <henrynash> ayoung: agreed 18:55:49 <ayoung> henrynash, so part of fixing that is providing an alternative 18:55:58 <ayoung> how about, as a stop gap, admin on the default domain? 18:57:01 <henrynash> ayoung: well for one thing we can't support this in v3 even if we wanted to (since how would we know which users was "admin") 18:57:31 <henrynash> ayoung: which role, sorry 18:58:33 <ayoung> henrynash, I think we make a migration which takes any user with a role of admin on any project, removes that assignment, and provides them with admin on the default domain instead. THen, amdins for the default domain can perform the actions in the V2.0 api that are is_admin now. 18:58:41 <ayoung> dolphm, ^^ does that make sense? 18:59:53 <ayoung> can I put that proposal to a vote? 19:00:14 <ayoung> Tell you what, I'll blueprint it and send it out. 19:00:22 <henrynash> ayoung; +1 19:00:25 <gyee> +1 19:00:34 <gyee> need some time to think it over :) 19:01:40 <glau_aguiar> ayoung: in this proposal, which role can create domains? 19:02:42 <ayoung> #action all review https://blueprints.launchpad.net/keystone/+spec/remove-tenant-admin 19:03:06 <ayoung> glau_aguiar, I guess it would mean that an admin on the default domain could create a new domain, as there is no other role that can do that now. 19:03:29 <bknudson> could use admin token? 19:04:10 <ayoung> bknudson, correct 19:04:39 <ayoung> OK, we are over time. Continue any discussions in #openstack-dev 19:04:58 <ayoung> #endmeeting