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