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