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