18:02:43 <dolphm_> #startmeeting keystone
18:02:44 <openstack> Meeting started Tue Dec 10 18:02:43 2013 UTC and is due to finish in 60 minutes.  The chair is dolphm_. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:45 <tristanC> Hello guys!
18:02:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:48 <openstack> The meeting name has been set to 'keystone'
18:02:58 <ayoung> You rang!
18:03:07 <dolphm_> #topic keystone hackday!
18:03:07 <fabiog> hi
18:03:20 <dolphm_> As mentioned a bit at the summit, I'd like to host a keystone hackday around the end of milestone 2 at Rackspace's office in San Antonio, TX. I put two options for dates on the agenda-- if you can attend and prefer one or the other, speak up! Otherwise I'm running with option 1 which end on the last Friday of milestone development
18:03:21 <morganfainberg> weee!
18:03:34 <lbragstad> Hi
18:03:40 <dolphm_> Can someone past the options from the meeting agenda?
18:03:47 * gyee is looking forward to the two week mandatory Christmas vacation
18:03:50 <morganfainberg> Option 1: Wednesday-Thursday-Friday January 17-19th (ahead of the milestone)
18:03:51 <dolphm_> I'm trapped on my phone again :)
18:03:54 <morganfainberg> Option 2: Monday-Tuesday-Wednesday January 22-24th (around the milestone)
18:04:07 <bknudson> isn't it chinese new year around then?
18:04:11 <henrynash> either is fine by me
18:04:29 <dolphm_> bkhudson: sure why not
18:04:34 <morganfainberg> I think ahead of the milestone is better
18:04:37 <morganfainberg> (option 1)
18:04:43 <morganfainberg> but that is just personal bias.
18:04:59 <dstanek> i think i'd be find with either
18:05:06 <gyee> I can bring chinese fire crackers to celebrate
18:05:12 <dolphm_> agree, and we wanted a Friday :)
18:05:18 <ayoung> dolphm_, Gettin close on dates, we probably need to lock it down for airfare
18:05:21 <morganfainberg> dolphm_, ++
18:05:47 <ayoung> gyee, Bringing fireworks to Texas is like bringing Coal to Newcastle
18:05:53 <morganfainberg> and letting employers know and all that.
18:06:33 <dolphm_> ayoung: I'd like to pick now for that reason
18:06:37 <stevemar> i'll let topol know, not sure if he's here
18:07:08 <gyee> stevemar, just submit the expense report later
18:07:31 <stevemar> gyee, that's insanity
18:07:33 <dolphm_> gyee++ ask for forgiveness
18:07:47 <ayoung> dolphm_, so, I think we should agree that if we go with the later date, anything done during the hackfest is fair game for Icehouse, API freeze or no.  Otherwise, it has to be the earlier one.
18:07:53 <morganfainberg> dolphm_, uhm... is my calendar wrong? but... 17-19 seems to be friday, saturday, sunday?
18:08:08 <stevemar> oooo i like that, ayoung ++
18:08:09 <dolphm_> ayoung: earlier one the
18:08:12 <dolphm_> n
18:08:24 <ayoung> morganfainberg, you are right
18:08:31 <dolphm_> did I calendar bad?
18:08:35 <stevemar> you did
18:08:38 <dolphm_> dammit
18:08:39 <morganfainberg> yep
18:08:49 <ayoung> When is I2?
18:09:04 <morganfainberg> #link https://wiki.openstack.org/wiki/Icehouse_Release_Schedule
18:09:06 <gyee> 1/23
18:09:08 <morganfainberg> Jan 23
18:09:25 <ayoung> https://launchpad.net/keystone/+milestone/icehouse-2
18:10:39 <ayoung> So 15-17 would be Wed-Fri before
18:10:42 <morganfainberg> i think the first one would need to be jan 15, 16, 17 (wed -> fri)
18:10:55 <ayoung> and 20-22
18:11:00 <dolphm> alright so icehouse-m2 is the 23rd, which means branching on the 21st, which means Option 1 was supposed to be Jan 15-17
18:11:23 <morganfainberg> and i like that one better because it gives us a (short) window to follow up on anything that comes out of it to hit i2 if needed
18:11:25 <dolphm> i bet i was looking at 2012 or something
18:12:09 <dolphm> #agreed Keystone Hackday Icehouse January 15-17 @ San Antonio, TX
18:12:41 <bknudson> 1218 miles for me... straight down i35
18:12:43 <dolphm> bknudson: you've got 3 items on the agenda -- which do you want first ?
18:12:59 <bknudson> let's start at the beginning
18:13:09 <bknudson> tempest change for assignments-doesn't-check-identity
18:13:15 <dolphm> #topic Tempest change for assignments-doesn't-check-identity
18:13:21 <bknudson> so I put the change in at henrynash 's request
18:13:35 <bknudson> and then it failed tempest because they added a test that if you assign a role to a user doesn't exist then it fails
18:13:49 <bknudson> so I added the tempest change but they didn't like it... wanted a blueprint
18:13:54 <henrynash> bknudson: :-(
18:13:57 <dolphm> #link assignments-doesn't-check-identity
18:14:04 <dolphm> err
18:14:08 <dolphm> #link https://review.openstack.org/#/c/56106/
18:14:13 <bknudson> so I looked for blueprint and didn't see one that would be obvious to tempest
18:14:27 <bknudson> I could use federation ... but I don't think that's obvious
18:14:33 <bknudson> so how about a new blueprint?
18:15:04 <bknudson> split-identity was also suggested, but that one is closed already
18:15:19 <ayoung> bknudson, you should be able to create a role assignment for a bogus user and have it succeed.  Then create the user in SQL and they get the roles when next they get a token
18:15:52 <bknudson> ayoung: that's what my fix does, and what the tempest tests don't allow
18:16:12 <dolphm> #link https://review.openstack.org/#/c/54647/
18:16:15 <gyee> with federation, you'd be insane to assign roles directly to users
18:17:02 <dolphm> bknudson: new bp ++
18:17:16 <bknudson> dolphm: ok, just wanted to make sure.
18:17:53 <dolphm> gyee: ++ not really possible at all
18:17:58 <dstanek> bknudson: is you comment true that assigning to a non-existent use may return either a success or 404?
18:18:15 <ayoung> gyee, except that we are going to have to.  There are no group mechanisms in Identity that we can count on, and we don't have user groups in Assignments
18:18:43 <bknudson> dstanek: the identity spec doesn't says that it can return success, and the keystone server can also return 404
18:18:55 <dolphm> ayoung: mapping comes into play
18:19:01 <gyee> always maps users to groups, that's the best way to manage changes
18:19:07 <ayoung> bknudson, the split-identity blueprint should cover this behavior
18:19:16 <ayoung> https://blueprints.launchpad.net/keystone/+spec/split-identity
18:19:23 <gyee> your auditing will be that much easier
18:19:35 <bknudson> ayoung: but the split-identity blueprint is complete ... would seem odd to re-open it?
18:19:44 <dstanek> bknudson: i can see why sdague doesn't like it - it really is multiple scenarios
18:19:47 <dolphm> ayoung: re-opening released bp's is a no-no
18:20:01 <ayoung> bknudson, hmmmm
18:20:20 <morganfainberg> gyee, ++, it still doesn't change the fact that you can't rely on identity to assign a role in all cases.  you'd need to still assign without checking / not fail?
18:20:24 <bknudson> Maybe I can make the new blueprint a continuation of split-identity.
18:20:50 <dolphm> bknudson: yeah, we can link them up
18:20:53 <ayoung> could also be covered under federation if it is for future work
18:21:10 <gyee> morganfainberg, you'll always assign roles to groups
18:21:19 <ayoung> https://blueprints.launchpad.net/keystone/+spec/federation
18:21:21 <morganfainberg> gyee, yes.
18:22:07 <bknudson> ayoung: the concern I have with using federation bp is that I don't think it's going to be obvious to tempest what the connection is.
18:22:25 <morganfainberg> bknudson, make a new bp linked to federation?
18:22:42 <ayoung> morganfainberg, ++
18:22:58 <bknudson> a new bp linked to federation would make it obvious, so I'm fine with that
18:23:56 <ayoung> I think all of the arrows are pointing the wrong way in the dependency graph https://blueprints.launchpad.net/keystone/+spec/federation
18:24:27 <ayoung> I'll take the action item to write the BP
18:24:29 <gyee> ayoung, good observation
18:24:36 <bknudson> ayoung: great, thanks
18:24:37 <ayoung> bknudson, and then I'll assign to you?
18:24:42 <bknudson> yep
18:24:58 <dolphm> #action syoung to write the bp
18:25:35 <ayoung> dolphm, probably want more context in those #action lines....
18:25:39 <dolphm> #topic REMOTE_USER auth v2 and v3 mismatch
18:26:03 <gyee> didn't we beat this horse to death already?
18:26:04 <ayoung> dolphm, I think the latest patch is on track for REMOTE_USER
18:26:11 <dolphm> A) we need to provide compat with grizzly throuhg master, which is currently broken
18:26:22 <dolphm> ayoung: good to hear
18:26:23 <bknudson> so on this one... I think it would be great to have some doc that says what the plugins we want are.
18:26:27 <ayoung> #link https://review.openstack.org/#/c/50362/
18:26:44 <bknudson> maybe I'm the only one who needs this to be more explicit so we can make sure we've got them all.
18:26:55 <dolphm> bknudson: genreally thats the bp system :P
18:26:56 <gyee> bknudson, ++ on good doc, that's the best we can do here
18:27:21 <ayoung> bknudson, we need to old behavior, which turns all of REMOTE_USER into the user-id, and we need the Split on the @ sign for Kerberos
18:27:22 <dolphm> use cases for each should be doc'd in bp's
18:27:44 <bknudson> ok, I'll aim for a bp.
18:28:03 <bknudson> that was it
18:28:26 <dolphm> cool
18:28:32 <dolphm> #topic Moving keystone tests to tempest
18:28:49 <bknudson> so, unfortunately I missed the summit session.
18:29:00 <bknudson> but I had some time so I decided to get started on this.
18:29:26 <bknudson> I thought the best way to go is to essentially copy keystone's client tests to tempest
18:29:35 <bknudson> because don't want to lose any coverage they're giving us
18:30:03 <bknudson> so I posted 1 test for now, to see if tempest was ok with it
18:30:16 <bknudson> but, I don't think they want our tests as they are...
18:30:22 <ayoung> bknudson, the fixtures were always the weak link
18:30:32 <jamielennox> bknudson: understandable
18:30:36 <bknudson> I put them in "scenarios", and they don't fit well with the other scenario tests.
18:30:54 <bknudson> now, shardy had made a new directory for client API tests
18:31:03 <bknudson> but that change is -2 and abandoned at this point
18:31:19 <shardy> bknudson: I spoke to sdague a while back, and IIRC he said put them under scenario
18:31:24 <bknudson> so maybe tempest can be convinced to accept a new directory for client tests
18:31:29 <ayoung> Do they have a standards document that they are saying we need to meet, or is it all Project norms at this point?
18:31:39 <shardy> I think the separate tree was what caused all the upset ;)
18:31:41 <dolphm> aren't we blocked on the patch that mordred mentioned on list?
18:31:46 <ayoung> What is a "scenario"
18:32:07 <bknudson> shardy: the new trust tests would probably be an excellent candidate for a scenario test...
18:32:22 <bknudson> could go through a whole scenario where get token, get trust, do something, delete trust, etc.
18:32:27 <dolphm> ayoung: basically a configuration of openstack
18:32:50 <dolphm> ayoung: i.e. stable/havana keystone running on SQL vs a year old release of keystoneclient
18:32:54 <shardy> bknudson: Yeah, I've revived the API surface tests, and I'll revive those client trusts tess as scenario tests soon
18:33:14 <bknudson> the API surface test is the one that I think tempest has more concern about
18:33:25 <ayoung> dolphm, so all of the operations we would want to perform should be done in a scenario, and I assume separate smallish tests for each aspect of that are acceptable.
18:33:32 <jamielennox> dolphm: that would indicate scenario is not a good fit
18:33:42 <shardy> ayoung: http://docs.openstack.org/developer/tempest/field_guide/scenario.html
18:33:48 <shardy> #link http://docs.openstack.org/developer/tempest/field_guide/scenario.html
18:33:56 <dolphm> i don't think this has been mentioned yet, but all of test_keystoneclient (and all the git checkout business) is basically testing v2.0, which we're also now deprecating...
18:34:28 <ayoung> we fall more under this http://docs.openstack.org/developer/tempest/field_guide/cli.html
18:34:32 <dstanek> shardy: excellent link thanks
18:34:36 <bknudson> it might take us so long to get the tests to tempest that they'll be deprecated by then!
18:34:38 <dolphm> so, maybe only focus on porting authentication tests (things testing /v2.0/tokens and /v2.0/tenants stuff)
18:35:03 <ayoung> or this http://docs.openstack.org/developer/tempest/field_guide/api.html
18:35:18 <ayoung> explicitly not scenario tests. Otherwise we are hiding what we are trying to do.
18:35:20 <bknudson> tempest thinks that "api" is "REST API"
18:35:38 <ayoung> bknudson, yes, we are scope creeping tempest here
18:35:44 <ayoung> we have stated that all along
18:36:12 <ayoung> but the client API is a contract that we need to be held to as much as the remote HTTP API
18:36:41 <dolphm> ayoung: ++ today we're testing those in one suite for v2.0 ... we could break them apart into separate tests
18:36:50 * shardy has to go
18:36:58 <ayoung> shardy, thanks
18:37:04 <bknudson> my latest request in my tempest patch was if we could get it in the python API tests that shardy proposed and is -2d
18:37:13 <ayoung> dolphm, lets follow the guidelines for the API tests, then
18:37:24 <jamielennox> ayoung: ++,  i think we should be arguing for a new folder for client tests
18:37:28 * dolphm shardy sponsored by Fiber One® Breakfast Cereal, Fiber Bars & Healthy Yogurt
18:37:37 <jamielennox> and encouraging other clients to do the same
18:37:57 <ayoung> jamielennox, so that should probably be a Tempest Blueprint
18:38:10 <bknudson> there is one for keystone...
18:38:16 <jamielennox> ayoung: yea
18:38:43 <bknudson> #link https://blueprints.launchpad.net/tempest/+spec/keystoneclient-api
18:38:47 <ayoung> but it sounds like Monty is cranking on just that already, wonder if he has a bp he is working from?
18:38:57 <jamielennox> but at least reading through the field guide we'll be really struggling to get included in any of those groups
18:38:58 <topol> o/  Showing up way late
18:39:01 <dstanek> there seems to be a big gap between cli tests and api tests...does tempest already have a bp to address this?
18:39:35 <dolphm> #link https://review.openstack.org/#/c/41931/
18:39:51 <dolphm> bug 939699
18:39:53 <uvirtbot> Launchpad bug 939699 in openstack-ci "client lib integration tests should hit multiple branches" [High,In progress] https://launchpad.net/bugs/939699
18:39:54 <jamielennox> dstanek: not sure about tempest and the blueprint but it doesn't surprise me, there has been an attitude that the CLI is the important part of a client
18:40:19 <bknudson> I'm not sure I totally follow the link between what infra is doing and how that matches with what keystone's client tests are doing.
18:40:39 <bknudson> but infra team seems to think it's "equivalent"
18:40:47 <bknudson> or adequate, or more correct.
18:40:55 <dolphm> bknudson: infra is most interested in matrix testing supported client and server versions
18:41:26 <bknudson> they also are the ones who are asking for it to be in tempest...
18:41:34 <dolphm> bknudson: whether that's CLI or python lib, i don't think tempest really cares
18:41:54 * gyee sees business opportunity for OpenStack certification test suite :)
18:42:05 <ayoung> gyee, it will be called Tempest
18:42:15 <gyee> oh damn
18:42:18 <jamielennox> gyee: i'm pretty sure they are doing that
18:42:26 <bknudson> gyee: I think the board or foundation is considering doing that... calling it "core" openstack
18:42:26 <dolphm> gyee: you're a year late :P http://www.rackspace.com/blog/newsarticles/rackspace-launches-certification-program-for-openstack/
18:42:32 <jamielennox> can't remember what it is called
18:42:59 <dolphm> oh, the TC wants to use tempest to certify clouds.. yeah
18:43:07 <bknudson> http://robhirschfeld.com/2013/07/22/kicking-off-core/
18:43:16 <gyee> excellent!
18:43:34 <gyee> so yeah, client tests are the acid tests
18:43:42 <jamielennox> gyee: http://refstack.org/
18:44:02 <bknudson> tempest is not doing much python API testing at this point... the scenario tests do use the python API
18:44:09 <bknudson> (v2 for keystoneclient)
18:44:32 <bknudson> I haven't looked at the cli tests to know what they cover for keystoneclient
18:44:42 <dolphm> jamielennox: that website needs some grammar help
18:44:51 <dstanek> so what do we need to do about this - propose a blueprint for real client tests instead of the cli tests?
18:45:20 <bknudson> I think we have a blueprint -- https://blueprints.launchpad.net/tempest/+spec/keystoneclient-api
18:45:30 <bknudson> again, thanks to shardy_afk !
18:45:55 <dolphm> bknudson: ++
18:45:56 <jamielennox> dstanek: i think so, but from the list and from those bugs we should coordinate with monty and see whether we can just piggyback that effort
18:47:05 <bknudson> I'll try to engage the tempest team more and see if they agree with the bp.
18:47:12 <dstanek> just to summarize our goal - we want to test the matrix of all supported keystone client versions against all supported keystone server versions...is that right?
18:47:23 <dolphm> dstanek: yes
18:47:42 <bknudson> the supported keystone client versions are apparently 0.1.1, essex-3, and master
18:47:54 <dstanek> bknudson: if you can keep me in the loop here because i am heavily interested in this topic
18:48:09 <topol> bknudson how did you determine that?
18:48:13 <dolphm> bknudson: that's debatable
18:48:16 <jamielennox> bknudson: i don't think that is really the case
18:48:21 <dolphm> topol: that's what we have in test_keystoneclient
18:48:37 <dolphm> but we should really have 0.2.x tests, 0.3.x tests, and now 0.4.x tests
18:48:39 <jamielennox> bknudson: i'd like to see 0.2.2, 0.3.x and an 0.4.0
18:48:46 <jamielennox> + master
18:48:46 <dolphm> and master
18:49:02 <bknudson> I could make that change to test_keystoneclient first.
18:49:22 <bknudson> (or somebody else could)
18:49:43 <dolphm> bknudson: there's already a patch in review to drop essex-3
18:50:02 <jamielennox> anyone know what was special about 0.1.1?
18:50:12 <dolphm> jamielennox: it was released
18:50:25 <gyee> :)
18:50:27 <dstanek> bknudson: i can change test_keystoneclient
18:50:32 <bknudson> dstanek: thanks!
18:50:59 <bknudson> I'm guessing everything since 0.1.1 was put into the "master" testcase
18:51:10 <bknudson> so it will require some work to figure out where each test works
18:51:45 <bknudson> maybe just throw them all into compat and skip them
18:51:54 <jamielennox> bknudson: is it worth fixing test_keystoneclient? why don't we just start again in tempest, and do it how they want it
18:51:57 <dolphm> bknudson: well, you'll see them fail, and we can review the skips in gerrit to make sure they're legit
18:52:01 <dolphm> err, intended
18:52:20 <dolphm> jamielennox: this bit of work has to be done either way
18:52:55 <dolphm> jamielennox: coverage can be ported piece by piece once we have something organized enough to port
18:52:59 <bknudson> I think it will be easier and better to get our own house in order before having to go through a different set of reviewers
18:53:10 <dstanek> what i had a hard time grokking in tempest was how it would run using different client versions and not pulling them from git
18:53:41 <bknudson> dstanek: I don't know how that's going to happen either... that was my comment earlier about not seeing the link.
18:54:24 <bknudson> can the tests in tempest know what version of keystoneclient they're using and skip tests?
18:54:31 <gyee> dstanek, how does grenade test upgrades?
18:54:40 * dolphm 5 minutesish
18:54:41 <bknudson> (also, maybe that's a better way to write the client tests in keystone
18:55:01 <jamielennox> dolphm: wouldn't mind a quick chat on backwards compat in client
18:55:03 <dstanek> bknudson: maybe we just need to have a quick chat with some tempest folks to really hash out what we are trying to do
18:55:03 <bknudson> gyee: I started looking at grenade but didn't have enough time to figure it out.
18:55:15 <jamielennox> i put up a auth plugin WIP https://review.openstack.org/#/c/60751
18:55:31 <gyee> jamielennox, good stuff
18:55:38 <bknudson> dstanek: I assume they have a meeting like ours
18:55:39 <jamielennox> is it appropriate to say if you pass a session object to a client then you are using the *new way* and that you should not expect the previous behaviours to apply?
18:55:46 <dstanek> gyee: grenade test upgrades?
18:55:49 <dolphm> jamielennox: yes
18:55:55 <dolphm> jamielennox: that's backwards-compatible
18:55:57 <gyee> dstanek, that's my understanding
18:55:58 <ayoung> 5 minutes left
18:56:22 <jamielennox> dolphm: it turns testing into a bit of a mess
18:56:27 <dstanek> bknudson: would it be https://wiki.openstack.org/wiki/Meetings/QATeamMeeting?
18:56:34 <dolphm> jamielennox: you could also just have a new constructor
18:56:35 <gyee> I would like to re-introduce pagination if y'all don't mind
18:56:42 <bknudson> ok, I think we've got a TODO for dstanek and I to talk to tempest and try to make progress.
18:56:47 <gyee> pagination never got killed and we need it
18:57:02 <dolphm> gyee: i didn't follow up on the pagination discussion at the summit, other than knowing everyone went into it despising pagination
18:57:03 <jamielennox> dolphm: ie don't use v3.client.Client ?
18:57:09 <dolphm> jamielennox: right
18:57:16 <bknudson> dstanek: we'll have no idea when they meet because they have different times depending on the week!
18:57:21 <dolphm> jamielennox: that's why I was suggesting keystoneclient.Client()
18:57:23 <gyee> dolphm, that session didn't happen and we need some pagination
18:57:35 <gyee> I would like to re-introduce the ones we had originally
18:57:45 <gyee> page,per_page as the minimum
18:57:53 <jamielennox> dolphm: i've been hoping to make keystoneclient.Client() the discoverable entry point
18:58:05 <dolphm> gyee: we talked about supporting hard limits in conf... is that all you want?
18:58:07 <jamielennox> dolphm: but as that is a new feature as well maybe it can be rolled into one
18:58:17 <dolphm> jamielennox: ++
18:58:30 <gyee> dolphm, not so much about implementation, we need to get it back onto the API spec first
18:58:42 <dolphm> gyee: the configuration approach does not impact API
18:58:42 <gyee> we removed them from the spec
18:59:04 <dolphm> gyee: the spec still supports paginated links -- we're just not using them
18:59:06 <gyee> I mean page and per_page is not on the API spec currently
18:59:20 <gyee> dolphm, as list filters
18:59:30 <bknudson> I think I removed them from the spec because they weren't implemented
18:59:33 <gyee> i.e. GET /v3/projects?page=5
18:59:46 <bknudson> and I didn't see them being implemented
18:59:49 <gyee> bknudson, it is implemented in common controller
18:59:56 <dolphm> gyee: hardly
19:00:02 <bknudson> the implementation in common controller was "return"
19:00:06 <gyee> dolphm, I can finish up the implementation
19:00:12 <gyee> the bare minimum
19:00:38 <dolphm> gyee: we can talk about hard limits in conf first, which was the actual deployer ask
19:00:40 <dolphm> #endmeeting
19:00:52 <dolphm_> #endmeeting