18:00:39 #startmeeting keystone 18:00:42 ping ajayaa, amakarov, ayoung, breton, browne, crinkle, claudiub, davechen, david8hu, dolphm, dstanek, edmondsw, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, jorge_munoz, knikolla, lbragstad, lhcheng, marekd, MaxPC, morganfainberg, nkinder, raildo, rodrigods, rderose, roxanaghe, samleon, samueldmq, shaleh, stevemar, tjcocozz, tsymanczyk, topol, vivekd, wanghong, xek 18:00:42 hi 18:00:49 Meeting started Tue Apr 19 18:00:39 2016 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:50 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:52 * stevemar pokes the bot 18:00:53 The meeting name has been set to 'keystone' 18:00:55 o/ 18:00:55 \o 18:00:55 hi 18:00:55 there it is 18:00:59 o/ 18:01:00 hi 18:01:03 Oyez oyez 18:01:05 hey everyone! 18:01:16 o/ 18:01:16 o/ 18:01:19 o/ 18:01:24 heey 18:01:25 #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Main_Agenda 18:01:28 o/ 18:01:31 agenda isn't too heavy today 18:01:36 \o/ 18:01:47 * morgan waves at everyone... and goes back under a rock. 18:01:47 \\\\o//// 18:01:51 we have a keystone functional tests job! 18:01:55 henrynash: HEY no upstaging me ;) 18:01:59 (henry playing the spider)) 18:02:08 lol 18:02:15 early start it seems :-) 18:02:36 my atomic clocks says 11:02 18:02:36 rodrigods: nice! 18:02:51 henrynash: i like your ascii style 18:02:51 (my body clock says time for dinner) 18:02:53 anyone who doesn't know... Rule 1 of the Summit for Keystone: don't give ayoung a microphone ;) 18:03:02 ayoung: ^_^ 18:03:04 haha 18:03:11 my phone sayx 11:05 18:03:16 morgan: unless you want to go over schedule 18:03:16 morgan: but he takes it anyway 18:03:17 * ayoung don't need no stinken electronic amplification 18:03:23 my computer says 11:03 18:03:27 hi 18:03:27 ayoung: right...we need duct tape 18:03:36 dstanek, Duck tape. 18:03:45 It really is Duck...waterproofing 18:03:52 dstanek: gaffer tape 18:04:05 100 mph tape 18:04:13 (ayoung is indeed, the gaffer) 18:04:19 lol 18:04:20 ayoung: i never say duck unless i mean that brand, but yes agree 18:04:23 bknudson, ++ 18:04:26 ooooooookay. so. 18:04:27 #topic summit prep 18:04:37 so, not sure if you all know, there's a summit next week 18:04:40 in austin, no big deal 18:04:40 wat 18:04:45 everest? 18:04:49 stevemar, I added Federation Enhancements in the new features etherpad 18:04:51 i should get my plane tickets sorted 18:05:00 dolphm: you haven't already!? 18:05:01 I like the "drinks on topol" subtopic 18:05:06 stevemar: definitely not 18:05:08 samueldmq: :) 18:05:14 stevemar: he's probably driving 18:05:21 stevemar: hence the no plane tickets. 18:05:26 samueldmq. everybody does 18:05:26 morgan: ... 18:05:29 o/ 18:05:37 topol: o/ 18:05:38 morgan: do i really need sarcasm tags, with you! 18:05:40 samueldmq, iirc it was "hp pays" :) 18:05:40 dolphm: spending 2 hours in the airport to avoid the 1.5 hour drive seems reasonable! 18:05:47 morgan: lbragstad and i are being chauffeured 18:05:52 dstanek LOL 18:05:52 stevemar: best part is... #trollsuccess 18:05:55 ;) 18:05:58 morgan: dammit! 18:06:01 driving with a boat? 18:06:14 gyee: not cause then they'd be "on a boat"... 18:06:16 Schedule for Design sessions: https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Keystone%3A 18:06:18 amakarov: : x 18:06:23 #link https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Keystone%3A 18:07:04 we have 5 fishbowls 18:07:08 I heard we may need a boat to get around 18:07:14 meaning the ones with lots of chairs and a projector 18:07:47 I made the generic (thanks for the suggestion ayoung), so topics are stability, integration, testing, clients, new features 18:08:09 where does moving to Fernet fit in there> 18:08:10 ? 18:08:14 you can find etherpads on the actual schedule link, or here: https://wiki.openstack.org/wiki/Design_Summit/Newton/Etherpads#Keystone 18:08:16 stability? 18:08:29 ayoung: yep: https://etherpad.openstack.org/p/newton-keystone-stabilization 18:08:33 cool 18:09:07 i know some of you have separate etherpads going, if its not too hard, try to copy the content onto the one central (or at least link it) 18:09:10 ayoung: https://www.openstack.org/summit/austin-2016/summit-schedule/events/9145 18:09:25 rderose for instance ^ 18:09:39 what's the topic for the work sessions? 18:09:51 bknudson: work work 18:09:57 bknudson: basically, yeah 18:09:58 bknudson: or zug zug 18:10:25 last time i tried to have topics for the work sessions that didn't seem to go over well, agree? 18:10:30 yep 18:10:31 stevemar: okay 18:10:36 stevemar: ++ 18:10:43 everyone worked on different things 18:10:53 i'd rather just give us time to work on some of the things we discuss in the fishbowl 18:11:00 the discussions at the summit tend to push the work sessions in certain directions 18:11:07 hard to know ahead of time what those are 18:11:16 agreed 18:11:27 which is why i left them blank 18:11:30 stevemar: what's the difference between work sessions and contributors meetup? in one of those, we had parallel work streams going on in small groups for sure 18:11:43 where does rolling upgrades fit? stabilization? 18:11:54 rderose: work session? 18:11:54 rderose: i'd say so 18:11:57 stevemar, it would be good to focus on owning features by the most number of participants possible 18:12:06 rederose: I think that is database upgrades under stabalization? 18:12:07 amakarov: agreed! 18:12:20 amakarov: owner + dedicated reviewer 18:12:26 reviewer(s) 18:12:51 henrynash: cool, thx 18:13:06 dolphm: the work sessions are the ones with parallel work streams in small groups/pairs 18:13:06 stevemar, it's always simpleir to review things you understand what are they about :) 18:13:40 the code should be written so that everybody understands it 18:13:46 bknudson: ++ 18:13:47 amakarov, ++ 18:13:50 otherwise we couldn't maintain it anyways 18:13:58 any other summit-y type of questions? 18:14:04 i'm excited to see everyone again :D 18:14:15 also, it's on the agenda, so it's official "drinks on topol" 18:14:18 stevemar, can we add some final part to worksessions were people brief others what they've done? 18:14:26 topol: yay \o/ 18:14:39 topol, again?! heh 18:14:42 amakarov: hmm, is there something you had in mind? 18:14:45 * topol time to figure out some loop holes 18:14:55 topol: likes it, really he does 18:15:02 how do we find topol? 18:15:10 gyee, that is never a problem 18:15:15 gyee, topol finds you 18:15:19 amakarov: like - "what did i accomplish in this work session?" 18:15:20 hah 18:15:22 stevemar, yep - do something like a stan-up at the end of every worksession 18:15:23 gyee, easy Im gonna head to blacks BBQ sunday night 18:15:39 I like that plan 18:15:43 ++ 18:15:43 amakarov: we could try that if you'd like 18:15:48 amakarov: just remind me 18:15:55 worth trying 18:16:06 amakarov: you think it'll help keep us on track? 18:16:13 stevemar, I'd be honored, but what others think about it? ;) 18:16:30 stevemar, hope so 18:16:33 topol: I tried Rudy's BBQ last time, was great 18:16:37 amakarov: +++ 18:16:41 amakarov: should only take 5 minutes :P 18:17:01 stevemar, for seasoned scrummers - yes )) 18:17:04 samueldmq... Rudys is mediocre at best. Way better in Austin. Ask the locals 18:17:09 also, work sessions should share a single etherpad - so we don't have notes and stuff scattered everywhere 18:17:18 amakarov: let's do it then 18:17:20 dolphm: good call 18:17:24 stevemar, 5 minutes per work item otherwise 18:17:28 dolphm: ++ 18:17:31 dolphm Great idea 18:17:33 dolphm: i'll create some etherpads 18:17:42 Hopefully we'll have stronger chairs. 18:17:45 amakarov: i'll cut people off after 30 seconds :) 18:17:48 (my connection will drop for 10 mins…back in soon) 18:17:58 bknudson bah - I forgot about that 18:18:00 Almost tempted to work up something like a gant chart to track all the things we have in flight. 18:18:16 ayoung: it's a lot! 18:18:22 stevemar: i literally mean 1 etherpad for all topics in all work sessions :) with a section for each topic covered there. a lot of work session items will span multiple timeslots, so there's no point in having an etherpad per timeslot 18:18:26 * topol wondering if amakarov has new cool Russian tshirts 18:18:30 stevemar, its the dependencies that are starting to get hard to track. 18:18:49 dolphm: thanks for the clarification :) 18:19:09 dolphm: https://etherpad.openstack.org/p/newton-keystone-work-session 18:19:35 * amakarov adds an action item: "Find cool Russian t-shirt" 18:19:56 hehe 18:19:57 amakarov, in Austin, Cool Russian T-Shirt finds YOU! 18:20:09 alright, thats it for summit, any other questions ask me in -keystone 18:20:18 ayoung, I remember - Austin is weird 18:20:22 #topic Functional testing setup 18:20:25 breton: ^ 18:20:30 there was a similar spec some time ago that was moved to superseded 18:20:38 so i decided to suggest another one 18:20:51 tldr: a devstack plugin in a separate repository that would set up things. 18:20:54 https://review.openstack.org/307371 18:21:12 first i proposed to implement a plugin for federation only. I've received some feedback to make it more general and set up all functional testing related things. I have done it. 18:21:15 breton, one doubt: you mean move keystone/keystone_tempest_plugin to there? 18:21:21 that was one doubt i had 18:21:26 and forgot to ask in the review 18:21:39 rodrigods: no 18:21:52 so... what is that? 18:21:59 so...can I suggest that we use Ipsilon for testing? K2K will only get us SAML, and we'd like to test OpenIDC as well 18:22:02 rodrigods: the plugin will do only set up. Like installing shibboleth. 18:22:07 ayoung, ++ 18:22:12 breton, hmmm 18:22:20 now everything makes sense 18:22:23 shib isnot going to do OPENIDC, is it? 18:22:27 stevemar, even the name ^ 18:22:30 breton: if it doesn't live in keystone do we create another repo for it? 18:22:39 dstanek: yes 18:22:53 breton: any reason for that/ 18:23:00 is it just the plugin that's in a repo or also the tests? 18:23:12 dstanek, what do you think, may implementing SAML in keystone be easier solution? 18:23:20 ayoung: it wouldn't no 18:23:31 dstanek: the plugin expects that it has a /devstack directory in the root of the repo 18:23:37 amakarov: easier than? 18:23:39 there is an alternative to a plugin in a repo -- create directory /devstack in the Keystone tree. 18:23:53 dstanek, than devstack plugin in separate repo 18:23:57 (back) 18:24:09 its still WIP, but Patrick is still cranking on it. Is there a comparable tech to Shibboleth for OpenIDC? Something we'd have the repo set up? 18:24:22 bknudson: just the code that does setup. Installing and configuring shibboleth etc 18:24:25 amakarov: we'll still need devstack plugins even if you guys like the saml2 stuff i'm working on 18:24:38 yep 18:24:45 I'm fine with the devstack plugin being in keystone 18:24:50 bknudson: ++ 18:24:53 breton, /devstack in keystone tree is cool 18:24:57 it would provide useful documentation 18:25:01 breton: i'd rather it be in keystone so it's easier to manage 18:25:05 bknudson, ++ 18:25:07 dstanek ++ 18:25:22 breton: did you see how i implemented my devstack plugins? 18:25:32 move the work in /tests/functional to /devstack than? 18:25:47 I hope the tests are still in /tests. 18:25:48 i've split it into 2 patches -- https://review.openstack.org/307371 Functional testing setup and https://review.openstack.org/307960 Federation testing setup (which uses the repo in the previous spec) 18:25:58 dstanek: yes, i have 18:26:08 bknudson: the tests are in tempest_plugin_keystone 18:26:30 breton: that was modeled after what the gate really does 18:26:48 bknudson: in fact, there is no strong preference, i think we can still have them in /tests 18:26:59 breton, nice 18:27:06 bknudson, breton, if we are going to use the tempest plugin 18:27:09 it should remain there 18:27:17 the setup is different from the tests 18:27:25 yep. Usage of tempest plugin is optional for the spec. 18:27:44 if you use the plugin, you can run more tests 18:27:58 * ayoung likes where this is going 18:28:01 is it automatic where more tests run, or is it a config option to enable it? 18:28:05 bknudson, btw, did you see the job has been merged? 18:28:11 ayoung, ++ 18:28:22 rodrigods: I did. Waiting to see results. If it works, make it voting. 18:28:30 bknudson, ++ 18:28:34 bknudson: what is automatic? 18:28:58 breton: if the plugin is available, will federation tests run? 18:29:23 bknudson: no. The devstack plugin does only set up. Nothing related to tests. 18:29:38 (i should probably cut out tempest-related things from the spec) 18:29:39 or do the tests have to be configured to run the federation tests? 18:29:45 bknudson: i think we'd need another job to use the plugin and run the tests 18:30:09 dstanek: that would make sense 18:30:19 dstanek: or modify existing one 18:30:25 i always thought that each test suite would have a different job 18:30:34 unfortunately the details are superseded http://git.openstack.org/cgit/openstack/keystone-specs/tree/superseded/functional-testing-setup.rst 18:30:36 dstanek: (if we use tempest plugin; the modification would be minimal) 18:31:04 you wouldn't want to use the same setup for all test runs 18:31:28 why not? People have a lot of things running at the same time in production. 18:31:50 might be a problem if there was a conflict where 2 things could run at the same time for some reason 18:31:50 dstanek: i did that to clean up the repo, i can move it around 18:32:08 bknudson: exactly 18:32:20 but there's no conflict with the base tests and federation, right? 18:32:46 i don't believe there is at this point 18:32:50 there would be a conflict if you had a test for sql and for ldap 18:33:02 bknudson: probably there should be multiple plugins then. A plugin to set up federation, a plugin to set up rabbit etc. 18:33:15 makes sense 18:33:21 multiple plugins == multiple repos 18:33:28 why? 18:33:37 not subfolders? 18:33:38 lets start with one repo and worry about multiple later. 18:33:53 breton: we already have too many repos :-) 18:33:56 rodrigods: because devstack plugins are supposed to live in a git repo. 18:33:57 do LDAP in DSBE only 18:34:36 can we deprecate LDAP as the identity backend an only support Domain Specific? 18:34:48 we can use git submodules than 18:34:57 rodrigods: no, please, no 18:35:11 dstanek, lol ok 18:35:53 OK, so for now i suggest to have a plugin in Keystone main tree that would do setup of all components. If they break or conflict in the future, decouple them into repositories. 18:36:07 breton, ++ 18:36:09 breton, ++ 18:36:11 sounds okay for now 18:36:13 one step at a time 18:36:15 breton: ++ 18:36:16 the approach may change when it happens too 18:36:29 yeah, let's start simpler 18:36:33 this won't break any architecture or whatever. 18:36:46 breton: we're talking devstack plugin right? not tempest plugin 18:36:51 dstanek: yes 18:37:10 #link http://docs.openstack.org/developer/devstack/plugins.html#plugins 18:37:23 breton: ok, i modeled the /dsvm/* paths based on what the other projects where doing 18:37:49 dstanek: maybe they didn't know about devstack plugins, because they are not so old 18:38:03 there's no dsvm paths that I can find? 18:38:13 that very well could be 18:38:16 breton, would this plugin be able to setup ldap backend as well? 18:38:23 there's ./ironic/ironic_tempest_plugin 18:38:24 bknudson: maybe they've move to plugins? 18:38:25 yeah, ironic uses /devstack 18:38:27 for example 18:38:43 dstanek, there is a issue with the tempest plugin naming 18:38:48 roxanaghe: afaik you don't need a plugin to set up LDAP backend, i thought that devstack can do that out of the box 18:38:51 we must have "keystone" in it 18:38:54 lets have a "get LDAP testing a reality hackfest" at the summit 18:39:23 ayoung, ++ 18:39:23 devstack can do it, and then we need to do the DSBE stuff...not huge 18:39:38 breton, that's what I know as well, we just need to enable that in devstack 18:39:55 roxanaghe: i think you meant in the gates 18:40:01 one big use case is to transition people that were using LDAP as the Identity backend to SQL with DSBE. THus, the LDAP backed domain has to be V2 18:40:02 breton, right :) 18:40:06 "Default" domain 18:40:19 rodrigods: easy fix 18:40:29 dstanek, ? 18:40:53 ayoung: ldap working hackfest, i like it 18:40:56 rodrigods: fixing the naming 18:40:56 dstanek, ahh, sure 18:40:57 if tempest is forcing us to use a name we don't want we should fix tempest 18:41:14 bknudson, it is just how the tox plugin does the discovery 18:41:29 it looks for the folder name 18:41:33 inside the repo 18:41:47 I am going to code some things by the summit so that you could discuss 18:41:52 bknudson: I don't like having to name "keystone" inside keystone too 18:42:05 breton: PoC would be great :) 18:42:35 yep 18:43:18 alright, time for next topic 18:43:19 So...can we open discussion now? 18:43:27 ayoung, should be quick 18:43:28 my topic 18:43:33 ayoung: quick topic first 18:43:36 #topic Add protocol to identity provider using nonexistent mapping 18:43:39 rodrigods: ^ 18:43:42 just do it! 18:43:50 gyee: lol 18:43:51 ? 18:43:54 ok... so for federation we have 3 entities 18:43:54 bug 1571878 18:43:56 bug 1571878 in OpenStack Identity (keystone) "Add protocol to identity provider using nonexistent mapping" [Undecided,New] https://launchpad.net/bugs/1571878 - Assigned to Ron De Rose (ronald-de-rose) 18:43:59 idp, protocol and mapping 18:44:08 we can create a protocol using a nonexistent mapping 18:44:22 I thought that mapping was enforced 18:44:23 rodigods: use case being? 18:44:24 what happens when it tries to use the mapping and it doesn't exist? 18:44:28 but i'd suggest to have clear steps here 18:44:34 bknudson, blows up, i guess 18:44:37 didn't try it 18:44:46 1 - create idp 18:44:49 2 - create mapping 18:44:50 bknudson, you'll get a nice 500 return code 18:44:50 rodigods: ah sorry, I thought this was a feature you wanted! 18:44:51 3 - create protocol 18:44:55 that doesn't seem very friendly 18:45:13 so... we'd enforce the mapping_id while creating/updating the protocol 18:45:25 that's it... we even have someone willing to fix 18:45:27 rderose, ^ 18:45:30 we can't have more than one mapping per protocol anyway 18:45:42 I would even argue that they shouldn't even be separate resource 18:45:51 you can share mappings 18:45:57 rodrigods: ++ :) 18:46:01 i have some tests that exposes this https://review.openstack.org/#/c/307508/2/keystone_tempest_plugin/tests/api/identity/v3/test_identity_providers.py 18:46:14 your tests are going to break! 18:46:20 what if someone is relying on this broken behavior? 18:46:35 bknudson, nope! they are not waiting for an error 18:46:37 bknudson, sharing mapping? 18:46:38 bknudson: yes, someone maybe has built tools around this 18:46:48 gyee, you are probably right 18:46:54 could we merge mapping into protocol? 18:46:59 samueldmq, bknudson, V10 driver? 18:47:20 gyee, hmmm, except for testing cycle...would be nice to be able to swap between mappings 18:47:20 we already allow multiple *rules* per mapping 18:47:27 rodrigods: it's not about the driver, but the API behavior being changed 18:47:32 so in essence, you have multiple maps 18:47:37 yeah, we torqued that one up big time 18:47:39 samueldmq, hmm right 18:47:55 rodrigods: I think bknudson is concerned about people already doing it in other order, that isn't the one you propose 18:47:56 so - we essentially need to require this attribute in the jsonschema https://github.com/openstack/keystone/blob/e380a3c005aa1c045bc15ef884edf3d0e20032f7/keystone/federation/schema.py#L110 18:48:07 so...yeah, lets fix that one. 18:48:09 so that tooling would be broken if we "fix" it 18:48:33 here's the stability guidelines: http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html#guidance 18:48:40 for now, yes, only allow a protocol create/update with a valid mapping id 18:48:45 which I think argues for continuing to allow this 18:48:55 we could deprecate the old behavior 18:49:13 ayoung: ++ 18:49:22 is there really a problem with it being missing? Does it 500 or something? 18:49:45 A change such that a request which was successful before now results in an error response (unless the success reported previously was hiding an existing error condition). 18:49:52 whats the harm is having this continue? no user actually reported it (sorry rodrigods) :) 18:49:54 isn't there a way to make it not 500 and be backward compatible? 18:49:55 bknudson: I think you're right: "A change such that a request which was successful before now results in an error response " is NOT acceptable 18:49:56 bknudson, think we fall in the "unless" 18:50:16 i think we just have to live with this 18:50:25 stevemar, i'd vote for deprecate 18:50:31 We need to put some thought into Federation mapping anyway...needs to be something managable by the Federaiton admins. We should be able to lock down an Idp to map only to a subset of domains 18:50:57 this can just return an error of unauthorized just because the mapping was wrong 18:51:03 ayoung: totally agree 18:51:06 not sure, need to verify what happens in this case 18:51:24 ayoung: maybe IdP's could be domain-specific configs, 1-1 relationship 18:51:26 I was asked to implement mapping in Horizon the other day during the meetup talk. :-) 18:51:28 Let's fix the 500, make it fail with a 420 or something and focus on the debug/develop side of Federation to mitigate. 18:51:35 changing mapping is like changing policy.json 18:51:45 Like the policy tool, someone should be able to say "what would I get IFF I passdin these attributes." 18:51:47 has all sorts of security implications if we are not careful 18:51:47 passed 18:52:09 samueldmq, I argued for 1-1 ad lost , but we can't do that now. 18:52:16 at the minimal, need a mapping validation tool 18:52:24 We need to say "IdP P can map domains X,y,z" 18:52:26 "Changing an error response code to be more accurate." is acceptable as per the API change guideline 18:52:27 gyee: keystone-manage has one 18:52:35 there is the possibility of conflict, etc. 18:52:36 stevemar, it only validate syntax 18:52:45 but with the shadow table, we should be able to work around that 18:53:43 samueldmq, we got request to create a Keystone runbook as well 18:54:07 OK...gonna snag the last 5 minutes if I might 18:54:10 gyee: relly ? 18:54:11 would be nice to "compile" the mapping upon creation too 18:54:16 #topic open discussion 18:54:20 stevemar, ? 18:54:20 * stevemar hands ayoung the mic 18:54:22