18:02:32 <dolphm> #startmeeting keystone
18:02:33 <openstack> Meeting started Tue Sep  9 18:02:32 2014 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:36 <openstack> The meeting name has been set to 'keystone'
18:02:44 <dolphm> #topic Spoilers
18:02:47 <dolphm> #info it's a watch
18:02:51 <topol> o/
18:02:57 <dolphm> #topic Juno-3
18:03:01 <bknudson> everybody is making watches now
18:03:04 <bknudson> is it round at least?
18:03:07 <dolphm> bknudson: no
18:03:15 <dolphm> Congrats on Juno-3 everyone! not only did we manage to make juno-3, but we were actually the first project to be feature complete for juno :D
18:03:19 <dolphm> so, THANK YOU EVERYONE!
18:03:27 <dolphm> (despite a 20+ hour gate for most of the week)
18:03:46 <bknudson> and the pip failures
18:03:48 <topol> +++
18:04:11 <dolphm> bknudson: and a three fold increase in transient errors in the gate over the past 3 weeks :(
18:04:16 <stevemar> yay!
18:04:22 <morganfainberg> dolphm, can't let our track record of hitting the deadlines fall off.
18:04:36 <dolphm> morganfainberg: ;)
18:05:13 <dolphm> even though we had two feature freeze exceptions going into RC1, they were both approved and gating long before juno-3 was cut :(
18:05:18 <dolphm> like, 48 hours ahead
18:05:21 <dolphm> sad
18:05:22 <dolphm> anyway
18:05:29 <lbragstad> o/
18:05:30 <dolphm> #topic Juno RC1
18:05:33 <dolphm> #link https://launchpad.net/keystone/+milestone/juno-rc1
18:05:36 <topol> feels good to be complete
18:05:40 <bknudson> what's the date on rc1?
18:05:53 <dolphm> bknudson: ASAP
18:06:06 <bknudson> 9-25 according to https://wiki.openstack.org/wiki/Juno_Release_Schedule
18:06:12 <ayoung> We need to remove the cinder and neutron jobs that have all of the transient errors.  We should not be gating on them
18:06:14 <dolphm> we've started our list of blockers to RC1, and thus the countdown to RC1... RC1 will be cut when everything on the list above is Fix Committed
18:06:24 <morganfainberg> bknudson, but if we're good earlier we can get cut over and get to work on Kilo!
18:06:36 <lbragstad> whoop!
18:06:38 <dolphm> bknudson: 9/25 is the target
18:06:39 <bknudson> let's stop finding bugs then
18:06:47 <dolphm> bknudson: hopefully we'll be stable before then
18:06:55 <nkinder> bknudson: easiest way to do that is to stop looking :)
18:06:58 <morganfainberg> ayoung, that is a larger conversation - mostly around gate in general
18:07:16 <morganfainberg> ayoung, that push (functional testing in-tree vs tempest) is looking like a K target across the projects (see ML threads)
18:07:18 <ayoung> yep,  just wanted to get it in the log
18:07:36 <lbragstad> morganfainberg: do you have a link to that
18:07:48 <morganfainberg> lbragstad, it's the "TC exercise one" give me a second
18:07:49 <dolphm> i also resumed maintaining the same list as for RC1 blueprints... this time containing code reviews that are blockers for Juno-RC1:
18:07:50 <bknudson> is there more info on the functional testing in-tree?
18:07:51 <dolphm> #link https://gist.github.com/dolph/651c6a1748f69637abd0
18:08:03 <bknudson> I don't know what it means for keystone
18:08:14 <ayoung> https://bugs.launchpad.net/bugs/1361422  is the only incomplete .  I can take a look at triaging it
18:08:15 <uvirtbot> Launchpad bug 1361422 in keystone "When using Keystone API v3, catalog won't be returned" [High,Incomplete]
18:08:21 <bknudson> since keystone isn't depending on other projs seems like there's nothing for us to do.
18:08:39 <morganfainberg> bknudson, we're mostly there already. our restfultests are sortof what they're doing
18:08:41 <ayoung> But it sure looks like a "using the service_token"  problem
18:09:07 <morganfainberg> bknudson, the integration will still be needed but some of the tests will move to functional in-tree (some of the failures are cinder specific for example)
18:09:07 <bknudson> morganfainberg: so it's not in a separate git repo?
18:09:20 <morganfainberg> bknudson, nope. it would be (in our case) in keystone
18:09:40 <dstanek> morganfainberg: that's exactly what keystone.test.system should be used for!
18:09:43 <dolphm> ayoung: thank you
18:09:52 <amakarov> hi
18:10:34 <morganfainberg> #link http://lists.openstack.org/pipermail/openstack-dev/2014-September/044766.html
18:10:59 <morganfainberg> that thread is part of it, there is also the other various threads that floated the ideas of funcitonal testing (like swift and neutron do) in-tree.
18:11:15 <bknudson> I'm just worried given how much of a mess our tests are in already
18:11:15 <morganfainberg> and irc discussions. it's been floating around a lot
18:11:36 <morganfainberg> bknudson, basically the big change is we would have a full devstack to run our functional tests in.
18:11:44 <morganfainberg> bknudson, but tempest is at it's limit.
18:11:45 <bknudson> ohhh
18:12:08 <bknudson> I did try submitting some tempest tests but then this came up so I abandoned them.
18:12:28 <dolphm> i like the direction of this, but i wish we had seen it coming sooner as a community
18:12:31 <bknudson> because it looks like they don't want keystone tests in tempest
18:12:34 <dolphm> as an inevitable need
18:13:25 <morganfainberg> bknudson, yep, tempest should be for integration not functional is the general view i've seen
18:13:28 <morganfainberg> and i don't disagree.
18:13:42 <morganfainberg> our restful cases are clearly functional
18:14:53 <bknudson> morganfainberg: so you're saying our restful cases are changed to work against devstack keystone rather than the one started by test?
18:14:55 <topol> morganfainberg, there would be *no* keystone tests in tempest???
18:15:21 <morganfainberg> bknudson, i think we should have a functional tox target that makes it so they *can* run against a live keystone server in devstack
18:15:22 <bknudson> topol: other projects will be using keystone but nothing specific to it.
18:15:22 <dolphm> topol: no keystone-only tests in tempest -- just ones that require integration across multiple projects
18:15:38 <topol> dolphm, thanks, that helps
18:15:56 <morganfainberg> bknudson, but i don't want to make it not possible to run under a local/non-devstack env. if that makes sense. (they might move out of py26/27)
18:16:00 <bknudson> as part of another test they'll probably be adding users and validating tokens
18:16:27 <dolphm> the interesting twist for us is that we only really need to do integration tests with auth_token -- it doesn't matter what service is running behind auth_token, so it might as well be a trivial stub service that just returns 200's. or echo's your auth context back in a response body
18:16:55 <bknudson> dolphm: I think we have middleware tests that essentially do that.
18:17:24 <ayoung> bknudson, yes, but middleware can't spin up a server
18:18:14 <bknudson> it would be good to test with a real SSL connection
18:18:19 <dolphm> ayoung: we *can* do that though
18:18:21 <dolphm> echo wsgi app https://github.com/dolph/keystone-deploy/blob/master/playbooks/roles/http/templates/echo.py
18:18:40 <ayoung> dolphm, good point.   I should say "we don't spin up a server"
18:18:53 <ayoung> dolphm, my point was just that the middleware tests were using stubbed data
18:19:07 <dolphm> ayoung: ++ but we could make it a real service (albeit a trivial one)
18:19:49 <dolphm> we should move on ...
18:19:50 <bknudson> we'll want tests with other openstack projects to ensure that we don't change the interface on them.
18:20:20 <dolphm> agree
18:20:21 <dolphm> #topic meeting-topic bugs
18:20:59 <dolphm> so, trying a new thing: we have a new tag in LP on bugs that should be discussed during the weekly meeting
18:21:01 <dolphm> #link https://bugs.launchpad.net/keystone/+bugs?field.tag=meeting-topic
18:21:14 <bknudson> handy!
18:21:14 <dolphm> so, the question for most of these is "should it be a release blocker?"
18:21:44 <dolphm> so, let's start with the two wishlist bugs, which i think can be discussed as one:
18:21:46 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1331884
18:21:49 <uvirtbot> Launchpad bug 1331884 in keystone "A V2 token from trust cannot be generated with user/pass" [Wishlist,In progress]
18:21:50 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1331882
18:21:51 <uvirtbot> Launchpad bug 1331882 in keystone "trustor_user_id not available in v2 trust token" [Wishlist,In progress]
18:22:03 <dolphm> basically both of them are v2 API impacting
18:22:15 <bknudson> I thought we deprecated it
18:22:42 <dolphm> bknudson: v2? or v2 trusts?
18:22:49 <bknudson> v2 api
18:22:52 <dolphm> *pending* deprecation, still
18:23:09 <dolphm> we reversed the deprecation near the icehouse release
18:23:48 <stevemar> the changes for the trustor_user_id one look good to me
18:24:05 <stevemar> its pretty straightforward
18:24:15 <stevemar> and i like the new bug tag :)
18:24:26 <dolphm> given that this is API impacting, post FF, and it's on a completely undocumented API feature (v2 trusts), i'm inclined to bump to kilo or just leave it as Won't Fix
18:24:31 <ayoung> How is trustor_user_id not available in v2 trust token?
18:24:52 <lbragstad> is jamielennox around?
18:24:58 <bknudson> neither of these look like things that obviously need to be blockers
18:25:02 <jamielennox> lbragstad: yea, i'm watching
18:25:02 <lbragstad> I believe he opened the bug originally
18:25:06 <nkinder> bknudson: it was deprecated, then the deprecation was deprecated once everyone saw the logs being spammed with deprecation warnings
18:25:09 <dolphm> ayoung: the bug description only has a trustee_user_id
18:25:29 <ayoung> dolphm, no, I see that.  I just find it hard to believe we missed that in testing, and it has gone this long.
18:25:43 <stevemar> ayoung, it's missing impersonation too
18:25:44 <jamielennox> i don't know if i  have a strong opinion on whether we should fix it at this point, particularly post RC - it was just something i found
18:25:46 <dolphm> ayoung: and the fact that it's gone on this long means it shouldn't be a blocker :)
18:25:48 <dolphm> stevemar: ++
18:26:03 <stevemar> dolphm, good point
18:26:12 <ayoung> I wonder if it happened when we moved this to the token provider?
18:26:17 <topol> dolphm +++ good logic
18:26:19 <jamielennox> right, no one has complained about it so it shouldn't be a blocker
18:26:31 <ayoung> Um,  what if it is a regression?
18:26:46 <stevemar> ayoung, wouldn't the tests have spotted that?
18:26:58 <dolphm> stevemar: v2 trusts are untested, AFAIK
18:27:00 <jamielennox> stevemar cracks me up
18:27:03 <stevemar> womp womp
18:27:04 <bknudson> even if they're not blockers we can still approve them?
18:27:04 <ayoung> stevemar, not if we missed it
18:27:16 <dolphm> v2 trusts are basically not supported
18:27:19 <stevemar> jamielennox, :D
18:27:50 <dolphm> bknudson: i'd like to -2 both of these until kilo -- unless someone wants to champion for these
18:27:53 <stevemar> then i don't think it's a regression if it's not supported
18:28:28 <lbragstad> hard to disagree with that
18:28:43 <morganfainberg> how far are we willing to go with v2 trusts it at all
18:28:57 <morganfainberg> i mean if they are "unsupported" ... do we even *want* to support them?
18:29:09 <gyee> isn't HEAT use v2 trust?
18:29:16 <morganfainberg> gyee, v3
18:29:20 <gyee> ah
18:29:21 <bknudson> would be safer from security perspective to remove support
18:29:23 <morganfainberg> gyee, afaik they use all v3 for that stuff
18:29:25 <dolphm> morganfainberg: well, we haven't supported them since the implementation AFAIK ... i don't see a reason to change that in the middle of feature freeze
18:29:38 <ayoung> http://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/providers/common.py#n87
18:29:47 <dolphm> bknudson: probably so, but we also have a flag to disable trusts altogether
18:29:47 <morganfainberg> dolphm, i mean in K, i wouldn't remove them now.
18:29:58 <dolphm> morganfainberg: ++
18:30:02 <ayoung> dolphm, lets allow a fix for the V2 token/trust thing
18:30:24 <ayoung> yeah, there are enough people stuck on V2 that theyr are going to end up using the trusts anyway
18:30:29 <ayoung> just without all of the data needed for audit
18:30:36 <dolphm> ayoung: the fixes for these are far from trivial
18:30:37 <ayoung> the fix is minimal
18:30:38 <bknudson> here's the fix: https://review.openstack.org/#/c/101829/ ?
18:30:52 <dolphm> like this mammoth function: _deal_with_trust_scope(): https://review.openstack.org/#/c/112230/4/keystone/token/controllers.py
18:30:53 <topol> ayoung, why woulkdnt we be pushing them to V3?
18:31:05 <dolphm> topol: this isn't an issue in v3
18:31:14 <morganfainberg> dolphm, pushing users to v3
18:31:14 <dolphm> topol: or is that what you're suggesting
18:31:17 <dolphm> gotcha
18:31:26 <bknudson> I was +2 on https://review.openstack.org/#/c/101829/ a few times already.
18:31:27 <topol> +++ pushing!!!
18:31:36 <stevemar> to be fair, the first change was made in june, and yeah bknudson was +2 on it
18:32:02 <ayoung> I wasn't added to it...sorry I missed it.  The fix looks good.
18:32:16 <morganfainberg> dolphm, oh gah that method...
18:32:29 <bknudson> so assuming it hasn't changed much approve and have the fix
18:32:38 <ayoung> dolphm, you have any real problem with me +2Aing that one?
18:32:41 <topol> have any of the other integrated projects adopetd V3 this time around?
18:33:04 <bknudson> topol: even keystonemiddleware doesn't really support v3
18:33:11 <lbragstad> I can take another look at it too, I had eyes on it before
18:33:13 <nkinder> heat is v3 (for trusts), right?
18:33:14 <ayoung> bknudson, I'm going to +2.  You can take it from there
18:33:17 <dolphm> ayoung: if it's introducing a risk, then yes. i haven't reviewed either
18:33:21 <jamielennox> that looks pretty good - i'd be inclined to approve the v2 trust fix given it's been there so long
18:33:21 <nkinder> or am I mistaken?
18:33:38 <morganfainberg> nkinder, correct, this is unrelated to heat
18:33:59 <ayoung> dolphm, Its adding data to the token, but it is passing tempest.  Not sure that there is any more risk including it than leaving it out
18:34:30 <ayoung> heat might need to use V2 tokens for a service that is V2 only, but someone obviously saw this
18:34:34 <nkinder> morganfainberg: userstood.  Just responding to topol's question about v3 usage
18:34:36 <morganfainberg> ayoung, adding the data isn't a big change tbh. the other one is
18:34:46 <ayoung> "the other one?"
18:34:58 <morganfainberg> ayoung, https://review.openstack.org/#/c/112230/4 the trust review
18:35:10 <ayoung> ah
18:35:18 <ayoung> morganfainberg, I'd be OK passing on that one
18:35:18 <lbragstad> https://bugs.launchpad.net/keystone/+bug/1331884
18:35:19 <uvirtbot> Launchpad bug 1331884 in keystone "A V2 token from trust cannot be generated with user/pass" [Wishlist,In progress]
18:36:10 <dolphm> so definitely hold https://review.openstack.org/#/c/112230/ for kilo?
18:36:24 <dolphm> that's much more wishlisty
18:36:25 <morganfainberg> dolphm, yes
18:36:45 <lbragstad> ok, I'll remove the meeting-topic tag from https://bugs.launchpad.net/keystone/+bug/1331882 and leave a comment on the bug report?
18:36:48 <uvirtbot> Launchpad bug 1331882 in keystone "trustor_user_id not available in v2 trust token" [Wishlist,In progress]
18:37:12 <dolphm> lbragstad: thanks
18:37:23 <dolphm> lbragstad: i already commented on the bug
18:37:27 <dolphm> lbragstad: err patch
18:37:33 <lbragstad> cool
18:37:49 <ayoung> dolphm, or even mark "won't fix"
18:37:58 <ayoung> I am not certain I want 112230
18:38:02 <morganfainberg> i'd be ok with wont fixing it.
18:38:06 <dolphm> me too
18:38:17 <morganfainberg> i'm inclined to say it's new functionality and we're not adding functionality to v2
18:38:32 <dolphm> ayoung: i'll let you dive into that - i at least want to hold it for kilo for now
18:38:39 <dolphm> morganfainberg: certainly is
18:38:48 <ayoung> morganfainberg, dolphm, ++
18:38:50 <lbragstad> dolphm: did you publish?
18:39:03 <lbragstad> dolphm: oops, wrong review
18:39:16 <dolphm> lbragstad: i was thinking i commented on the wrong review :)
18:40:03 <stevemar> lbragstad, dolphm fyi added another bug to the meeting topic list
18:40:16 <dolphm> one more wishlist bug that i just added meeting-topic to before we get into bugs:
18:40:21 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1350273
18:40:22 <uvirtbot> Launchpad bug 1350273 in keystone "Filtering services by name doesn't work" [Wishlist,In progress]
18:40:22 <dolphm> stevemar: ack
18:40:23 <lbragstad> cool, I'll update the consensus of the other trust bug too
18:40:45 <dolphm> i actually thought this merged awhile back, and it just slipped under my redar
18:41:34 <dolphm> it seems like a safe add (it's a read-only api feature), made all of our deadlines, but was just forgotten about
18:41:49 <dolphm> anyone want to save it for kilo?
18:42:45 <dolphm> i'll take that as a no
18:42:46 <stevemar> seems like a kilo move
18:42:52 <dolphm> stevemar: ?
18:43:26 <stevemar> dolphm, seems like even more impact than the trustor_id one
18:44:03 <dolphm> stevemar: want to hold it for kilo then?
18:44:25 <stevemar> thats my vote, i'll let others weigh in
18:44:44 <ayoung> its 5 lines of real code, and a slew of testing
18:44:46 <stevemar> well, i guess most of the changes are in tests
18:44:56 <stevemar> ayoung, yeah, just realized that now
18:45:01 <jamielennox> i'm ok with this - particularly since we've already merged the corresponding identity-api review
18:45:05 <henrynash> dolphm: I vote for putting it in
18:45:08 <ayoung> https://review.openstack.org/#/c/110904/5/keystone/common/sql/core.py,cm  that is the real change
18:45:28 <ayoung> and https://review.openstack.org/#/c/110904/5/keystone/catalog/controllers.py,cm
18:45:35 <ayoung> yeah....lets merge this one
18:45:43 <stevemar> meh, lets do it
18:45:47 <dolphm> let's *review* it then
18:45:50 <ayoung> need to look at the tests, but the real code looks good
18:45:59 <lbragstad> updating the bug report
18:46:13 <morganfainberg> this looks like a legitimate bug, and a trivial fix (in code) - tests less trivial but def. reviewable
18:46:30 <dolphm> i'll give it til the end of the week to get gating -- if it's not approved by then, i'll hold it for kilo
18:46:31 <ayoung> dolphm, let rephrase to avoid upsetting sensibilities;  lets *allow the* merge of this one
18:47:13 <dolphm> stevemar: CADF one?
18:47:15 <morganfainberg> dolphm, ++
18:47:19 <stevemar> dolphm, yep
18:47:20 <dolphm> stevemar: can you set the priority on that?
18:47:43 <dolphm> oh this is brad's one
18:47:46 <jamielennox> it seems to me like the service_name one is missing a controller component? where's the python side filtering happening?
18:48:29 <dolphm> jamielennox: in the decorator implementation, IIRC?
18:48:58 <dolphm> stevemar: i'm happy to see this happen in juno
18:49:02 <dstanek> are there a lot of services in a real implementation?
18:49:03 <bknudson> I like that there was already a todo for it.
18:49:21 <dstanek> this would basically always download the table and filter in the app
18:49:23 <stevemar> dolphm, yeah, if we take that out, metering ceilometer for authN events becomes much easier
18:49:48 <dolphm> stevemar: good to note
18:49:49 <jamielennox> dolphm: i don't remember the decorator actually doing filtering, it was just a policy tie-in
18:49:51 <stevemar> dolphm, i was thinking, maybe a potential backport to icehouse
18:50:04 <dolphm> stevemar: that i wouldn't want to do :(
18:50:06 <jamielennox> (maybe i'm wrong and i did a lot of stuff manually i didn't need to do )
18:50:24 <stevemar> dolphm, just putting it out there
18:51:04 <dolphm> jamielennox: hmm... worth looking into. henrynash surely knows the answer though
18:51:39 <henrynash> jamielennox: fitering is down is wrap_collection
18:51:48 <ayoung> 9 minutes
18:51:52 <dolphm> eek
18:52:00 <henrynash> (done in)
18:52:05 <ayoung> want to reserve 5 for the Kerberos issue, please
18:52:15 <dolphm> so, three more bugs that aren't wishlisty, so this is just deciding if they should be RC blockers or not
18:52:22 <dolphm> ayoung: these should be quick
18:52:24 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1313956
18:52:25 <uvirtbot> Launchpad bug 1313956 in keystone "Keystone adds role to non-existing user in specific tenant by API" [Medium,Triaged]
18:52:44 <dolphm> this is the one we've gone back and forth on ^
18:53:11 <bknudson> dolphm: what's the proposed fix/
18:53:11 <bknudson> ?
18:53:15 <bknudson> change v2 or change v3?
18:53:18 <jamielennox> henrynash: oh - cool i'd never seen that, there might be some code i can pull out..
18:53:20 <dolphm> patch is in review, but abandoned https://review.openstack.org/#/c/93982/
18:53:26 <bknudson> both of these seem like a bad idea
18:53:36 <ayoung> I say "won't fix"
18:53:40 <dolphm> bknudson: both
18:54:05 <ayoung> for SAML and the multi-backend patch we don't necessarily know all of the userids that will be possible
18:54:26 <dolphm> ayoung: will you mark the bug as such with an explanation?
18:54:28 <ayoung> lets at least punt on the fix for this release.
18:54:30 <ayoung> Will do
18:54:31 <morganfainberg> the only counterpoint to ayoung  is that we don't allow assignments to federated users.
18:54:40 <morganfainberg> ayoung, ++ punt to Kilo at the least.
18:54:41 <ayoung> morganfainberg, LDAP is not federated though
18:54:48 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1326421
18:54:50 <uvirtbot> Launchpad bug 1326421 in keystone "No endpoint ID in v3 KVS or templated catalog" [Medium,Triaged]
18:54:58 <morganfainberg> ayoung, ah, right.
18:55:03 <bknudson> oh, I thought this was talking about some kind of _member_ role.
18:55:17 <dolphm> this is going to be a mess to fix -- basically requires rewriting the KVS driver to be v3 ish
18:55:26 <dolphm> i'd rather not do that for RC
18:55:35 <jamielennox> ++
18:55:44 <morganfainberg> dolphm, ++ i'd like to deprecate the templated backend tbh. but ....
18:55:47 <dolphm> jamielennox: unlses the client is going to choke somewhere without that attr?
18:55:52 <morganfainberg> dolphm, and templated goes away so can kvs
18:56:10 <bknudson> people love templated backend
18:56:18 <dolphm> and the last one:
18:56:20 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1346211
18:56:20 <morganfainberg> bknudson, i don't have the foggiest why.
18:56:21 <uvirtbot> Launchpad bug 1346211 in keystone "keystone under apache can't handle request chunking" [Low,Triaged]
18:56:23 <bknudson> but it needs a v3 rewrite
18:56:23 <jamielennox> dolphm: not off the top of my head
18:56:24 <bknudson> it's fast
18:56:38 <dolphm> this is a long discussion, and the short of it is that keystone doesn't support chunking and we should document that
18:56:39 <morganfainberg> bknudson, we could improve the SQL one similarly.
18:56:50 <morganfainberg> dolphm, ++ that is a mod_Wsgi thing
18:56:57 <ayoung> Defer on chunking.  Needs an Apache fix to be viable, as Morgan comments in the bug report
18:57:07 <morganfainberg> ayoung, actually it is a wsgi spec issue
18:57:12 <ayoung> that too
18:57:14 <morganfainberg> ayoung, "wont fix" + doc is correct
18:57:19 <ayoung> ++
18:57:23 <dolphm> anyone want to volunteer to write a one sentence doc for this for juno? otherwise, i'll defer to kilo
18:57:29 <ayoung> OK...Kerberos in 2 minutes?
18:57:31 <morganfainberg> dolphm, i'll add a 1 liner
18:57:37 <dolphm> sold
18:57:42 <dolphm> #topic kerberos
18:58:06 <ayoung> Here's the deal with Kerberos:  we want it to be everywhere, but accept that adding an additional Binary dependency is not appropriate
18:58:15 <ayoung> (Kerberos should be done with native libraries)
18:58:21 <ayoung> this is explicitly a client issue, BTW
18:58:24 <ayoung> so...
18:58:32 <ayoung> where should the Kerberos Auth plugin live, then?
18:58:54 <morganfainberg> ayoung, as an entry point
18:58:59 <jamielennox> python-keystoneclient-kerberos
18:59:03 <morganfainberg> jamielennox, ++
18:59:04 <bknudson> stackforge?
18:59:05 <ayoung> In KC, but with out the requirements.txt entry
18:59:09 <morganfainberg> ayoung, in a separate module.
18:59:13 <ayoung> jamielennox, no
18:59:25 <ayoung> I think in the KC repo, but released a s a separate module yes.
18:59:26 <morganfainberg> ayoung, separate module, separate pacakge
18:59:33 <dolphm> jamielennox: new repo?
18:59:38 <morganfainberg> ayoung, new repo.
18:59:52 <jamielennox> yea, i looked into that before, pip doesn't handle having mutliple packages come out of the same repo well
18:59:53 <ayoung> why is that the answer?  It seems like a waste of effort?
19:00:06 <dolphm> jamielennox: ++ pbr says that's a no-go
19:00:10 <morganfainberg> ayoung, makeing separate packages from one repo is really really ugly
19:00:26 <ayoung> morganfainberg, so is splitting code out into its own repo, but for different reasons
19:00:40 <morganfainberg> ayoung, pbr also will have issues with separating packages
19:00:43 <ayoung> morganfainberg, we want to be able to ship it in a single package downstream
19:00:46 <jamielennox> i think the same thing should be done for the federation work in client that requires lxml that people got annoyed by
19:01:02 <ayoung> jamielennox, are we going to have a separate repo for Federation, too?
19:01:09 <morganfainberg> ayoung, i would advocate non-standard plugins should all be separate repos
19:01:09 <jamielennox> time
19:01:13 <ayoung> THis sounds like what the Nova folks are dealing with the drivers
19:01:17 <jamielennox> ayoung: but yes
19:01:21 <ayoung> morganfainberg, Kerberos should be come a standard driver
19:01:34 <morganfainberg> ayoung, if it has binary deps that cannot be installed everywhere, no.
19:01:36 <dolphm> and that's the nova discussion
19:01:37 <dolphm> #endmeeting