17:59:29 <morganfainberg> #startmeeting Keystone
17:59:29 <openstack> Meeting started Tue Jun  2 17:59:29 2015 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:59:32 <openstack> The meeting name has been set to 'keystone'
17:59:47 <morganfainberg> Welcome back! First meeting post summit
17:59:48 <stevemar> o/
17:59:56 <marekd> Vancouver was great!
18:00:00 <david8hu> samueldmq, I will bring my personal translator, google.
18:00:06 <breton> marekd: indeed
18:00:12 <samueldmq> david8hu, haha
18:00:22 <morganfainberg> so, lets get moving. I'm going to hold on the summit rundown until the end
18:00:29 <morganfainberg> i think we all know how the summit went
18:00:31 <ayoung> L1 is in 4 weeks
18:00:39 <morganfainberg> we were (except henrynash) there!
18:00:47 <htruta> a little bit late, bom dia as well
18:01:01 <morganfainberg> and yes L1 is rolling up on us
18:01:03 <morganfainberg> meaning...
18:01:07 <david8hu> It was nice to meet everyone in person.
18:01:08 <morganfainberg> #topic Liberty-1
18:01:21 <ayoung> liberty-1 (Jun 23-25)
18:01:27 <ayoung> #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule
18:01:30 <ayoung> 3 weeks
18:01:47 <morganfainberg> #info Liberty-1 is Spec Proposal Freeze, work on specs and review specs. Target is June 23.
18:02:07 <morganfainberg> after L1 - we will need emails for spec proposal freeze exceptions
18:02:19 <ayoung> I'll start writing them now
18:02:23 <morganfainberg> ayoung: thanks.
18:02:33 <morganfainberg> #topic What's going on with auth plugins and client?
18:02:47 <morganfainberg> bknudson: (and I assume jamielennox...who isn't here)
18:02:53 <ayoung_Eeyeore> Your welcome
18:02:53 <bknudson> y, what's going on?
18:03:07 <bknudson> are we supposed to be merging changes to auth plugins?
18:03:14 <bknudson> or are they all going to a different repo now?
18:03:28 <morganfainberg> bknudson: auth plugins must be maintained and run as they are within KSC for now
18:03:33 <morganfainberg> unless they are specifically split out
18:03:47 <marekd> morganfainberg: new plugins go to KSA only, right?
18:03:51 <gyee> they are part of the newly minted ksa repo right?
18:04:02 <morganfainberg> marekd: keystoneauth is not ready for primetime
18:04:15 <morganfainberg> keystoneauth is being worked on and will become the real-deal soon
18:04:24 <bknudson> we have openstack/python-keystoneclient , openstack/python-keystoneclient-kerberos , openstack/python-keystoneclient-saml2, openstack/keystoneauth repos
18:04:25 <morganfainberg> but if you need it sooner, it needs to land in keystoneclient
18:04:37 <breton> morganfainberg: is there a roadmap?
18:04:41 <gyee> bknudson, you are scaring me
18:04:43 <marekd> morganfainberg: in terms of federation i'd strongly advocate for proper work in ksa.
18:04:50 <morganfainberg> breton: i am hoping keystoneauth to be ready by L1
18:05:02 <breton> morganfainberg: I would really like to participate, but don't know where to start
18:05:05 <bknudson> gyee: that's why I'm bringing it up at the meeting since I have no idea what we're supposed to be doing
18:05:06 <morganfainberg> then we start working on moving things over
18:05:18 <marekd> federation plugins in KSC are kind of messy, it'd become even more messier with deprecations and backwards compatibility. jamie advised on simply adding fixed version to KSA
18:05:34 <morganfainberg> bknudson: so, -kerberos and -saml2 is about having system level dependencies
18:05:39 <morganfainberg> and often platform specific
18:05:47 <marekd> morganfainberg: ++
18:05:53 <bknudson> so these are supported repos?
18:05:54 <morganfainberg> if it's pure python minimal deps i can go in keystoneclient or keystoneauth
18:06:01 <bknudson> I don't think we ever picked them up in our product
18:06:07 <marekd> bknudson: saml2 not yet.
18:06:17 <morganfainberg> bknudson: kerberos has been released and is available.
18:06:17 <stevemar> bknudson, they arent even released yet
18:06:20 <marekd> bknudson: in fact, i think we will need with it for ksa release.
18:06:22 <morganfainberg> not sure how widespread it is.
18:06:31 <morganfainberg> if at all used
18:06:40 <marekd> bknudson: which means another project rename (ksc-federation -> ksc-saml2 -> ksa-saml2)
18:06:41 * morganfainberg wishes jamielennox was here
18:06:46 <dstanek> can they go away if we start using pbr's new optional dep feature (i don't know much about it)
18:07:01 <morganfainberg> dstanek: maybe.
18:07:24 <samueldmq> morganfainberg, I guess he got too happy with devstack working with v3 (I saw a message from him saying that)
18:07:29 <morganfainberg> dstanek: however, the whole optional dep thing is still really poor ux.
18:07:37 <morganfainberg> in python packages imo
18:07:38 <gyee> we are keeping tab on all these repos in a nice readme file somewhere right?
18:07:42 <mordred> hi
18:07:44 <gyee> right?
18:07:44 <davechen> morganfainberg:  for what's keystoneauth  is split out? this should be dump question?
18:07:57 <morganfainberg> gyee: governance/projects.yaml
18:08:02 <morganfainberg> mordred: hi
18:08:08 <dstanek> morganfainberg: maybe, but so if fighting to find the right package to install all the time
18:08:10 <marekd> davechen: so services like nova don't need to include ksc
18:08:13 <mordred> morganfainberg: I was summoned by mention of pbr
18:08:19 <anteaya> mordred: dstanek was invoking a little known pbr feature
18:08:20 <marekd> whereas they only need auth plugins.
18:08:20 <morganfainberg> mordred: optional dependencies
18:08:28 <mordred> yah. I think that's not ready for prime time yet
18:08:35 <morganfainberg> dstanek: ^^
18:08:48 <dstanek> anteaya: so little known that i only know the name :-)
18:08:55 <mordred> I believe you're talking about extras and the ability to do things like "pip install ksa[kerberos]"
18:08:58 <anteaya> dstanek: ha ha ha typical pbr
18:09:12 <dstanek> mordred: yes, exactly
18:09:18 <mordred> lifeless: ^^ we're not ready for people to start doing that yet, right?
18:09:29 <dstanek> mordred: it just mimics what distutils/setuptools does right?
18:09:32 <bknudson> how does it know what files are kerberos files?
18:09:34 <morganfainberg> mordred: is lifeless awake at this time?
18:09:40 <lifeless> no, I'm not.
18:09:46 <mordred> bknudson: more entries in setup.cfg
18:09:50 <lifeless> sec, scanning for context
18:09:51 <morganfainberg> lifeless: moar coffee then.
18:10:13 <lifeless> morganfainberg: nup, I cold turkeyed a couple years back.
18:10:21 <morganfainberg> lifeless: /impressed
18:10:30 <ayoung> lifeless, /me depressed
18:10:31 <bknudson> now he doesn't sleep
18:10:35 <dstanek> lifeless: the short, short is that we have a packaging fetish and like to have lots of them - was hoping that using pbr's extras we could stop that
18:10:46 <morganfainberg> mordred: though the pip install ksa[kerberos] would be nice.
18:11:03 <lifeless> dstanek: extras is implemented in pbr 1.0.0 and usable
18:11:07 <bknudson> could be python-keystoneclient[auth]
18:11:25 <morganfainberg> bknudson: no.
18:11:31 <marekd> so now we are all going to merge all the repos...?
18:11:35 <morganfainberg> auth should not depend on keystonelcient at all
18:11:37 <dstanek> lifeless: cool, thx
18:11:38 <lifeless> environment markers have a small glitch in the setuptools easy_install interactions tchaypo is tracking down, so that isn't quite ready.
18:11:57 <lifeless> so yeah, foo[bar] is entirely doable now.
18:11:57 <lifeless> but
18:12:01 <lifeless> two caveats
18:12:06 <morganfainberg> bknudson: but the kerberos/system specific things probably should be merged down then if this "works"
18:12:07 <lifeless> firstly, its a union with foo
18:12:21 <lifeless> foo[bar] == foo + foo's extra called bar.
18:12:32 <lifeless> (not everyone realises this)
18:12:50 <morganfainberg> bknudson: ^ which is why keystoneauth will still be a thing.
18:12:51 <lifeless> secondly, we haven't yet taught update.py in global-requirements about syncing into setup.cfg.
18:13:00 <dstanek> lifeless: can bar map to a list of packages?
18:13:04 <lifeless> That is on the cards in the short term, but its a thing to be cognizant of
18:13:09 <lifeless> dstanek: yes
18:13:33 <lifeless> dstanek: http://docs.openstack.org/developer/pbr/#extra-requirements
18:13:34 <ayoung> morganfainberg, so...kerberos and X509 client auth should probably not be an auth pluging
18:13:48 <ayoung> but rather should be some sort of session plugin
18:13:55 <ayoung> you don't just want them for auth
18:14:15 <morganfainberg> ayoung: take that up w/ jamielennox :P
18:14:21 <ayoung> morganfainberg, I did
18:14:32 <morganfainberg> ayoung: i don't want to specifically jump into session plugins here
18:14:36 <morganfainberg> vs. auth plugins
18:14:38 <morganfainberg> vs other things
18:14:43 <ayoung> morganfainberg, it is a repo naming issue
18:15:11 <ayoung> we have been talking about auth plugins, and a big part of the name kludge came from not really understanding where things should live
18:15:13 <lifeless> you can do foo[bar,quux] of course, which does what you'd think: unions them all together
18:15:13 <morganfainberg> bknudson: so i think the answer is: the stuff we split out can be merged back in and dropped *except* keystoneauth will still be a thing to specfically handle auth/session/etc
18:15:24 <morganfainberg> without needing the CRUD interface support of keystoneclient's library
18:15:28 <ayoung> we want to split upon dependency lines,
18:15:33 <morganfainberg> (silly to require crud for auth)
18:15:48 <bknudson> so do you want us to -1 everything related to auth plugins since we don't know what's going on?
18:15:54 <ayoung> most of the federation auth plugin code is common across the different Fed mechanisms, it is a session difference which determines, not the auth plugin
18:16:10 <marekd> bknudson: where, -1 in ksc ?
18:16:13 <morganfainberg> ayoung: since jamie isn't here
18:16:19 <morganfainberg> lets loop him in later and resovle this
18:16:31 <bknudson> marekd: yes, in ksc
18:16:33 <morganfainberg> right now i can't say for sure one way or another what is going on.
18:16:43 <bknudson> I haven't been looking at the other ones... don't know if anyone is.
18:16:49 <marekd> bknudson: okay, then. I agree.
18:16:57 <morganfainberg> bknudson: i have but lets defer and get jamie in
18:17:02 <marekd> bknudson: I am doing small refactors in KSA
18:17:17 <morganfainberg> bknudson: i'd like to drop the other repos. but likely keystoneclient is where things need to go for now.
18:17:20 <morganfainberg> until KSA is done.
18:17:25 <morganfainberg> s/done/ready
18:17:30 <morganfainberg> then we have to migrate over
18:17:39 <gyee> sounds like a plan
18:17:39 <marekd> morganfainberg: but l1 is roughly 3 weeks. Is it THAT long time?
18:17:39 <ayoung> morganfainberg, is ksa just going to be auth plugins?
18:17:54 <bknudson> ksa includes session
18:17:56 <morganfainberg> ayoung: it holds all the sesson, adapter, discovery code, etc
18:18:10 <morganfainberg> ayoung: the things you'd need to auth against keystone w/o the keystoneclient crud
18:18:30 <morganfainberg> ayoung: it's very specifically to make keystoneclient the crud interface and not be required for everything
18:18:47 <morganfainberg> just like you don't need novaclient to use cinderclient
18:18:48 <breton> folks, is there a description of what ksa will be? A spec or something?
18:18:55 <samueldmq> morganfainberg, removing auth from ksclient ?
18:19:06 <morganfainberg> samueldmq: yes. it is splitting the concerns
18:19:16 <samueldmq> morganfainberg, well, at least making something in charge of "just" auth
18:19:22 <samueldmq> morganfainberg, got it, thanks
18:19:39 <samueldmq> morganfainberg, auth crud api <-  :(
18:19:43 <bknudson> I think it's a good idea to split out ksa ... but it's complicating things until it's ready.
18:19:49 <samueldmq> morganfainberg, making people get confused
18:19:51 <marekd> morganfainberg: let me repeat the question - there are chances (reasonably big) that ksa will be released around l1 which is June 23rd, right?
18:20:05 <morganfainberg> marekd: i want that to be the case
18:20:15 <morganfainberg> marekd: but... i cannot answer that w/o jamielennox
18:20:17 <morganfainberg> who is not here
18:20:19 <bknudson> you want people to work on ksa so we can get it done?
18:20:20 <morganfainberg> which is why we need to defer
18:20:29 <marekd> morganfainberg: I am asking, cause in some cases it's better to star with fresh ksa without backwards compatibility spaghetti code and wait that 3 weeks.
18:20:37 <marekd> s/star/start/
18:20:46 <anteaya> liberty1 is june 23: https://wiki.openstack.org/wiki/Liberty_Release_Schedule
18:21:19 <morganfainberg> so i want this to be the case
18:21:28 <morganfainberg> but again, i repeat, i cannot answer without jamielennox at the moment
18:21:28 <marekd> anteya: so, 3 weeks or i am missing something....
18:21:37 <marekd> morganfainberg: I understand that!
18:21:45 <morganfainberg> so l1 is the target
18:21:49 <morganfainberg> ~3wks
18:21:53 <morganfainberg> it may not happen in 3wks
18:21:57 <marekd> morganfainberg: that satisfies me
18:22:04 <marekd> let's move on.
18:22:05 <morganfainberg> it may be much longer
18:22:19 <morganfainberg> ok moving on
18:22:43 <morganfainberg> #action Followup with Jamie Lennox about Keystoneauth and "ready" timetables
18:22:49 <morganfainberg> #topic Keystone IdP config API - an API to configure Keystone IdPs instead of using the config file
18:23:02 <morganfainberg> rodrigods, gabriel-bezerra o/
18:23:07 <gabriel-bezerra> hi
18:23:10 <stevemar> ohhh thats a good one
18:23:18 <henrynash> (this sounds awfully familiar)
18:23:19 <bknudson> we should be moving away from config file in general if we can.
18:23:28 <gyee> ++++++++++++
18:23:39 <gabriel-bezerra> this is a pain gyee talked about in the Federated Demo Deep Dive session in the summit
18:23:51 <gabriel-bezerra> #link https://youtu.be/dl010R-bZHw?t=17m15s
18:23:58 <gyee> only problem is we need shibboleth and mellon to be able to dynamically pull the config
18:24:21 <dstanek> gabriel-bezerra: data stored in a database?
18:24:29 <marekd> wait.
18:24:35 <marekd> are we talking SP or IDP ?
18:24:43 <ayoung> we can work on getting support into mellon
18:24:52 <gabriel-bezerra> so, we (rodrigods) would like to do that: specs and code
18:24:59 <gyee> marekd, adding a new IdP from SP side
18:25:01 <ayoung> we had already started discussions with out team's mellon maintainer
18:25:07 <gabriel-bezerra> it's about idp
18:25:26 <marekd> gabriel-bezerra: explain please
18:25:28 <ayoung> there is some prior-art, like mod_authz_mysql
18:25:28 <gabriel-bezerra> #link http://rodrigods.com/it-is-time-to-play-with-keystone-to-keystone-federation-in-kilo/
18:25:59 <gabriel-bezerra> according to him, it's about putting the part in the 'Keysonte as an IdP' section in the database
18:26:13 <marekd> gabriel-bezerra: because i think you are talking 2 thing now.
18:26:19 <henrynash> let’s also learn from the experience we had doing the domain config management API (see: https://review.openstack.org/#/c/187249/)
18:26:27 <gyee> marekd, right now, to add a new IdP from SP, one needs to write chef/puppet/ansible/your-favorite-deploy-script
18:26:29 <ayoung> Please make sure that whatever approach you take is not Keystone specific.  If Keystone needs, any SAML consumer will need it
18:26:51 <marekd> gyee: so it's SP, not IdP.
18:27:04 <gyee> marekd, right, introducing new IdP from SP
18:27:07 <ayoung> marekd, I think it needs to be any of the above
18:27:16 <ayoung> new IdP, new SP
18:27:16 <henrynash> e.g. issues doing crud of “config options” in a multi-process keystone
18:27:30 <ayoung> henrynash, +++++
18:27:34 <gabriel-bezerra> henrynash: yes, thanks for the reference
18:27:42 <dstanek> henrynash: yes, that is why i asked about a database...
18:27:43 <bknudson> we've had issues with doing crud of any objects in multi-process
18:28:00 <henrynash> bknudson: so true
18:28:02 <marekd> ayoung: in K2K we have API for that, ADFS also supports it in the runtime. I think guys simply want to do SP side.
18:28:17 <dstanek> at summit i heard someone talking about it writing to a config file and that's just going to cause problems
18:28:45 <marekd> i don't fully understand how keystone should help this, as it's more Apache thing.
18:28:48 <ayoung> marekd, yeah, we could extract it compleetly out of the Keystone code base if we had an external discovery service, but that is not how we are headed.
18:29:01 <ayoung> We put the "discover" dropdown right there on the Horizon login page
18:29:14 <gsilvis> dstanek: that might have been me.  it's not actually tenable, but we might end up doing it anyways to get a demo working
18:29:22 <dstanek> marekd: that's why we've started talking about fixing shib a mellon
18:29:29 <ayoung> dstanek, ++
18:29:29 <marekd> dstanek: yes.
18:29:39 <marekd> pretty intersting thing, would be happy to code some C
18:29:41 <gyee> this is not about discovery, its about cleanly draw a line between "administration" and "configuration"
18:29:46 <dstanek> gsilvis: demo would be good, but we shouldn't merge it
18:29:53 <gabriel-bezerra> gyee: ++
18:29:53 <gsilvis> dstanek: agree
18:30:04 <gyee> administration should be all APIs
18:30:05 <morganfainberg> so across the board yes.
18:30:06 <dolphm> gyee: ++
18:30:13 <geoffarnold_> o\
18:30:30 <geoffarnold_> We'll need it for Mercador, of course
18:30:36 <morganfainberg> however, .... if the answer is write files to disk that (config), i am against keystone growing into a CMS too
18:30:43 <marekd> ++
18:30:46 <gyee> geoffarnold, I haven't seen any code in mercador yet
18:30:58 <henrynash> morganfainberg: ++
18:31:00 <stevemar> gyee, patience my friend
18:31:06 <marekd> gabriel-bezerra: so, what's your idea?
18:31:15 <marekd> how do you want to solve this?
18:31:21 <geoffarnold_> there isn't any - empty repos right now while we get it from github to stackforge
18:31:25 <morganfainberg> marekd: i think we need to talk to shib folks
18:31:30 <marekd> morganfainberg: ++
18:31:36 <morganfainberg> and RH can take on mod_mellon
18:31:48 <marekd> morganfainberg: i see the desire for that, but I think keystone should have nothing to do with that...
18:31:55 <morganfainberg> correct
18:31:57 <gabriel-bezerra> well, I'll take these points to rodrigods and we can have more details in what we should be doing.
18:31:57 <gyee> marekd, if mellon can pull the config dynamically from (say) an endpoint, we should have a good solution there
18:32:00 <morganfainberg> this is not a keystone "thing"
18:32:02 <marekd> morganfainberg: all in all, keystone is protocol agnostic, right?
18:32:06 <marekd> morganfainberg: exactly.
18:32:10 <morganfainberg> it's a "keystone could leverage something behind it"
18:32:10 <gyee> acceptable anyway
18:32:16 <dstanek> maybe we should make sure that shib and mellon can be similar enough not to cause compat problems
18:32:17 <morganfainberg> but it would be generic
18:32:43 <morganfainberg> since neither can do this today
18:32:44 <morganfainberg> ...
18:32:45 * topol suprised no one mentioned zookeeper yet
18:32:54 <morganfainberg> topol: shhhhhhhh ;)
18:33:01 <gabriel-bezerra> and we'd just like to let you guys know we'd like to do it.
18:33:01 <marekd> let's use zookeeper and Cassandra!
18:33:04 <dolphm> topol: nevermind the elephants
18:33:10 <marekd> topol: ^^ there you are!
18:33:21 <jsavak> elastic search backend to keystone!
18:33:25 <morganfainberg> since neither are able to take this config from non-file sources at the moment
18:33:30 <morganfainberg> we have to defer this
18:33:41 <dstanek> topol: zookeeper brings death and destruction wherever it goes
18:33:45 <morganfainberg> there is not a lot we can do until the dependencies we rely on can receive this.
18:33:56 <ayoung> I think the right solution is along the lines of ADFS:  make it someone elses problem, single discovery service.  Ipsilon for us.
18:34:00 <gyee> while we are at it, store policies in zookeeper :)
18:34:12 <morganfainberg> so, yes. we should, we should reach out and ask the projects what we can do to help. we have not much else to do in Keystone
18:34:17 <marekd> dstanek: what are the technologies that don't bring death? redis does, mongo does, zookeeper does....:)
18:34:18 <geoffarnold_> i'd love to have an oslo-programmable-config service to lean on, but....
18:34:28 <bknudson> keep your PKI certs in zookeeper
18:34:31 <morganfainberg> whoa.. ok ok
18:34:32 <morganfainberg> stop
18:34:38 <gabriel-bezerra> morganfainberg, ayoung: I see.
18:34:39 <morganfainberg> enough we're getting punchy moving on
18:34:44 <gabriel-bezerra> thanks for the feedback
18:34:46 <dstanek> marekd: redis has been good to me :-)
18:35:09 <gyee> morganfainberg, its turning into a zoo here
18:35:14 <marekd> dstanek: ough, sorry, thought i had heard some bad thing about redis from your mouth...:P
18:35:18 <morganfainberg> gabriel-bezerra: marekd ayoung: please follow up with the respective projects (shib, etc) and see what you can do
18:35:29 <morganfainberg> it is out of scope of keystone though.
18:35:31 <marekd> morganfainberg: ++
18:35:38 <morganfainberg> #topic No one uses keystonemiddleware's memcache_pool
18:35:42 <morganfainberg> breton: o/
18:35:46 <breton> yep
18:35:48 <breton> there is review to ksm https://review.openstack.org/#/c/171264/
18:35:48 <breton> it fixes a critical problem in memcache pool backend of keystonemiddleware
18:35:56 <breton> it turns out, that the problem is there since the memcache pool inclusion, since original patch
18:36:08 <morganfainberg> i'm wondering if it was downstream fixed
18:36:17 <morganfainberg> honestly and not contributed for the few folks who have used it
18:36:26 <morganfainberg> it is not commonly used thats for sure
18:36:27 <breton> we in Mirantis use memcache_pool in keystone, but not in ksm
18:36:35 <bknudson> still no unit tests
18:36:43 <breton> the code there is old an not maintained. We did some fixes to memcache pool in keystone, but not in ksm.
18:36:50 <breton> does anybody even use it?
18:36:53 <morganfainberg> bknudson breton: I'm fine with dropping it.
18:36:59 <morganfainberg> no unit tests, no bug reports.
18:37:11 <bknudson> there's no unit tests for the fix... I don't know about the rest of it
18:37:20 <ayoung> drop it, see who screams
18:37:35 <morganfainberg> we still need to move away from python-memcache but i looked at the overlap with it and pymemcache, pymemcache doesn't support multiple servers but out of the box supports pools
18:38:04 <breton> I mostly wanted to hear from someone who uses it. It seems no one here does.
18:38:23 <morganfainberg> breton: based on thread.local + eventlet, everyone should be using it
18:38:23 <dstanek> morganfainberg: doesn't support hashing to different memcached instances?
18:38:30 <morganfainberg> dstanek: nope
18:38:39 <morganfainberg> dstanek: cannot connect to multiple instances at all
18:38:50 <morganfainberg> dstanek: has everything else though :(
18:38:53 <dstanek> morganfainberg: that's useless
18:39:02 <breton> morganfainberg: well, no. A lot of stuff runs eventlet in MOS and we don't use it
18:39:10 <marekd> MOS?
18:39:21 <breton> Mirantis Openstack, our distro
18:39:33 <morganfainberg> breton: this is used in lots of services and results in potential DOS - hence the thread.local fix of using the pool
18:40:02 <breton> then why there are no bug reports?
18:40:05 <morganfainberg> my guess is everyone blames another part of openstack when they get hit by FD/socket exaughstion / slowness because of eventlet
18:40:19 <morganfainberg> breton: because it is an opt-in. most people use in-process dict caching
18:40:22 <morganfainberg> with memorycache
18:40:36 <morganfainberg> but some larget deployments use memcache
18:40:42 <breton> yep. And don't use memcache_pool.
18:40:44 <morganfainberg> and those *should* use the pool.
18:40:48 <morganfainberg> but again, is opt in
18:41:01 <morganfainberg> my guess is they don't know the issue
18:41:13 <breton> err
18:41:16 <morganfainberg> and blame something else when they are slow due to eventlet + memcache thread.local
18:41:25 <breton> turn on memcache_pool -> ksm doesn't work
18:41:49 <morganfainberg> breton: since no one realizes the source of the problem, they don't look at the solution
18:41:54 <morganfainberg> breton: and therefore no one uses it
18:42:00 <ayoung> kill it
18:42:06 <morganfainberg> anyway moving on
18:42:09 <breton> morganfainberg: oh, ok.
18:42:15 <morganfainberg> propose a drop of the pool from KSM
18:42:25 <bknudson> if people are willing to maintain it then let's keep it
18:42:43 <bknudson> if the only problem is a couple of ,s that should be a reason to drop it
18:42:43 <morganfainberg> we can reachout to the ML for support/users before we approve the drop
18:42:58 <samueldmq> morganfainberg, +
18:43:01 <morganfainberg> bknudson: bit rotting code with no eyes and no support isn't worth carrying
18:43:07 <bknudson> I agree
18:43:10 <ayoung> 17 minutes left
18:43:12 <Chenhong> ++
18:43:16 <morganfainberg> bknudson: so lets reach out to the MLs
18:43:19 <breton> yep, lets move on
18:43:20 <dstanek> if this the exact same code that's in keystone?
18:43:26 <breton> dstanek: no
18:43:27 <morganfainberg> dstanek: sortofish
18:43:28 <ayoung> next topic is mine, not bretons
18:43:35 <morganfainberg> anyway.. next
18:43:39 <morganfainberg> #topic Dynamic Policy Update
18:43:41 <morganfainberg> ayoung: o/
18:43:55 <ayoung> OK...so...mega load of specs and a few code changes, too
18:44:04 <ayoung> using trello to monitor:
18:44:15 <morganfainberg> ayoung:  and subteam meeting wouldn't be a bad idea
18:44:24 <morganfainberg> you could pull in outside of keystone resources as needed that way
18:44:26 <ayoung> is anyone besides me , david8hu and samueldmq going to actually be working on this?
18:44:27 <geoffarnold_> +1
18:44:44 <ayoung> morganfainberg, I was going to ask if a subteam meeting was required here.
18:44:47 <david8hu> ayoung, yes I am.
18:44:50 <morganfainberg> not required
18:44:51 <gyee> ayoung, I have a ksm patch to enforce something
18:44:51 <davechen> ayoung: +1
18:44:54 <morganfainberg> might be worth while.
18:45:02 <gyee> ayoung, yeh, endpoint constraints
18:45:06 <david8hu> ayoung, maybe just 3 of us? :)
18:45:23 <morganfainberg> ayoung: i'd reach out on the ML see if anyone else is joining in
18:45:23 <samueldmq> gyee, need to talk to you about that post-meeting .. (endpoint binding)
18:45:23 <geoffarnold_> as long as we can all track the Trello
18:45:36 <morganfainberg> if no one else is, 3 people hardly justifies a subteam meeting
18:45:36 <samueldmq> morganfainberg, ++ so we can get people from other porjetcs
18:45:43 <samueldmq> morganfainberg, nova guys look to be interested
18:45:48 <morganfainberg> samueldmq: yeah.
18:45:48 <ayoung> there is a new card on trello for setup subteam meeting.  Provide input on that card for when
18:46:07 <morganfainberg> #action ayoung to look into subteam meeting for policy
18:46:15 <ayoung> morganfainberg, one thing that is importnatn it the policy DB
18:46:18 <morganfainberg> #link https://trello.com/b/260v4Gs7/dynamic-policy
18:46:21 <ayoung> we've nicknamed it Papai
18:46:28 <marekd> Ioram's work?
18:46:29 <ayoung> PAP==Policy Administration Point
18:46:31 <samueldmq> ayoung, o/
18:46:35 <ayoung> marekd, yes
18:46:41 <gyee> Papai the Sailor man?
18:46:52 <ayoung> there are some disconnects between their approach and how Keystone names things, but I think they are managemeable
18:47:01 <ayoung> need to figure out how to sync between the two, though
18:47:13 <samueldmq> gyee, haah
18:47:21 <morganfainberg> we need to keep moving
18:47:46 <ayoung> so, for example, if we do hierarchical roles, how do we make a change in Keystone, that shows up in Papai, and then get the resulting policy distributed out of Keystone...or do we make PAPAI a separate service in the SC?
18:48:02 <samueldmq> ayoung, yeah we need to decide whether we need a generic policy storage or not, we can revisit that later
18:48:06 <marekd> ayoung: pub-sub like service?
18:48:15 <ayoung> so the big question for Keystone team is are we willing to accept Papai as a separate server under our umbrellla
18:48:30 <samueldmq> ayoung, I think keystone should own the database, as it offers the api
18:48:41 <ayoung> samueldmq, I don't think we can avoid answering that too long
18:49:18 <bknudson> according to the big tent model the question should be is papai willing to work as an openstack project
18:49:29 <morganfainberg> bknudson: ++
18:49:42 <ayoung> Once they get the code posted, I'll set up a public demo so we can beat on it, and see what the delat is between what they've exposed and what we need from Keystone
18:49:52 <ayoung> bknudson, they have already said that they are
18:50:15 <bknudson> then I assume the tc will accept it as an openstack project
18:50:17 <ayoung> the real question is does it make sense to keep it separate.  I am leaning toward yes
18:50:19 <morganfainberg> then i don't think it's a question of it being Keystone or not Keystone, i think it's a question of it being OpenStack and something Keystone can use
18:50:36 <ayoung> morganfainberg, it would be under our team's program, though
18:50:42 <samueldmq> I still thing that should be a keystone thing
18:50:44 <morganfainberg> ayoung: there are no programs
18:50:45 <morganfainberg> :P
18:50:54 <ayoung> essentially, I could see it as a split out of the policy service from the rest of Keystone
18:51:13 <ayoung> right now,  the KC code looks for that in the identity service_type
18:51:22 <morganfainberg> ayoung: this is a bigger conversation than we can have right now
18:51:23 <ayoung> Whatever
18:51:30 <morganfainberg> lets take this to -keystone and specs
18:51:34 <morganfainberg> after the meeting
18:51:37 <lbragstad> ~ 9 minutes left
18:51:37 <gyee> watch out them congress people
18:51:39 <bknudson> maybe we need a parallel to the bug tent guidelines, which is what makes a keystone project
18:51:50 <morganfainberg> bknudson: ++
18:51:58 <bknudson> big tent, not bug tent
18:52:04 <samueldmq> hehe
18:52:07 <ayoung> bknudson, Keystone is already a Bug Tent
18:52:09 <gyee> bknudson, lmao
18:52:11 <morganfainberg> bknudson: mind taking a crack at a starting place for that with papai in mind?
18:52:29 <morganfainberg> not saying it should be under keystone or not, just that it is where we start evaluating
18:52:46 <bknudson> I could look into it.
18:52:46 <ayoung> I'll set up a subteam meeting, then
18:52:51 <morganfainberg> bknudson: thanks
18:52:54 <ayoung> and we can discuss that
18:52:54 <morganfainberg> ok next topic
18:52:57 <morganfainberg> #topic Project scoped token by name in Reseller
18:52:59 <ayoung> floor is yours
18:53:09 <htruta> ok, so... in reseller, we need to know how to get a project scoped token by name
18:53:17 <ayoung> domain + name
18:53:18 <htruta> we may have A being an is_domain project, with a project hierarchy B -> C -> A, which means that requesting a project scoped token to A, we don't know which A project we're talking about
18:53:21 <morganfainberg> ayoung: ++
18:53:26 <ayoung> and...we need to make hierarchical naming work
18:53:33 <ayoung> so it is more than a 2 level hierarchy
18:53:41 <ayoung> domain should be the "local root"
18:53:42 <htruta> I've sent an email with two proposals and was hoping we could have more time to discuss it here :/
18:54:06 <ayoung> but if we had dom1.p1.p2  versus dom1.p3.p2  we should be able to have both
18:54:14 <morganfainberg> you need to use the namespace like you do today
18:54:26 <morganfainberg> in HMT the namespace is the hierarchy though
18:54:36 <gyee> morganfainberg, would it be a UX issue if we have a deep tree?
18:54:44 <morganfainberg> gyee: not much way around it
18:55:05 <htruta> ayoung: the issue is if we wanted to have a non-domain project called dom1
18:55:07 <morganfainberg> heirarchical things cause UX headaches
18:55:10 <henrynash> htruta: so what was wrong in inclueing the the “is_domain” flag as part of the token rquest?
18:55:14 <davechen> ayoung: seem like parts of spec of dynamic policy is still WIP. we need figure out some solution for bunches of comments in those spec,then we can start coding process.
18:55:30 <samueldmq> morganfainberg, ++
18:55:32 <morganfainberg> htruta: you use dom1.<project named dom1>
18:55:36 <samueldmq> morganfainberg, experienced myself in horizon
18:55:40 <htruta> henrynash: I don't remember why, but morganfainberg said we could not do that
18:56:06 <morganfainberg> you don't get to say "i want a domain scoped token for dom x" because domains are also heirarchical
18:56:09 <htruta> morganfainberg: can we have "." in project names?
18:56:24 <morganfainberg> htruta: we need to solve the reserved character issue
18:56:27 <morganfainberg> for delimiters
18:56:34 <morganfainberg> unfortunately we don't have time today
18:56:46 <htruta> morganfainberg: ok.
18:56:57 <morganfainberg> we have allowed all characters so we have effectively caused ourselves a headache
18:57:05 <htruta> I was not considering this delimiter point
18:57:05 <morganfainberg> lets solve the delimiter issue for the heirarcy
18:57:06 <geoffarnold_> hurts how about a wiki page on this topic?
18:57:11 <geoffarnold_> htruta
18:57:15 <morganfainberg> then the answer for this becomes easy
18:57:26 <morganfainberg> maybe the heirarchy is always a list.
18:57:27 <geoffarnold_> (spelling correction!)
18:57:33 <htruta> morganfainberg: cool. so, you could answer my email in openstack-dev ML?
18:57:38 <morganfainberg> sure.
18:57:41 <morganfainberg> will response
18:57:42 <morganfainberg> last topic
18:57:45 <morganfainberg> will make this fast
18:57:49 <htruta> ok
18:57:51 <morganfainberg> #topic Shall we pull Federation Mapping Engine out of Keystone and make it separate library?
18:57:56 <henrynash> morgangainberg, htruta: not yet confinced that is_domain is not the answer….I think the only time you get multiple clashing names is between a projiect and it’s owning domain
18:57:58 <morganfainberg> marekd: stevemar: sorry for short window
18:58:10 <morganfainberg> henrynash: i am very convinced that it is not the answer
18:58:13 <marekd> There was an idea do for pullling our Mappingengine into separate library
18:58:21 <gyee> oslo.mapping
18:58:28 <morganfainberg> henrynash: will explain later
18:58:30 <morganfainberg> post meeting
18:58:30 <htruta> henrynash: we can talk in openstack-keystone later
18:58:38 <bknudson> I haven't looked at it lately, is the mapping engine "API" clean?
18:58:42 <gyee> actually, works well with oslo.policy
18:58:47 <gyee> they are sorta similar
18:58:53 <morganfainberg> bknudson: i don't see how anyone but keystone is going to use the code
18:58:54 <marekd> this could help us building a simple wrapper for testing mapping rules locally - you give mapping rules, input (credentials,) and see what it the output (user_id, group_ids).
18:59:08 <morganfainberg> i'm not seeing a benefit to it being split out *except* for a CLI tool to do a "validation"
18:59:27 <morganfainberg> which, i'm not convinced is a huge win (you could just install keystone)
18:59:33 <dstanek> validation could be done via api it we were so inclined
18:59:36 <marekd> we can either have a separate library, and the wrapper - easy to install, or make a CLI tool in the keystone: drawback, one would need to install whole keystone locally to check out the mapping rules.
18:59:36 <morganfainberg> slash-use keystone
18:59:39 <morganfainberg> dstanek: ++
18:59:42 <marekd> morganfainberg: i understand this.
19:00:01 <dstanek> marekd: what is the difference between installing keystone and the new tools?
19:00:16 <dstanek> marekd: number of deps i mean
19:00:16 <morganfainberg> we're at time. we need to continue this in -keystone
19:00:23 <marekd> ok
19:00:25 <morganfainberg> sorry.
19:00:27 <marekd> np
19:00:31 <morganfainberg> #endmeeting