18:01:55 <dolphm> #startmeeting keystone
18:01:56 <openstack> Meeting started Tue Sep 10 18:01:55 2013 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:00 <openstack> The meeting name has been set to 'keystone'
18:02:03 <dolphm> YAY HAVANA
18:02:21 <dolphm> #topic Havana release blockers
18:02:26 <dolphm> #link https://launchpad.net/keystone/+milestone/havana-rc1
18:02:32 <topol> hi
18:02:53 <dolphm> speaking of packstacking all day... ayoung, you've got three RC blockers assigned to you -- are you working all of those?
18:03:17 <henrynash> so #link https://bugs.launchpad.net/keystone/+bug/1201487 is available fore review
18:03:18 <uvirtbot> Launchpad bug 1201487 in keystone "listing projects for a user omits those that only have group related roles" [High,In progress]
18:03:22 <dolphm> i just want to make sure that everything we have targeted towards RC1 is making progress
18:03:58 <atiwari> #link https://bugs.launchpad.net/keystone/+bug/1221889 working on it
18:04:00 <uvirtbot> Launchpad bug 1221889 in keystone "Invalid X-Subject-Token results in HTTP 401 rather than 404" [High,In progress]
18:04:01 <dolphm> (cc henrynash) i also just updated the meeting agenda with code reviews to havana release blockers https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Agenda_for_next_meeting
18:04:09 <ayoung> dolphm, when is the submission freeze for RC1?
18:04:23 <dolphm> ayoung: ASAP? it's done when it's done
18:04:31 <dolphm> ayoung: hence 'blockers'
18:04:35 <bknudson> is there a reason keystone returns 401 and not 404 (security?)
18:04:42 <dolphm> bknudson: context?
18:04:47 <henrynash> dolphm: excellent
18:04:54 <bknudson> https://bugs.launchpad.net/keystone/+bug/1221889
18:05:03 <dolphm> bknudson: i think that's just a bug
18:05:14 <dolphm> bknudson: disagrees with spec, and with auth_token's expectations
18:05:27 <morganfainberg> dolphm ++ on that being a bug
18:05:32 <bknudson> ok. I hadn't looked at it, just looked fishy.
18:05:35 <dolphm> atiwari: thanks!
18:05:56 <atiwari> yrw
18:06:12 <henrynash> dolphm: as an aside, I will also post a review for a solution to #link https://bugs.launchpad.net/keystone/+bug/1153645 tonight as well
18:06:13 <uvirtbot> Launchpad bug 1153645 in keystone "Deleting a role should revoke any tokens associated with it" [High,Confirmed]
18:06:32 <henrynash> dolphm: not in the rc1 list, but it is rated High
18:06:48 <dolphm> henrynash: should that be a release blocker?
18:07:20 <dolphm> henrynash: "need to refactor the code" means i'm scared to land in havana :)
18:08:16 <henrynash> dolphm: turned out to be much easier than I thought..I forgot I had written the list_role_assignments() method, I can just use that to get all the uses that have the roel we are deleting
18:08:41 <henrynash> dolphm: so very relatively small change
18:08:53 <dolphm> henrynash: cool
18:09:00 <dolphm> henrynash: targeted
18:09:05 <henrynash> dolphm: ok
18:09:26 <dolphm> if anyone has any other bugs in progress that *should* be release blockers, feel free to point them out :) i've been trying to identify as many as possible
18:09:44 <dolphm> i also have this one targeted which just needs to be investigated, at least https://bugs.launchpad.net/keystone/+bug/1131590
18:09:45 <uvirtbot> Launchpad bug 1131590 in keystone "the folsom keystone database schema can't upgrade to latest  version" [High,Confirmed]
18:09:54 <ayoung> How's morganfainberg
18:10:06 <ayoung> 's work on domains coming?
18:10:12 <morganfainberg> ayoung, review is posted
18:10:20 <dolphm> morganfainberg: passing jenkins?
18:10:24 <morganfainberg> dolphm, yes
18:10:41 <gyee> link?
18:10:43 <morganfainberg> sec
18:10:48 <dolphm> #link https://review.openstack.org/45649
18:10:51 <morganfainberg> https://review.openstack.org/#/c/45649/
18:10:51 <ayoung> #link https://review.openstack.org/#/c/45649/
18:11:02 <dolphm> #winner dolphm
18:11:09 <ayoung> heh, anyone else?
18:11:14 <morganfainberg> lol
18:11:34 <henrynash> morgafainberg: so I noticed you kind of pulled back from removing the user/group validation checks form the grant calls
18:11:37 <ayoung> morganfainberg, anything in that that you would consider "scope creep" besides URL encoding the IDs?
18:12:01 <henrynash> morganfainberg: was that just too minimise change/risk?
18:12:02 <morganfainberg> ayoung, i didn't address full DNs as user_ids.
18:12:13 <morganfainberg> ayoung, that could be a large amount of change risk
18:12:19 <dolphm> morganfainberg: ++
18:12:27 <dolphm> save that for icehouse, and do it project-wide :)
18:12:47 <gyee> wow, user_id is not globally unique?
18:13:02 <morganfainberg> henrynash, i was working towards minimizing risk, but i pulled a some of "check user_id/project_id" out of the drivers and pushed to the controllers where i could
18:13:09 <bknudson> user_id won't be globally unique if use DNs
18:13:10 <dolphm> gyee: it's now "complicated" in the case of users and identity-backend-per-domain
18:13:12 <morganfainberg> or .. brought it in line with the other implementations
18:13:23 <gyee> dolphm, that will be messy
18:13:28 <dolphm> gyee: +++++++++
18:13:31 <henrynash> gyee: yes, it still is…but you might not know which domain to look in
18:13:39 <ayoung> bknudson, yes they will
18:13:55 <ayoung> DNs will be per LDAP server....if you use the same DN twice, you are wrong wrong wrong
18:14:17 <morganfainberg> if you have a complete DN being duplicated, i'm going to raise an abiguous ldap server error :P
18:14:30 <dolphm> bknudson: shouldn't they vary per DC?
18:14:39 <morganfainberg> dolphm, they should.
18:14:49 <dolphm> morganfainberg: i assume that's how you're selecting the LDAP driver to use?
18:14:49 <gyee> DN, by definition, is globally unique
18:14:53 <ayoung> morganfainberg, I still think we want to look at the ID and say "ah, that is  a DN,  let us parse it, and figure out which LDAP server to talk to"  in icehouse
18:14:54 <jamielennox> i though user_id was unique username was supposed to be unique per domain
18:15:00 <bknudson> DNs could vary, but then someone might just store by cn=Users.
18:15:01 <morganfainberg> ayoung, that was my thought
18:15:28 <ayoung> bknudson, and then only one LDAP server will be allowed to do that in a deployment...and everyone else is SOL
18:15:31 <dolphm> jamielennox: ++
18:15:32 <morganfainberg> jamielennox, user_id should be globally unique.
18:15:32 <bknudson> also, our LDAP can also use cn for the userid attribute
18:15:50 <morganfainberg> jamielennox, and you're right, username is domain unique
18:15:52 <henrynash> morganfainberg: ++
18:16:08 <jamielennox> ok, must of misread the conversation
18:16:20 <dolphm> bknudson: user.name=cn, user.id=dn ?
18:16:37 <morganfainberg> bknudson, but does the fully qualified DN ever change?
18:16:39 <ayoung> jamielennox, no, you did not,  he is explicitly putting a domain check on the lookup by user_id
18:16:42 <gyee> dolphm, that's usually the case
18:16:52 <bknudson> dolphm: that would be ok, but we currently have the user id is the cn, I think?
18:17:01 <dolphm> bknudson: i think so too
18:17:03 <ayoung> oh, wait...not, that is not what you are doing, is it
18:17:13 <morganfainberg> bknudson, we do. that is why i didn't want to tackle this change in havana
18:17:20 <ayoung> you are just confirm after lookup..that is much better
18:17:32 <morganfainberg> ayoung ++
18:17:49 <bknudson> if we're going to change it, it'll take a release of deprecated.
18:18:02 <morganfainberg> bknudson, and migration paths.
18:18:05 <dolphm> #topic open discussion
18:18:29 <bknudson> I'm getting asked about https://review.openstack.org/#/c/43041
18:18:39 <bknudson> "Support client generate literal ipv6 auth_uri base on auth_host"
18:18:56 <bknudson> my opinion is that it's supported already if you can put [] in auth_host
18:19:30 <bknudson> but others might have different opinions so would be nice to get wider input
18:20:02 <gyee> bknudson, yeah, host is just a string
18:20:12 <bknudson> also, https://review.openstack.org/#/c/45488/ -- it's a doc change
18:20:35 <gyee> you can also tunnel IPv6 over IPv4 right?
18:20:36 <topol> bknudson all the bug fix does is add []. you are saying that is an uneeeded convenience function?
18:20:58 <bknudson> topol: yes, an unnecessary complication of the code.
18:21:36 <gyee> bknudson, yeah, seem unnecessary
18:21:40 <bknudson> note that I haven't actually tried putting [] in auth_host myself yet... haven't had time.
18:21:48 <ayoung> gyee, I don't thien IPv6 over IPv4 is what people are looking for
18:22:11 <gyee> ayoung, point is auth_token itself doesn't know
18:22:17 <gyee> and probably don't care
18:22:54 <dolphm> gyee: bknudson: ayoung: i suspect this is poor interplay between token providers, business logic distributed between controller/manager/driver, driver separation etc, but there's a lot of redundant queries to LDAP in a single POST /tokens call http://ix.io/7Xg
18:23:24 <ayoung> bknudson, if they are doing IPv6, then the problem is, I think, DNS.  THe hostname should only resolve to a AAAA record, and the client should deal with that directly
18:23:34 <bknudson> dolphm: the logging when using LDAP is pretty crazy
18:23:42 <bknudson> ayoung: yes, I'd also say use DNS.
18:23:42 <ayoung> we should not be advocating oputting IP address, V4 or V6, into URLs
18:23:48 <dolphm> morganfainberg: caching reduces the load on LDAP in the above request from like ~22 queries to ~5
18:23:54 <ayoung> bknudson, rip out the logging!
18:24:02 <morganfainberg> dolphm, nice.
18:24:19 <morganfainberg> dolphm, it'll only get better as we implement more caching
18:24:24 <dolphm> ayoung: bknudson: it's not just logging. it's the issuing tons of redundant queries to LDAP for the same data over and over
18:24:24 <ayoung> <steve_perry> Shoulda been gone, long ago, far away!</steve_perry>
18:24:27 <bknudson> ayoung: but the logging is also an indication we're doing something wrong (e.g. new connection per query)
18:24:34 <gyee> yeah, that logging's a lot of noise
18:25:16 <morganfainberg> bknudson, it seems like a pool like sqlalchemy session pooling would make sense for LDAP.  though… that has other pitfalls
18:25:16 <dolphm> ayoung: bknudson: blueprint and make go! https://pypi.python.org/pypi/ldappool/
18:25:27 <morganfainberg> dolphm, +++++
18:25:43 <ayoung> No
18:25:52 <ayoung> that is the wrong approach for LDAP
18:26:01 <gyee> is connection pool reliable in Python land?
18:26:11 <ayoung> What we are doingright now is using a manager account
18:26:27 <ayoung> we should, instead,  be using the same ldap connection that we used to authenticate the user, and do things as that user
18:26:44 <ayoung> That wauy, LDAP ACLs are enforced
18:26:48 <dolphm> ayoung: how does that make connection pooling 'the wrong approach'?
18:27:04 <ayoung> dolphm, a connection pool only makes sense for the manager case
18:27:23 <ayoung> dolphm, we create a connection for authentication right now, using the simple bind
18:27:45 <ayoung> there are other things we can do that have the same capabilities
18:27:55 <dolphm> ayoung: pretty sure ldappool covers that use case, check out the docs
18:28:23 <morganfainberg> i also think we can restructure the ldap driver to not make as many redundant queries.  but it'll be a lot of shuffling code around.
18:28:23 <bknudson> looks like the pool can provide differently-auth'd conns:
18:28:26 <bknudson> with cm.connection('uid=adminuser,ou=logins,dc=mozilla', 'password') as conn:
18:28:31 <dolphm> bknudson: ++
18:28:45 <dolphm> morganfainberg: ++
18:28:48 <ayoung> we need to stop providing user-list
18:29:13 <gyee> huh
18:29:14 <bknudson> ayoung: that's what filtering was going to do
18:29:17 <ayoung> dolphm, can we deprecate user list
18:29:42 <gyee> ayoung, why?
18:29:57 <ayoung> gyee, because it is thinking like a small business, and we need to think cloud scale
18:30:06 <ayoung> you wouldn't do a user list for all citizens of the US
18:30:11 <ayoung> or all BofA customers
18:30:27 <morganfainberg> ayoung, force filtering on any user-list requests?  e.g. no filter (no sane filter that is) no result?
18:30:42 <morganfainberg> there is a case for getting users like <pattern>
18:30:47 <ayoung> morganfainberg, yes and no
18:30:51 <morganfainberg> even in the case of bofa customers.
18:30:57 <ayoung> think federation, and you realize there is no user list accessable
18:31:04 <dolphm> ayoung: i'd like a list of all BofA customers so I can send them letters politely suggesting that they find a better bank
18:31:09 <ayoung> assume that you don't have enumeration access to the backing store
18:31:23 <morganfainberg> dolphm, don't hate (i've just been too lazy to switch...)
18:31:24 <gyee> dolphm, heh
18:31:24 <morganfainberg> :P
18:31:42 <ayoung> dolphm, I bet even BofA can't generate that list....maybe the NSA can
18:31:58 <henrynash> ayoung: I'd have thought that filtering + policy rules that , for instance, you must at least specify a domain_id would get us a long way
18:32:02 <dolphm> ayoung: you're saying we need to think NSA scale?
18:32:02 <morganfainberg> ayoung, good idea, lets ask the NSA for our user-list!
18:32:12 <ayoung> dolphm, absolutely
18:32:29 <dolphm> morganfainberg: i think we need message bus for that
18:32:34 <ayoung> morganfainberg, I have no desire to go through the background security clearance check to be able to see NSA data
18:32:52 * topol just got a weird phone call that said tell your buddies to stop making fun of the nsa
18:33:32 <morganfainberg> ayoung, but even with a federated login, you need some kind of breadcrumb to match up right? so a filtered userlist could still work, just not in the enumerate the canonical list way
18:33:38 <dolphm> ayoung: i think the immediate answer is that user list can be denied for everyone via RBAC, a custom driver could not implement it, etc
18:33:41 <gyee> topol, sigint is trolling this channel right now
18:33:46 <jamielennox> given that it is there is there any restriction to user-list that makes sense?
18:34:00 <dolphm> ayoung: long term we can pursue filtering, and then perhaps *require* filtering
18:34:15 <ayoung> dolphm, no, long term we say "we don't have a user list to give you"
18:34:24 <gyee> when it comes to LDAP, is all about the filter :)
18:34:28 <ayoung> dolphm, we can only provide a list scoped to something in the assignments backend
18:34:29 <jamielennox> to my mind any backend that supports user-add can probably handle user-list, but that probably indicates it should be an extension rather than core
18:34:38 <ayoung> so we can provide a list of all users in a project, or something like that
18:34:45 <ayoung> but not all users in a domain
18:34:45 <dolphm> ayoung: but i totally understand the "getting a list of all users doesn't make sense" objection
18:34:50 <bknudson> jamielennox: that soundslike a good idea
18:35:12 <ayoung> dolphm, thinkg oauth.  You don't have any way to query a liast of users in an oauth setup...saml, ABFAB, etc...nonte of  them will provide that
18:35:17 <morganfainberg> ayoung, all current users of all current projects in a domain wouldn't work?
18:35:32 <morganfainberg> user-list could just be a "known user list" via assignment
18:35:33 <ayoung> morganfainberg, yse, but that is based on assignments, not identity
18:35:55 <gyee> ayoung, that's because in federation, user don't exist in a single place
18:35:56 <ayoung> morganfainberg, except that it makes no sense to do that, but yes, in theory it is possible
18:36:18 <ayoung> gyee, and that is exactly what Keystone is becoming: a Federated identity service
18:36:34 <morganfainberg> i can see a case (audit) for getting all "currently active" users in a domain (e.g. in assignment)
18:36:37 <topol> gyee even with federation you still can get user info from the assignments. Is that not good enough?
18:36:53 <bknudson> I think it would be nice to get keystone out of the identities game.
18:36:54 <dolphm> keystone is a restful federated centralized auth gateway service api
18:36:56 <gyee> topol, with federation, forget assignment
18:37:06 <gyee> will will be all mappings
18:37:18 <ayoung> bknudson, we can split identity off of the rest of Keystone, and make it an optional component
18:37:25 <morganfainberg> jamielennox, my concern with supporting the concept of "if we can add, we can list" is that it is very inconsistent
18:37:40 <ayoung> gyee, what do you think assignments are?  They are all mappings
18:37:46 <morganfainberg> ayoung, make identity an extension?
18:37:55 <ayoung> morganfainberg, make it a separate service
18:38:05 <ayoung> deployed on a separate machine
18:38:16 <ayoung> and optional
18:38:23 <morganfainberg> keystone-id, keystone-assignment, keystone-quota (sounding like nova's services in my mind)
18:38:25 <topol> doesnt assigments = mappings?
18:38:27 <bknudson> ayoung: sounds better all the time. if you want keystone users, use that, if you want ldap, use that
18:38:33 <bknudson> or kerberos or whatever.
18:38:34 <ayoung> that is the idea
18:38:35 <dolphm> topol: ++ i think that's what he meant
18:38:37 <bknudson> windows
18:39:03 <jamielennox> ayoung: as in the current sql identity be held on a different machine, or LDAP etc as well?
18:39:09 <morganfainberg> i'm seeing a summit session here.
18:39:16 <ayoung> jamielennox, no need to puyt LDAP on a separate machine
18:39:28 <ayoung> just need a way to specify what queries to run for a given domain
18:39:30 <jamielennox> ayoung: that was my thought
18:39:49 <dolphm> ayoung: with a whole new paste file, i think you might be able to deploy like that today? minus the cross driver calls between identity and assignment
18:40:15 <jamielennox> i like the idea of making the current user operations against a sql backend a new service
18:40:21 <ayoung> dolphm, well, we need a way to apss the authentication data from one to the other...
18:40:30 <ayoung> SAML is, I think a likely candidate for that
18:40:31 <bknudson> you could develop middleware for REMOTE_USER
18:41:21 <ayoung> dolphm, I've been arguing with davidchadwick that his Federaion API should not be a separate API at all, but rahter should be the coding standard for new plugins.
18:41:33 <topol> jamielennox why the need for a new service?  Lots of new queries to be expected in the future?
18:41:43 <ayoung> The ABFAB proposal would be the first Federated plugin, but it would be method: abfab
18:41:47 <atiwari> wondering if some body can review https://review.openstack.org/#/c/37141/
18:42:48 <morganfainberg> topol, to split the identity that keystone manages into a separate container, just like ldap, etc would be separate.
18:42:51 <jamielennox> topol: removes this whole question about user-list, if you have a service where you can add to and manage via an API user-list moves over to query that directly rather than via keystone
18:43:00 <ayoung> atiwari, needs a bug report to explain what problem you are solving
18:43:15 <ayoung> jamielennox, +1
18:43:24 <atiwari> it was a new BP
18:43:34 <atiwari> for an extension
18:43:35 <ayoung> atiwari, then link it in the commit message
18:43:41 <atiwari> ok
18:43:50 <atiwari> sorry for that
18:44:16 <bknudson> this change: https://review.openstack.org/#/c/45581/  makes it so that you can do ./run_tests.sh test_backend_sql again
18:44:21 <bknudson> (don't need keystone.tests.)
18:44:22 <ayoung> atiwari, a better way to get people's attention is to explicitly add them as reviews, too.
18:44:42 <ayoung> bknudson, neat
18:44:46 <atiwari> sure
18:44:48 <morganfainberg> bknudson, mind rebasing the chain?
18:45:07 <morganfainberg> bknudson, i was going through slowly and doing the rebases as i was reviewing them
18:45:08 <bknudson> morganfainberg: I can rebase it, I just don't think the rebase is necessary?
18:45:16 <ayoung> bknudson, um, no
18:45:19 <ayoung> no nononononono
18:45:19 <bknudson> the only change was the commit message
18:45:28 <ayoung> di you just put all those test back into the global namespace?
18:45:36 <morganfainberg> bknudson, click the rebase button. the parent is outdated
18:45:55 <bknudson> ayoung: the tests have been in the global namespace for some time.
18:46:31 <ayoung> bknudson, I thought we moved them out of the global namespace when we put them in keystone/tests?
18:46:32 <jamielennox> ayoung: no, he hasn't - or at least not in that review
18:46:34 <ayoung> that was the intention
18:46:34 <bknudson> the only change this makes is to not use relative imports for packages in tests.
18:47:13 <gyee> bknudson, so that change would eliminate the need to specify keystone.tests?
18:47:39 <bknudson> gyee: yes. I think I tried it once... let me try it again.
18:47:45 <ayoung> gyee, I care naught about that...I do care if the tests are out of the global namespace
18:47:56 <morganfainberg> bknudson, i thought that was an artifact that was resolved by going to testr
18:48:05 <ayoung> we need the tests in the keystone namespace so that we can start integrating our tests with Tempest
18:48:05 <bknudson> ayoung: how does one get the tests out of the global namespace?
18:48:07 <morganfainberg> not relative imports.
18:48:10 <bknudson> tests has an __init__.py
18:48:13 <ayoung> bknudson, __init__.py
18:49:05 <ayoung> OK...maybe I panicked...
18:49:43 <bknudson> for example, now ./run_tests.sh test_cache fails, NameError: name '_' is not defined
18:49:57 <bknudson> because keystone.tests. __init__.py wasn't run at the right time
18:50:10 <ayoung> NO...I think I misread what you are doing...I think they are still in the keystone.tests  namespace
18:50:21 <dolphm> ayoung: did you look at the change?
18:50:25 <morganfainberg> ayoung, they are still in the keystone.tests namespace
18:50:42 <topol> its just how he pulls them in
18:51:00 <bknudson> hmm, well test_cache still doesn't work. not sure the problem.
18:51:11 <morganfainberg> bknudson, i can take a look at that
18:51:17 <ayoung> dolphm, I did...but I misread what I was looking at...I thought he was doing the relative imports out of the global namespace...
18:51:22 <ayoung> dumb mistake...
18:51:57 <morganfainberg> bknudson, but i don't see why test_cache should be different than anything else.
18:52:16 <dolphm> ayoung: hmm, i guess i'm not understanding your concern :(
18:52:19 <bknudson> morganfainberg: it's not... others have the same time.
18:52:29 <bknudson> others do the same time.
18:52:32 <morganfainberg> bknudson, ah ok
18:52:32 <bknudson> do the same thing
18:52:45 <morganfainberg> bknudson, i think infra said testr would solve this (as i recall)
18:53:03 <morganfainberg> and moving the tests under keystone's namespace was a prereq to that?
18:53:18 <dolphm> morganfainberg: did you just volunteer to move us to testr?
18:53:27 <bknudson> morganfainberg: I didn't make the fix to make it so I could run_tests. I just thought it was really ugly to have these imports not follow the convention
18:53:32 <morganfainberg> dolphm, oh crap.  i might have :(
18:53:48 <ayoung> dolphm, he's doing the exact opposite of what I panicked about...I basically read the patch backwards, and thought he was putting the imports into the global namespace when he is doing the exact opposite.  We want the tests to be keyste.tests.tes_backend_ldap for example, so that, if we decide to call something from tempest, we have deconflicted with, say, the novate_test_backend_ldap (if there was one)
18:53:52 <morganfainberg> bknudson, and i like that it fixes a hacking issue (more flake8 checks!)
18:53:55 <topol> somebody hit #action fast for morgan
18:54:12 <morganfainberg> topol, if i leave the channel you can't find me!
18:54:20 * morganfainberg runs and hides
18:54:22 <ayoung> yeah, this is good stuff....
18:54:24 <dolphm> #action morganfainberg to switch keystone to testr and then we can all buy him beer
18:54:27 <ayoung> ok, 6 minutes left
18:55:13 <ayoung> dolphm, OK if I opent the packaging thing as a bug, and I attempt to fix in the Havana timeframe?  If it is too invasive when the patch comes out, I will gladly accept the -2
18:55:23 <ayoung> the activation of extensions....
18:55:29 <dolphm> morganfainberg: as i recall, there's some nasty problem with our test architecture that prevents us from easily moving to testr... so no one's going to make the switch for us
18:55:42 <morganfainberg> dolphm, i'll look at it once RC1 is cut
18:55:53 <dolphm> ayoung: definitely open a bug
18:55:58 <ayoung> will do
18:55:59 <jamielennox> dolphm: i think the way we do git checkouts of old keystoneclients will bite us with testr
18:56:00 <bknudson> morganfainberg dolphm: did rebase on https://review.openstack.org/#/c/45581/
18:56:22 <morganfainberg> bknudson, thanks.
18:56:37 <dolphm> ayoung: did you poke at creating a factory to instantiate oauth1.Manager() ?
18:57:02 <morganfainberg> jamielennox, ++
18:57:08 <dolphm> jamielennox: ooh, that too
18:57:18 <jamielennox> morganfainberg: any excuse to get out of it
18:57:32 <morganfainberg> jamielennox, nah, i'll still do the work
18:57:38 <bknudson> we need to move that into tempest
18:57:38 <dolphm> morganfainberg: so you're going to move all our integration tests to tempest, then?
18:57:45 <morganfainberg> dolphm, uh.
18:57:55 <morganfainberg> dolphm, i'll see what i can do.
18:57:56 <gyee> that's a trap
18:58:02 <morganfainberg> but i don't think that is in scope
18:58:04 <morganfainberg> :P
18:58:11 <jamielennox> it could be fixed relatively easily for testr, just have each client checkout to a different folder
18:58:13 <dolphm> morganfainberg: lol
18:58:34 <jamielennox> and do it up front
18:58:41 <morganfainberg> jamielennox, likely a good plan
18:58:54 <morganfainberg> we do need to "fix" that test mechanism in either case
18:59:07 <bknudson> just wondering if anyone else has been looking at the docs?
18:59:31 <jamielennox> whilst we're talking fixing test cases another plug for: https://review.openstack.org/#/c/44014/
18:59:38 <topol> remember the last time we fixed test and then half us could test and the other half were dead in the water. lets not repeat that
18:59:41 <morganfainberg> jamielennox, haha, i was going to plug that for you.
18:59:43 <bknudson> I'd consider our docs to be in rather poor shape. I'll try to work on it.
18:59:43 <dolphm> bknudson: which docs? /answer in -dev
18:59:47 <dolphm> #endmeeting