18:02:37 <dolphm> #startmeeting keystone
18:02:37 <openstack> Meeting started Tue May 20 18:02:37 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:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:40 <openstack> The meeting name has been set to 'keystone'
18:02:55 <dolphm> welcome back from the summit :)
18:03:10 <dolphm> hopefully everyone besides btopol is decompressed enough for a meeting
18:03:26 <dolphm> #topic identity-specs repo coming soon
18:03:49 <dolphm> so to kick off juno for real, we're starting an identity-specs repo, similar to nova-specs
18:03:51 <dolphm> #link https://review.openstack.org/#/c/94119/
18:03:57 <bknudson> I'm assuming anything we have in flight now requires an identity-spec
18:03:59 <dolphm> morganfainberg: IIRC, we should have it available this friday?
18:04:02 <bknudson> any bps
18:04:09 <dolphm> bknudson: yes and no...
18:04:19 <morganfainberg> dolphm, that is the idea. by next week i'll have the basic structure in place
18:04:22 <stevemar> going forward with this eh
18:04:27 <dolphm> we can introduce a hard requirement for -specs starting in j2
18:04:40 <morganfainberg> dolphm, or well by monday of next week i should have all the supporting structure (like nova has) up for review
18:04:51 <morganfainberg> or so
18:05:01 <dolphm> so if your feature is in flight, you have some hope of avoiding writing a full blown spec... and thus some encouragement to land your feature early in the juno cycle :)
18:05:28 <dolphm> still, -specs highly appreciated for all blueprint-level changes
18:05:33 <morganfainberg> dolphm, ++
18:05:34 <dolphm> #info Mandatory for feature proposals juno-2 onward
18:05:36 <ayoung> I made a first hack of what the content will be based on the nova one
18:05:39 <dolphm> and...
18:05:40 <dolphm> #info Propose a feature spec first, and when it's approved/merged, keystone-drivers will create and manage a corresponding blueprint in LP
18:05:51 <dolphm> so, basically only keystone-drivers will be creating BP's
18:06:02 <morganfainberg> dolphm, does this mean we will be evicting the current mess of BPs?
18:06:03 <jamielennox> how does -specs affect client?
18:06:03 <ayoung> #link https://github.com/admiyo/keystone-specs/
18:06:06 <morganfainberg> from LP that is.
18:06:26 <ayoung> feel free to clone and we can resolve differences when the real one gets up and running
18:06:43 <dolphm> morganfainberg: for the most part, that's what i'm thinking (mark them as obsolete?) not sure what the best approach is, or if it should be case by case
18:06:50 <morganfainberg> dolphm, ++
18:07:03 <morganfainberg> dolphm, case-by-case but most should be obsolete
18:07:16 <dolphm> jamielennox: nova's template includes a client impact section, but i'd like to have a discrete dir for client-specific work
18:07:26 <ayoung> BP should not be obsolete if the work will still happen, but maybe someone to indicate "neeeds full spec"
18:07:49 <jamielennox> dolphm: ok
18:08:03 <morganfainberg> ayoung, so we need to figure out the correct status.
18:08:05 <dolphm> jamielennox: but since the release naming doesn't apply to the client, we'll have to create separate versioned directories as we go
18:08:12 <gyee> does keystone spec have a cross-project impact section?
18:08:18 <morganfainberg> gyee, it can.
18:08:33 <morganfainberg> gyee, i'll make sure there is a section for that
18:08:40 <gyee> morganfainberg, ++
18:08:49 <nkinder> we could mark them as obsolete and ask for the person who proposed it to implement a full spec.  That should weed out old or non-important stuff
18:09:11 <lbragstad> nkinder: that's a good diea
18:09:12 <dolphm> morganfainberg: i'd like to simply reference nova's template rather than ever maintaining our own
18:09:14 <ayoung> How about "if it does not have a full spec, it stays "new"  and "needs review" means it has a real spec?
18:09:19 <mfisch> +1 to nkinder 's plan
18:09:32 <dolphm> nkinder: that's what i was thinking
18:09:42 <dolphm> nkinder: maybe stick a warning in the whiteboards until j2, and then do that?
18:09:51 <dolphm> hopefully that'll provide sufficient notice to those not here
18:09:56 <nkinder> yeah, sort of a deprecation period
18:10:01 <dolphm> nkinder: ++
18:10:26 <ayoung> Tag as "review" once there is a real spec, I think....ignore anything that is "new"  and weed out any that stay new for past j2?
18:10:33 <nkinder> morganfainberg: do you have a security impact section in the template?
18:10:53 <morganfainberg> nkinder, haven't built the template, but i belive that nova has that section, and if not, i want it
18:10:55 <ayoung> tell people to move to "drafting" if they are actively working on it
18:11:01 <dolphm> and fair warning... nova's experience with switching to -specs was that the community wasn't particularly good at doing design work up front. we've got some experience with identity-api, but i assume we'll see the same pain. so if you want to land a j2 feature, start working on the spec asap
18:11:04 <nkinder> morganfainberg: yeah, they added one IIRC
18:11:38 <dolphm> #link https://github.com/openstack/nova-specs/blob/master/specs/template.rst nova's spec tempalte
18:11:57 <ayoung> ++
18:12:07 <dolphm> there is no cross project impact section, but i think that would be valuable for nova as well
18:12:09 <dolphm> gyee: ^
18:12:19 <morganfainberg> dolphm, ++
18:12:20 <ayoung> The security impact portion of the template is pretty decent
18:12:44 <morganfainberg> there will also be a python check job that will ensure all sections exist
18:12:50 <morganfainberg> (similar to nova's)
18:12:52 <ayoung> here it is slightly modified for Keystone https://github.com/admiyo/keystone-specs/blob/master/specs/template.rst
18:12:56 <gyee> dolphm, yes, I would imagine nova have some dependency on others as well
18:13:14 <ayoung> We need to plus up the JSON-SPEC thing...
18:13:24 <ayoung> JSON schema
18:13:27 <henrynash> (oops, sorry I’m late)
18:13:30 <dstanek> how does the assignee stuff work? as things change will a new review need to be submitted? or do we not care?
18:13:34 <dolphm> their API section overlaps our use of identity-api as well
18:14:06 <bknudson> do we have separate spec directory for API as well as client?
18:14:11 <gyee> ayoung, performance impact, nice!
18:14:14 <dolphm> dstanek: i had the same question for the nova folks -- but i'm not sure they've been doing this long enough to have an answer yet
18:14:29 <ayoung> bknudson, I'd suggest no
18:14:30 <dolphm> bknudson: we'll still have identity-api
18:14:32 <morganfainberg> bknudson, i am not sure we need it for API, we already have the identity-api repo
18:14:56 <dolphm> the REST API impact section could just link to one or more identity-api reviews :)
18:15:04 <morganfainberg> dolphm, ++
18:15:06 <lbragstad> ++
18:15:21 <ayoung> bknudson, instead, under specs, we can have client subdir parallel with juno ....
18:15:21 <lbragstad> especially if the identity api docs need updates
18:15:49 <ayoung> the spec should write the identity-api
18:16:21 <stevemar> does this mean we stop creating new blueprints?
18:16:29 <ayoung> pretty much everything you need to update the identity API is in the spec template, so don't approve a bp until the spec is close enough that you could at least submit an API review
18:16:32 <dolphm> stevemar: for everyone but keystone-drivers, yes
18:16:44 <morganfainberg> stevemar, and only create the BPs for approved specs
18:16:54 <dolphm> stevemar: when a spec is approved and merged, keystone-drivers will create a corresponding BP to track the work
18:16:54 <stevemar> gotcha
18:17:05 <ayoung> ++
18:17:14 <dolphm> i think most of these details we can work out in review as we get into the process, etc
18:17:14 <stevemar> is there a way to lock down LP so only keystone-drivers can create BPs
18:17:16 <stevemar> ?
18:17:38 <dolphm> stevemar: i asked that question as well, and i think the answer is no :(
18:17:58 <dolphm> stevemar: the bp priority attribute is the only one that is "protected" afaik
18:18:04 <dolphm> the only one we use, anyway
18:18:11 <dolphm> even "Approved" can be set by anyone
18:18:23 <morganfainberg> lame
18:18:26 <stevemar> dolphm, so we're not really going to fix the clutter in LP
18:18:31 <dolphm> or maybe i'm thinking of Approver
18:18:32 <lbragstad> we'll probably have to keep tabs to make sure any new bps coming in get redirected to specs.
18:18:42 <dolphm> stevemar: in the long run, i think we will
18:18:46 * morganfainberg wants storyboard.
18:19:33 <dstanek> why even have blueprints it the info is in git? just to link against?
18:19:50 <morganfainberg> dstanek, release management
18:20:07 <morganfainberg> dstanek, all the release management stuff still leverages LP
18:20:26 <lbragstad> and we should still be able to tag bp in commits.
18:20:26 <dolphm> morganfainberg: ++
18:20:59 <dolphm> the agenda is quite long today, so let's move on
18:21:03 <dolphm> #topic Potential Keystone Hackathon dates in San Antonio, TX for Juno
18:21:04 <dstanek> morganfainberg: ah, that sucks. hopefully that will change once everyone adopts this new methodology
18:21:19 <dolphm> #link http://doodle.com/s4g7mm9n7qyu9inh vote for dates here if you're planning on attending
18:21:21 <stevemar> i think this will make it harder for new contributors ... (d'oh topic has changed)
18:22:19 <ayoung> Just to motivate you all:  if we make it July 18th, you have to help me celebrate my Birthday
18:22:21 <dolphm> wow, already a clear preference for 9, 10, 11
18:22:32 <stevemar> that was quick
18:22:53 <henrynash> (give a core a button to click on…and they will)
18:23:03 <morganfainberg> lol
18:23:13 <stevemar> henrynash ++
18:24:03 <ayoung> If you give a core a button, he is going to want a review to go with it.  If you give him a review.....
18:24:12 <henrynash> lol
18:24:20 <nkinder> I've read too many of those books...
18:24:42 <ayoung> the people here with kids get it.
18:25:38 <dstanek> i'm good for either date - i originally thought PyOhio would overlap, but I'm good there
18:25:39 <dolphm> i'll let this run until the end of the day or so, before i pursue event space more aggressively, etc
18:25:47 <ayoung> ++
18:25:54 <ayoung> Pagination and Filtering?
18:25:56 <gyee> dstanek, PyOhio?
18:26:14 <dolphm> hoping for http://www.geekdom.com/san-antonio/events or as a backup, rackspace headquarters again
18:26:45 <stevemar> rax headquarters was nice enough
18:26:57 * lbragstad wants to try the slide
18:27:09 <ayoung> nkinder, we are not looking to piggyback the Security group meetup with the keystone one, right, just Barbican?
18:27:13 <bknudson> two geeks enter one geek leaves
18:27:17 <dolphm> oh, this'll also likely be a joint event, overlapping for a day or so with a barbican hackathon
18:27:28 <dolphm> ayoung: ++
18:27:37 <nkinder> OSSG was talking about piggybacking, but I think it would be too much
18:27:46 <dolphm> we briefly discussed M-Tu-W barbican, W-Th-F keystone in the same space
18:27:59 <ayoung> I also heard August floated.
18:28:13 <clu_> ayoung: wondering what is the state of pagination is at the moment as a follow-up to
18:28:13 <clu_> this discussion a few months back -
18:28:14 <clu_> http://openstack.10931.n7.nabble.com/keystone-Pagination-td17386.html
18:28:22 <dstanek> gyee http://www.pyohio.org/
18:28:23 <ayoung> OSSG wanted it nearer to the release data IIRC
18:28:25 <nkinder> I was thinking August for some cross-project security stuff around Jamie's common client, but August might be too late in the cycle
18:29:01 <ayoung> clu_, I still think pagination is a UI antipattern
18:29:04 <nkinder> ...that's not really OSSG though, but more of a cross-project developer hackfest around security
18:29:27 <dolphm> 30 minutes and 3 topics left :)
18:29:30 <dolphm> #topic Pagination and Filtering
18:29:37 <clu_> filtering then?
18:29:49 <dolphm> so, there was a summit session on cross-project API consistency, wherein pagination and filtering was a highly relevant topic
18:30:04 <henrynash> dolphm: ahh, didn’t see that one
18:30:10 <dolphm> and the outcome was that we need a TC-blessed API conventions repo/document that spans cross projects
18:30:18 <gyee> pagination is like a religion around here, extremist at both ends
18:30:29 <dolphm> i threw my name down on a list of people to get that going
18:30:33 <morganfainberg> dolphm, imagine my surprise
18:30:38 <morganfainberg> dolphm, the tc bit that is
18:30:53 <clu_> +++ (to oblivion) dolphm
18:30:59 <bknudson> pagination and filtering of what?
18:31:16 <bknudson> every list api?
18:31:32 <morganfainberg> bknudson, any place pagination/filtering is implemented
18:31:37 <gyee> bknudson, it has to be consistent across the board if we are going to do it
18:31:39 <morganfainberg> or is wanted.
18:31:49 <jamielennox> i was in that session, there was lots of talk of needing it - and no actual resolution to how it was to be done
18:31:58 <bknudson> how do we know where it's needed?
18:31:59 <stevemar> having it for some resources, like domains seems silly
18:32:02 <jamielennox> are you signing up for another debate?
18:32:04 <bknudson> projects?
18:32:15 <bknudson> role assignments?
18:32:16 <gyee> same with version discovery, extension discovery, etc
18:32:17 <dolphm> but with regard to pagination specifically, the only voice (that i was aware of) in the room in favor of a specific approach to pagination (jaypipes=marker/limit), agreed that server-specified next/previous links were generally more reliable across various backends (which is the problem that keystone has with ldap, sql, nosql, etc)
18:32:30 <bknudson> we will hopefully not have users and groups and those are the obvious ones
18:32:30 <gyee> they are really stack-wide initiatives that should be driven by the TC
18:32:33 <henrynash> bknudson: so when I implemented a version of this back in the day (Grizzly?), it pushed pagination into teh backends the way we pushed filtering into teh backends, using the driver_hints concept
18:32:46 <jaypipes> dolphm: agreed.
18:33:02 <dolphm> s/more reliable/more implementable/ ?
18:33:19 <dolphm> most likely to not be unimplentium
18:33:35 <bknudson> we could implement it would just be very slow anyways
18:33:52 <dolphm> yeah...
18:34:03 <dolphm> so not viable with any real scale
18:34:31 <henrynash> dolphm: if we do decide to do it, I’m up for doing the implementation, since I attempted it before
18:34:33 <dstanek> prev & next links are the right way to go
18:34:37 <gyee> but slow is not an API thing, its a backend thing
18:34:57 <gyee> so deployer have the options for different backends
18:35:21 <dolphm> gyee: the problem with enforcing expectations of a specific approach like marker/limit is that it's exposing implementation details to the client, so an interface problem becomes a performance problem
18:35:51 <bknudson> if you want to be able to scroll to any page in a large table then following next links is going to be slow
18:36:07 <gyee> dolphm, no where in the API spec mention anything about peformance
18:36:18 <gyee> or expected performance
18:36:19 <ayoung> dolphm, I like your approach:  we return 200 results max.  Select 201.  If we get 201 "more results, please filter"
18:36:34 <gyee> it has always been a deployer enhancement
18:36:41 <dolphm> bknudson: even the horizon guys agree that filtering is a better solution that a billion direct links to pages
18:36:45 <henrynash> bknudson: and if you really ARE having to scroll lots an dlots of pages, you’re probably screwed anyway
18:37:08 <clu_> what type of filtering is in place today?
18:37:31 <henrynash> clu_: I think we’re in good shape with filtering as far as the SQL backend is concrened
18:37:40 <dstanek> that's for GUI access - what about building tooling? i may really want a list of all 1000 of a customer's projects
18:37:46 <dolphm> clu_: quite a bit https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md
18:38:11 <ayoung> LDAP in general supportes pretty good filtering, but I have not tested our backend code with it.  I have a pretty hefty user-DB I can load it up with and see...
18:38:23 <dstanek> i think filtering is a better solution in most cases, but can't replace everything
18:38:30 <bknudson> we could do approximate filtering with LDAP
18:38:36 <lbragstad> I thought jamielennox had a presentation at the summit about performance with LDAP?
18:38:39 <ayoung> dstanek, why would you want that paged?
18:38:42 <gyee> ayoung, LDAP is supposed to be optimize for lookup, if your LDAP is slow, always blame the configuration :)
18:39:03 <ayoung> gyee, I hear HP is really good at optimizing slow LDAP queries from Keystone.
18:39:07 <jamielennox> lbragstad: wasn't me
18:39:18 <henrynash> ayoung: :-)
18:39:27 <ayoung> lbragstad, it was  GoDaddy,  AD != LDAP
18:39:30 <gyee> ayoung, I'd blame HP LDAP too
18:39:45 <dstanek> ayoung: paging is usually easier for the server (especially in cases where the process could monopolize the CPU) and it makes caching possible
18:39:52 <clu_> henrynash, dolphm: wow, did not know that :) nice
18:39:56 <lbragstad> ayoung: jamielennox yep
18:40:09 <nkinder> filtering support/performance in LDAP is generally good, but you need to do things like define indexes on the LDAP servers (which is implementation dependent)
18:40:26 <dolphm> 20 minutes, 2 topics remaining :)
18:40:34 <bknudson> timeboxing
18:40:44 <ayoung> clu_, to be clear, pagination with LDAP is a bad thing...
18:40:45 <henrynash> clu_: …..and for SQL we pass the filter into the SQL query itself, but for ldap (today) we post-process the filer
18:41:00 <ayoung> LDAP does not return results in the same order for the same query
18:41:14 <ayoung> so you need to maintain a connection...which quickly can overwhelm an LDAP server
18:41:16 <bknudson> SQL doesn't have to return results in the same order
18:41:23 <dolphm> henrynash: but we expose the desired filtering to the ldap driver, which ignores them, correct?
18:41:32 <gyee> for pagination, its really about API consistency, implementation is a different matter
18:41:34 <henrynash> dolphm: yes
18:42:05 <henrynash> bknudson: you can ensure that by asking sqlalchemy to enforce that
18:42:18 <dolphm> so, it sounds like we need to write a -spec for ldap filtering, and pursue the cross-project api conventions repo (ping me later if you'd like to be involved in that effort)
18:42:24 <dolphm> #topic Split of middleware (auth_token, etc) out of keystoneclient to separate repo
18:42:25 <dolphm> morganfainberg: o/
18:42:32 <gyee> dolphm, ++
18:42:34 <morganfainberg> o/
18:42:44 <morganfainberg> so i think generally speaking there is a desire to split the middleware from ksc.
18:42:44 <dstanek> dolphm: pick me, pick me!
18:42:51 <ayoung> Don't do it!
18:42:59 <ayoung> You will have to change everyones config file
18:43:08 <morganfainberg> ayoung, there has been more and more requests to make this happen.
18:43:14 <dolphm> morganfainberg: someone also suggested building two packages out of the same repo, with different deps... is that viable? i feel like that's been shot down by infra before
18:43:22 <ayoung> what is the justification for that request?
18:43:23 <morganfainberg> dolphm, i don't think that works well
18:43:25 <dolphm> or maybe that was when openstack built its own packages
18:43:38 <morganfainberg> ayoung, limiting extra requirements for the ksc installs.
18:43:45 <jamielennox> it can be done via RPM etc, i don't think it works well for pip packages
18:43:53 <ayoung> jamielennox, ++
18:43:54 <dstanek> dolphm: that's a bad idea and a pain long term
18:43:58 <dolphm> jamielennox: ++ i bet that was it
18:44:05 <ayoung> that is why the repo is called python-keystoneclient...pip required that
18:44:12 <gyee> isn't there an python-openstacksdk repo already, that's for all the clients right?
18:44:14 <dolphm> dstanek: fair enough, i'm not advocating for it, just echoing a seemingly lazier solution
18:44:25 <jamielennox> so there are two things, 1st you are going to have a circular dependency between the two libs
18:44:30 <ayoung> lets discuss why...what do you think we are going to limit by splitting auth token from client:
18:44:34 <dstanek> it would be very confusing me thinks
18:44:36 <gyee> so keystoneclient, the CRUD part, may eventually end up in there right?
18:44:48 <jamielennox> 2nd if we are going to make people change configs like that then let's fix it first
18:45:03 <morganfainberg> ayoung, it is to make it so we can release auth_token without KSC as well as limit deps on both sides.
18:45:12 <ayoung> #link http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/middleware/auth_token.py#n146
18:45:25 <jamielennox> this would be the time to get rid of all those deprecations and just general crap
18:45:33 <morganfainberg> ayoung, and i think those two arguments are valid alone. security issue in auth_token, release a new one doesn't affect KSC
18:45:46 <morganfainberg> directly that is.
18:45:53 <ayoung> from oslo.config import cfg  is used by the CLI and by ATM, so if we split, and drop the CLI, we drop that one
18:46:20 <ayoung> from keystoneclient.middleware import memcache_crypt
18:46:36 <morganfainberg> the #1 request is to remove memcache from the dep in ksc
18:46:42 <ayoung> OK, I can see that
18:46:53 <morganfainberg> i'll be doing that w/ dogpile, but no reason to add dogpile to ksc
18:46:57 <bknudson> so ksc can't depend on auth_token?
18:47:04 <morganfainberg> bknudson, correct.
18:47:09 <bknudson> because if it does than ksc will still require all the deps
18:47:19 <ayoung> bknudson, dep should be the other way round
18:47:22 <bknudson> so we'd copy-paste auth_token rather than import it?
18:47:31 <bknudson> for backwards-compat
18:47:33 <morganfainberg> bknudson, ah yeah.
18:48:00 <bknudson> or do we import it without the dep?
18:48:14 <gyee> how do we do that?
18:48:22 <ayoung> no copy-paste.  that bad
18:48:33 <bknudson> we'd have to attempt to import and fail if it couldn't be imported
18:48:35 <morganfainberg> ayoung, circular imports = bad.
18:48:54 <ayoung> like crossing the streams
18:49:12 <ayoung> so this new repo...python-keystonemiddleware?
18:49:21 <dolphm> just keystonemiddleware i'd assume
18:49:28 <bknudson> does it contain the other middleware?
18:49:32 <morganfainberg> dolphm, ++
18:49:33 <morganfainberg> bknudson, it could.
18:49:34 <dolphm> bknudson: yes
18:49:34 <ayoung> bknudson, yeah, s3
18:49:45 <ayoung> http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/middleware
18:50:07 <dolphm> morganfainberg: let's write a spec for this to work out what belongs where if we introduce a new repo?
18:50:11 <ayoung> There is an ec2 version, too, which I think is still in Keystone
18:50:13 <bknudson> I think people are still importing s3_token middleware from keystone
18:50:16 <morganfainberg> dolphm, sounds good
18:50:26 <dolphm> morganfainberg: and by "let's" i mean "you"
18:50:29 <gyee> morganfainberg, that cross-project section will be long :)
18:50:33 <morganfainberg> dolphm, ++
18:50:37 <ayoung> http://git.openstack.org/cgit/openstack/keystone/tree/keystone/middleware/ec2_token.py
18:50:42 <dolphm> #action morganfainberg to write a -spec to introduce keystonemiddleware repo
18:50:51 <dolphm> #topic Add LDAP connection pool
18:51:00 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1320997
18:51:01 <uvirtbot> Launchpad bug 1320997 in keystone "Identity Ldap driver connection pooling" [Undecided,New]
18:51:04 <dolphm> gyee: o/
18:51:18 <bknudson> I thought this was already proposed.
18:51:19 <gyee> what do you guys think about this https://pypi.python.org/pypi/ldappool/1.0
18:51:42 <gyee> bknudson, is there a review already?
18:52:02 <ayoung> So long as it is optional, I think we should provide a way to test out pooling.
18:52:05 <bknudson> oh, maybe I just saw the bug
18:52:12 <dolphm> bknudson: ++ i recall connection pooling at some point
18:52:19 <dolphm> bknudson: brand new bug
18:52:28 <ayoung> the LDAP pooling story might be different for Eventlet and Apache.  nkinder ?
18:52:38 <gyee> k, we have some poc code and it seems to give us 30% improvement
18:52:55 <dolphm> my googling is not turning up any prior art
18:53:27 <dolphm> #link https://pypi.python.org/pypi/ldappool/1.0
18:53:30 <gyee> only issue is that ldappool doesn't support client cert at the moment
18:53:31 <nkinder> ayoung: for using httpd to perform auth up front, sssd would handle pooling
18:53:43 <gyee> but I don't think 2-way SSL is required
18:53:49 <dolphm> gyee: sounds like an upstream issue that can be solved :)
18:53:55 <gyee> dolphm, yes
18:53:57 <ayoung> nkinder, what about existing LDAP approach?
18:54:09 <nkinder> ldappool is something that Mozilla developed, which is the only Python implementation that I know of
18:54:22 <gyee> I can do a pull request for ldappool
18:54:30 <dolphm> nkinder: is it in use? basically zero downloads on pypi
18:54:41 <nkinder> ayoung: We could have httpd use PAM for auth, which will call into sssd and go against LDAP
18:54:48 <nkinder> dolphm: I've never seen it used
18:54:56 <nkinder> only heard about it via google searching
18:55:13 <dolphm> worth evaluating at least
18:55:23 <henrynash> ayoung: you mean support for pooling via our “LDAP driver underneath keystone identity” approach?
18:55:30 <ayoung> henrynash, yeah
18:55:43 <gyee> ayoung, I can make it configurable
18:55:49 <henrynash> ayoung: which I suspect will contiue to be the standard way for a while
18:56:06 <henrynash> standard = most used
18:56:07 <nkinder> why bother if we can just leverage httpd/sssd?
18:56:41 <gyee> nkinder, is apache in devstack for keystone already?
18:56:46 <nkinder> I agree with henrynash that the LDAP driver will be the standard way for a while, but the more effort we put into it the less we put towards a better long term approach
18:56:50 <ayoung> nkinder, cuz we are not there yet.  But I agree, that is the right long term approach.
18:56:59 <nkinder> gyee: yes, I believe so
18:57:18 <dolphm> gyee: yes
18:57:26 <gyee> ayoung, nkinder, I totally agree, but unless we standardize apache for keystone, we need something to improve performance right now
18:57:29 <henrynash> nkinder: agreed, it wil be a balance, how much to we “backport” to the old way of doing things, standard dev problem!
18:57:32 <dolphm> i don't think we gate on httpd anywhere, though?
18:57:34 <ayoung> nkinder, could the OS provide us some sort of LDAP connection pool?
18:57:40 <nkinder> gyee: APACHE_ENABLED_SERVICES+=key
18:57:43 <dolphm> nkinder: +++
18:57:54 <dstanek> dolphm: afaik we do not
18:58:08 <nkinder> we should gate on httpd though
18:58:18 <mfisch> thanks nkinder I was wondering the same
18:58:20 <ayoung> nkinder, morganfainberg is working on it
18:58:23 <dolphm> dstanek: that's going to be super important, as we can't currently gate on a federation configuration otherwise
18:58:30 <nkinder> ayoung: I know
18:58:42 <nkinder> we should gate on httpd, and we should gate on LDAP
18:58:49 <morganfainberg> nkinder, working on both
18:58:50 <dolphm> nkinder: ++
18:58:54 <henrynash> gyee, dolphm: I think at some point we are going to have to decide if we mandate apache for keystone or not…I’m a little leary of doing it, but I can see the advantages starting to stack up
18:58:54 <nkinder> morganfainberg: ++
18:58:58 <dolphm> morganfainberg: link or anything?
18:59:05 * dolphm 2 min
18:59:05 <mfisch> +1 to gating on LDAP
18:59:12 <ayoung> we currently have non voting job
18:59:14 <gyee> henrynash, I totally agree
18:59:16 <morganfainberg> dolphm, the LDAP one is not setup yet, working on apache_services now
18:59:21 <morganfainberg> dolphm, we already have a non-vote job
18:59:31 <mfisch> enfranchise it
18:59:32 <morganfainberg> dolphm, and compressed tokens should help fix the failures there
18:59:34 <dolphm> henrynash: i don't see any advantages for *not* using httpd, do you?
18:59:49 <dolphm> except for pki tokens being large :)
19:00:00 <ayoung> check-tempest-dsvm-full-apache-services   right morganfainberg ?
19:00:02 <morganfainberg> dolphm, henrynash, if we mandate httpd, we shoudl ensure we can use unicorn/nginx/uwsgi/etc
19:00:03 <gyee> I am all for apache
19:00:06 <morganfainberg> dolphm, henrynash, not just apache.
19:00:08 <morganfainberg> ayoung, yes
19:00:09 <henrynash> dolphm: I think it’s more of a configuration in people’s products and/or deploymetns prolems
19:00:11 <gyee> how soon can we get it in there?
19:00:17 <bknudson> it's easier to keystone-all than set up apache
19:00:29 <dolphm> morganfainberg: ++ but i'd like to choose a single container for doc purposes
19:00:31 <dolphm> and testign
19:00:32 <ayoung> bknudson, its easier to secure apache than keystone-all, though
19:00:40 <dolphm> s/container/server/
19:00:43 <dolphm> time!
19:00:54 <dolphm> #endmeeting