17:59:53 <stevemar> #startmeeting keystone
17:59:54 <openstack> Meeting started Tue Aug  2 17:59:53 2016 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:59:57 <stevemar> ping ajayaa, amakarov, ayoung, breton, browne, crinkle, claudiub, davechen, david8hu, dolphm, dstanek, edmondsw, gagehugo, gyee, henrynash, hogepodge, htruta, jamielennox, jaugustine, joesavak, jorge_munoz, knikolla, lbragstad, MaxPC, morgan, nkinder, notmorgan, raildo, rodrigods, rderose, roxanaghe, samleon, samueldmq, shaleh, stevemar, tsymanczyk, topol, vivekd, wanghong, xek
17:59:58 <bknudson> hi
17:59:58 <openstack> The meeting name has been set to 'keystone'
17:59:59 <nk2527> o/
18:00:01 <lbragstad> o/
18:00:02 <dolphm> \o
18:00:03 <stevemar> o/
18:00:03 <Raildo> o/
18:00:03 <breton> o/
18:00:05 <rodrigods> hello
18:00:08 <rderose> o\
18:00:13 <henrynash> \\o//
18:00:13 <browne> o/
18:00:22 <stevemar> dolphm, rderose and henrynash gotta be different
18:00:24 <dstanek> o/
18:00:31 <rodrigods> stevemar, hey, cascade deletion is useful!
18:00:32 <rderose> :)
18:00:33 <rodrigods> just kidding
18:00:33 <topol> o/
18:00:39 <stevemar> we're missing gyee and samuel today
18:00:49 <dolphm> stevemar: someone has to wave back
18:00:49 <henrynash> (practicing my yoga)
18:00:55 <dolphm> stevemar: we can't all just wave in the same direction
18:00:57 <stevemar> henrynash: lol
18:01:12 <stevemar> henrynash: kudo to you if you can still get into \\o//
18:01:23 <stevemar> agenda: https://etherpad.openstack.org/p/keystone-weekly-meeting
18:01:29 <henrynash> zero chance...I'm the entertainment for the class
18:01:41 <stevemar> hehe
18:01:52 <crinkle> o/
18:01:55 <breton> ////o\\\\
18:01:58 <stevemar> wait a minute for the rest of the folks to trickle in
18:02:04 <topol> \o
18:02:28 <henrynash> breton: those spiders really get me
18:02:29 <ayoung> Oyez Oyez
18:02:33 * stevemar avoids topol because he's gonna ask about our openstackSV presentation and if i'm done the slides...
18:02:41 <adriant> o/
18:02:54 <topol> stevemar!!!!! Im comin for ya
18:02:55 <stevemar> we got critical mass, lets go!
18:03:03 <stevemar> #topic release status
18:03:18 <stevemar> we've got  a few weeks to go til newton-3! http://releases.openstack.org/newton/schedule.html
18:03:22 <stevemar> #link http://releases.openstack.org/newton/schedule.html
18:03:41 <stevemar> we've got a bunch of bugs and blueprints, see https://launchpad.net/keystone/+milestone/newton-3
18:03:52 <stevemar> good news is almost everything has patches up
18:04:04 <stevemar> so we're in decent shape
18:04:33 <stevemar> and almost all patches associated with those blueprints and bugs have been seeing good reviews
18:04:42 <stevemar> so thanks everyone for that
18:04:53 <dolphm> +2
18:05:06 <stevemar> just gotta keep it up for another 4 weeks til newton-3 and we're smooth sailing til barcelona (tapas on me)
18:05:26 * topol wish our OpenStackSV prez was in as good shape :-)
18:05:37 <stevemar> OK that was good
18:05:41 <stevemar> :)
18:05:58 <ayoung> dngit we need the OSC client support for DSRs
18:06:19 <stevemar> so if you're looking for things to review, pick a bug or BP from https://launchpad.net/keystone/+milestone/newton-3 and look for the gerrit link
18:06:27 <stevemar> ayoung: henrynash is working on that
18:06:35 <stevemar> i'm done my spiel
18:06:45 <henrynash> ayoung: DSR patch for osc is in final review
18:06:54 <stevemar> thanks again for the reviews and triaging everyone!
18:06:57 <stevemar> #topic fix cache invalidation
18:07:00 <lbragstad> #link https://bugs.launchpad.net/keystone/+bug/1607553
18:07:00 <openstack> Launchpad bug 1607553 in OpenStack Identity (keystone) "Revocation event caching is broken across processes" [High,New]
18:07:03 <stevemar> breton, lbragstad, dstanek ^
18:07:19 <breton> hey
18:07:24 <breton> i and lbragstad ran into the same issue independently: https://bugs.launchpad.net/keystone/+bug/1607553
18:07:25 <lbragstad> ok - I spent a good portion of friday trying to figure out why we can't switch to fernet
18:07:28 <dstanek> this is a fun one
18:07:38 <bknudson> so just looking at the review comments "this is a hack" and "this doesn't work"
18:07:43 <breton> patch for it doesn't fully work, but because of a technical issue
18:07:46 <bknudson> not sure what the point is of discussing it.
18:07:58 <breton> the bug is a blocker for making fernet the default
18:08:01 <stevemar> bknudson: slow down turbo
18:08:13 <breton> the patch we are talking about is https://review.openstack.org/#/c/327885/ .
18:08:24 <lbragstad> I think we need to figure out what our best option is for moving forward so that we can invalidate cache regions across processes
18:08:28 <breton> the problem with it is that it *will* break with the new release of dogpile.cache
18:08:40 <breton> because it relies on internal interfaces of dogpile.cache
18:08:45 <bknudson> so -2
18:08:57 <breton> but using internal interfaces looks like the only way in stable dogpile.cache
18:09:01 <dstanek> breton: i think that my version won't once it's working
18:09:17 <amakarov> bknudson: OTOH it's the only solution for current stable/* branches
18:09:18 <breton> the fix for the bug also needs to be backported to stable/mitaka
18:09:20 <bknudson> does dogpile.cache not accept code submissions
18:09:47 <lbragstad> bknudson they do - amakarov added support for region invalidation across processes
18:09:52 <dstanek> bknudson: the problem is (and according to dolphm we can push back) the policy for bumping version numbers in stable branches
18:10:01 <lbragstad> #link https://review.openstack.org/#/c/349704/ this is dstanek's approach to fixing the problem
18:10:09 <breton> dstanek: have you and lbragstad tested it against fernet patches?
18:10:10 <stevemar> i see amakarov's commit here: https://bitbucket.org/zzzeek/dogpile.cache/commits/all
18:10:17 <dstanek> i think this is a solved problem there and ideally that's what i'd like to use
18:10:28 <amakarov> lbragstad: but I needed to ask zzzeek for permission - it's not automatic
18:10:49 <dstanek> breton: i get similar results. less test failures, but i was still getting some
18:11:19 <breton> dstanek: is it backportable to stable/mitaka?
18:11:30 <dstanek> breton: should be, but i didn't try it
18:11:40 <amakarov> stevemar: yes, and with this update it's possible to solve the issue in oslo
18:11:43 <dstanek> but i'd rather push forward
18:12:16 <stevemar> dogpile is currently capped at 0.5.7 in stable/mitaka
18:12:37 <amakarov> stevemar: exactly
18:12:49 <breton> stevemar: can we merge one fix for stable/mitaka and completely different to master?
18:12:54 <dolphm> amakarov: what would the new version of dogpile be released as?
18:13:04 <bknudson> http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt?h=stable/mitaka#n41
18:13:10 <stevemar> breton: you ... can, it's not ideal, but it's possible
18:13:14 <bknudson> according to this dogpile.cache is not capped.
18:13:46 <stevemar> bknudson: https://github.com/openstack/requirements/blob/stable/mitaka/upper-constraints.txt#L118
18:13:49 <amakarov> I suggest using breton's patch and cap dogpile.cache to the version prior to my patch
18:14:04 <bknudson> that's not a cap that's just what is used for testing.
18:14:36 <stevemar> the one after 0.5.7 is 0.6.0
18:14:39 <bknudson> if the min version is updated then that means every deployer/packager needs to upgrade.
18:14:43 <dstanek> amakarov: i'd want to immediately follow up with the right way to do it in master
18:14:54 <breton> dstanek: me too
18:14:57 <amakarov> bknudson: yes, though if we miss dogpile.cache release with my patch with breton's on merged, we'll be in trouble )
18:14:58 <dolphm> bknudson: ? http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt?h=stable/mitaka#n118
18:15:01 <breton> dstanek: but we need to do something with mitaka
18:15:08 <lbragstad> dstanek breton but are we sure the propose path actually fixes the race conditions?
18:15:23 <bknudson> upper-constraints is what the community uses for testing. It's not a cap.
18:15:23 <breton> lbragstad: lets leave technical issue aside
18:15:36 <amakarov> dstanek: right now breton follows it )
18:15:39 <dstanek> breton: right, that's why i said we should immediately fix master
18:15:54 <breton> lbragstad: i thing we can figure it out in reviews/#openstack-keystone
18:15:54 <dstanek> lbragstad: i don't think this fixes the race at all
18:15:55 <amakarov> sounds like a consensus
18:16:13 <stevemar> bknudson: but that's what'll be laid down when the dsvm tests run
18:16:21 <dolphm> packagers are not likely going to repackage dogpile 0.6.0 just for us (potentially breaking other consumers), especially if it contains a breaking API change
18:16:33 <dstanek> unspoken alternative is to recomment revocation caching be turned off
18:16:38 <amakarov> dolphm: good point!
18:16:43 <breton> dolphm: it doesn't contain breaking api change
18:16:47 <dolphm> dstanek: so i might have to take back the idea to bump the requirement
18:16:54 <breton> dolphm: the patch relies on private stuff :(
18:16:56 <lbragstad> dstanek at least until it works properly
18:17:02 <dstanek> dolphm: i don't know that it contains a breaking api change
18:17:18 <dolphm> oh, only we would break if we upgraded, then?
18:17:27 <lbragstad> right - it breaks because we rely on internal interfaces of dogpile
18:17:30 <dstanek> dolphm: out hacks are monkey patching protected variables
18:17:31 <breton> dolphm: yes
18:17:40 <bknudson> can dogpile.cache do a fix release 0.5.8 ?
18:17:41 <dstanek> s/out/our/
18:17:43 <bknudson> probably not.
18:17:44 <dolphm> why would dogpile require a 0.6.0 release instead of a 0.5.8 release, then? because this is perceived as a feature?
18:18:01 <lbragstad> amakarov ^ ?
18:18:08 <stevemar> breton: the 0.6.0 release had an api change, they moved things around IIRC
18:18:20 <breton> stevemar: oh, ok.
18:18:26 <breton> zzz... is not here
18:18:33 <dolphm> stevemar: unrelated to this fix?
18:18:34 <dstanek> stevemar: really?j
18:18:49 <amakarov> dolphm: don't remember exactly if the patch has a bug specified (
18:19:06 <breton> ok, since dstanek has a patch, here is what i suggest
18:19:24 <breton> 1. Try his patch out, it doesn't rely on protected variables
18:19:39 <breton> 2. if it works, merge, backport, code using amakarov's new feature
18:19:39 <lbragstad> #link https://review.openstack.org/#/c/349704/
18:19:45 <stevemar> dolphm: i thought so? https://bitbucket.org/zzzeek/dogpile.cache/commits/761dc0a9e4c08f9af4b732ced3604e72d74f09af
18:19:52 <amakarov> #link https://bitbucket.org/zzzeek/dogpile.cache/issues/38/invalidate-entire-cache
18:20:02 <breton> 3. if not, figure out at the next meeting
18:20:03 <amakarov> oops... it's a bugfix
18:20:28 <breton> what do you think?
18:20:32 <dstanek> breton: i still need to figure out if the transients are my fault or not
18:20:35 <lbragstad> breton that path will require us to bump the version of dogpile for the backport - right?
18:20:42 <dstanek> that's the case for both patches i guess
18:20:46 <breton> lbragstad: dstanek's? No.
18:21:02 <dstanek> breton: lbragstad: no version bump needed for mine
18:21:11 <stevemar> breton: #2 "code using amakarov's new feature" << whats that mean?
18:21:18 <dolphm> stevemar: ++
18:21:27 <dolphm> consume it in master, maybe?
18:21:33 <breton> stevemar: ^ >  i see amakarov's commit here
18:21:46 <breton> stevemar: the one in dogpile.cache
18:22:10 <breton> stevemar: https://gerrit.sqlalchemy.org/#/c/108/
18:22:10 <lbragstad> #link https://bitbucket.org/zzzeek/dogpile.cache/commits/d521db7eb4eab4ad2bacf5f1f5fd89bd3e43a0fa
18:22:20 <stevemar> breton: hmm, his dogpile commit, has it been released yet?
18:22:37 <breton> stevemar: it is not release yet, but i guess it will soon be
18:22:48 <breton> stevemar: and when it is, "code using amakarov's new feature".
18:22:56 <stevemar> ohhhh okay
18:23:04 <bknudson> when you backport to mitaka you can have the code check for the right version of dogpile.cache before using the new features.
18:23:16 <stevemar> i get it
18:23:21 <stevemar> breton: sounds like a plan
18:23:28 <breton> bknudson: dstanek's patch won't need any version checking
18:23:43 <rodrigods> nice work on chasing this down
18:24:04 <dstanek> ok, so concensus is breton, lbragstad and i will work on making sure my patch works and we'll get that merged and backported
18:24:06 <dstanek> ?
18:24:07 <stevemar> merge dstaneks patch in master and mitaka, then using amakarov's new feature when it's released in master
18:24:09 <breton> #action breton, dstanek, lbragstad: check if patch by dstanek works not worse than https://review.openstack.org/#/c/327885/
18:24:22 <dstanek> ++ sounds good
18:24:24 <stevemar> #action breton, dstanek, lbragstad: check if patch by dstanek works not worse than https://review.openstack.org/#/c/327885/
18:24:31 <lbragstad> sweet
18:24:37 <stevemar> i was expecting some bot feedback *shrugs*
18:24:42 <stevemar> great
18:24:54 <stevemar> thanks breton, lbragstad and dstanek
18:25:00 <lbragstad> thanks for the time
18:25:06 <stevemar> np
18:25:12 <stevemar> #topic Validating trust-scoped tokens with v2.0 API
18:25:16 <stevemar> breton you're up again
18:25:20 <breton> a trust-scoped token can be obtained via v2.0 API
18:25:30 <breton> why cannot it be validated against v2.0 API?
18:25:58 <stevemar> maybe it was just overlooked? is this by design ayoung?
18:26:08 <lbragstad> I believe that was something that changed when we consolidated the fernet token provider into the common provider
18:26:09 <amakarov> good point: trust doesn't scope to domains
18:26:31 <breton> ./test_auth.py heavily relies on getting trusts via v2.0
18:26:54 <ayoung> breaking that is still a backwards non-compat change until v2.0 goes away
18:27:06 <lbragstad> I worked on getting a patch up for supporting trust auth/validate for v2.0
18:27:26 <lbragstad> #link https://review.openstack.org/#/c/278693/
18:27:29 <breton> lbragstad: for fernet or for all types of token?
18:27:39 <lbragstad> breton specifically for fernet
18:27:44 <jamielennox> is this a fernet only problem?
18:27:48 <breton> jamielennox: no
18:27:55 <breton> jamielennox: initially i found it for uuid
18:27:57 <jamielennox> i'm sure there is trust code in v2
18:27:57 <lbragstad> jamielennox nope
18:29:31 <stevemar> so this should be working with any token provider
18:29:49 <stevemar> breton: file a bug and let's get it fixed
18:30:07 <lbragstad> breton we can probably fix it with https://review.openstack.org/#/c/278693/ (once it's revived)
18:30:41 <bknudson> https://review.openstack.org/#/c/278693/ says you can validate trust with v2
18:30:41 <breton> ok
18:30:59 <bknudson> uuid
18:31:31 <stevemar> breton: file a bug for it, currently https://review.openstack.org/#/c/278693/ is missing one :\
18:31:40 <stevemar> bknudson: pki
18:32:00 <bknudson> pki what?
18:32:08 <bknudson> https://review.openstack.org/#/c/278693/ says that uuid works
18:32:39 <stevemar> bknudson: ah damn, it does eh
18:32:48 <stevemar> but breton found the bug with uuid
18:33:30 <breton> ok, i will file a bug
18:33:31 <bknudson> there's a contradiction here.
18:33:45 <stevemar> breton: yeah, let's start there, we need more info on this one
18:34:03 <stevemar> i guess the only good part is that no one has noticed this is broken
18:34:23 <stevemar> next topic
18:34:28 <stevemar> #topic Rolling upgrades
18:34:32 <stevemar> henrynash: you're up
18:34:41 <henrynash> ok
18:34:49 <stevemar> i'm just about ready to +A this spec, but if anyone else wants to chime in, now is the time
18:34:59 <henrynash> so that was first thing....
18:35:17 <henrynash> any other comments? (dtsanek, thanks for yours)
18:35:34 <stevemar> spec is here: https://review.openstack.org/#/c/337680/
18:35:54 <henrynash> 3 patches are up for implementation, starting at: https://review.openstack.org/#/c/349703/2
18:35:58 <stevemar> dolphm: ayoung lbragstad ?
18:36:12 <stevemar> and it would land for newton
18:36:51 <lbragstad> stevemar I haven't weighed in on it yet
18:36:59 <henrynash> some of the implementation is still WIP, but it IS functional, and I am closing out some corner cases, adding more testing and then add docs
18:37:09 <dstanek> henrynash: the only think i didn't quite get was the steps that appeared to be duplicated
18:37:45 <dolphm> stevemar: i was pretty happy with our discussion at the midcycle, only had a few nits on the spec itself that i don't care that much about
18:37:51 <henrynash> dstanek: so I added a comment on that...it is to prevent problems once we have on-the-fly migrations
18:38:12 <henrynash> dtsanek: but happy to followup with clarifications
18:38:33 <stevemar> okay i'll give lbragstad til EOD then punt it through
18:38:52 <stevemar> henrynash: keep workin on the code ;)
18:39:05 <lbragstad> stevemar I might not get around to it today - but I trust the judgement of others who have weighed in on it
18:39:05 <henrynash> stevemar: yes sir
18:39:08 <stevemar> henrynash: you even got a +1 from xek
18:39:16 <stevemar> lbragstad: rgr that
18:39:19 <henrynash> stevemar: yep, gonna bank that one
18:39:37 <stevemar> henrynash: turns out mulling this over for a year makes it safe
18:39:43 <stevemar> next topic
18:39:52 <henrynash> stevemar; shockin' that
18:40:08 <dstanek> henrynash: so in step #3 we have all nodes upgraded and only reading/writing from old column. after that you only need to start reading from the new column
18:40:41 <stevemar> #topic MFA
18:40:45 <stevemar> adriant: o/
18:40:50 <stevemar> sorry for the wait  :)
18:40:52 <adriant> Hey
18:40:56 <adriant> np :)
18:41:00 <adriant> so
18:41:05 <dstanek> henrynash: i thought that set #5 would actually stop using the old column altogether
18:41:09 <stevemar> spec: https://review.openstack.org/#/c/345113/ and patch: https://review.openstack.org/#/c/343422/
18:41:13 <adriant> I'd like to get MFA working in OpenStack, and easiest way without breaking anything is password+passcode concatenation.
18:41:36 <adriant> Optional MFA plugin, works like password auth
18:41:44 <stevemar> adriant: does it matter to you if this lands in N or O?
18:41:47 <adriant> just also checked TOTP if present.
18:42:01 <adriant> stevemar: N would be better, but can wait
18:42:11 <stevemar> *nods*
18:42:13 <adriant> stevemar: I can backport for our own purposes easily enough
18:42:14 <henrynash> dstanek: (whct you need to prevent is one node that thinks its Ok to write to just the new column and one thinking it only has to read from teh old column...and since I decided against a spooky entaglement at a distance lock, we need a send phase of reboots, I think)
18:42:29 <stevemar> adriant: so you guys are running something like this already correct?
18:42:33 <adriant> My main worry is the v2 api
18:42:37 <adriant> stevemar: Not yet
18:42:57 <adriant> stevemar: but the goal is to be up and running with MFA in the next 3-6 months
18:43:04 <stevemar> rgr that
18:43:06 <jamielennox> i have most of the same concerns i've had in the past once we get in to which projects require what level of 2fa, what happens when they don't ahve a totp key etc
18:43:39 <adriant> jaminelennox: I've kept per project MFA out of this spec and patch
18:43:56 <stevemar> if no TOTP key, it should act just like password auth
18:43:59 <jamielennox> and do federation, but i feel like i've beat that drum a fair bit now
18:44:01 <adriant> jamielennox: as it's a requirement that would need too much work across all of keystone to make viable
18:44:02 <stevemar> and no per-project support
18:44:21 <jamielennox> yep, ok
18:44:37 <adriant> if a project needs MFA, it is up to the project to enforce all users have it active
18:44:51 <jamielennox> most other concerns are negated by the fact we already support a totp of some form
18:45:01 <stevemar> jamielennox: it'll enable MFA support for SQL users, which as we've found out, a lot of people use -- and they won't be moving all those users to federation any time soon
18:45:24 <adriant> Should also work for LDAP users.
18:46:22 <adriant> I've suggested in the docs that disabling V2 is part of the suggested method to enable MFA
18:46:38 <stevemar> adriant: can you elaborate why it won't work with v2?
18:46:38 <adriant> as I'm not sure touching the V2 auth code for this is a good idea
18:47:04 <adriant> v2 doesn't appear to be pluggable, and unless edited, does not do the TOTP check.
18:47:04 <bknudson> we don't require tempest testing for features?
18:47:51 <rodrigods> bknudson, no :(
18:48:00 <bknudson> scary.
18:48:08 <adriant> stevemar: are there ways to edit the v2 auth without changing the default?
18:48:40 <adriant> My worry is, a user with a TOTP cred on v3 will need password+passcode
18:48:45 <adriant> on v2, just password
18:49:03 <adriant> so v2 is a way around MFA unless v2 also has some MFA changes
18:49:04 <dolphm> adriant: don't deploy v2
18:49:09 <dstanek> adriant: disable v2?
18:49:33 <stevemar> dstanek: dolphm right, that's what adriant recommended
18:49:45 <stevemar> v2 auth won't be going away for a long time
18:50:27 <stevemar> I think if the v2 auth limitation is clearly documented then it's good enough.
18:50:27 <bknudson> why doesn't v2 use the password plugin?
18:50:35 <adriant> not the v3 one
18:50:57 <dolphm> bknudson: as in, just hardcode it to use the native password plugin?
18:51:00 <adriant> bknudson: It looks to be it's own separate auth plugin
18:51:18 <bknudson> right, just like v3 auth hardcodes the "external" plugin.
18:51:31 <stevemar> https://github.com/openstack/keystone/blob/9d54eb33c1d74ff39c947af6ff984ef2e0bf4be4/keystone/token/controllers.py#L63
18:51:43 <dolphm> this seems like a rabbit hole. why does v3 hardcode the external plugin?
18:52:25 <stevemar> we could create a v2_password plugin
18:52:59 <bknudson> v3 uses the "external" plugin if there's EXTERNAL_USER or whatever it is.
18:53:03 <jamielennox> lol, don't look at auth!
18:53:19 <jamielennox> it makes you sad
18:53:28 <adriant> stevemar: yep, I've looked at how i could edit that v2 auth controller to support MFA, but I didn't want to edit older defaults.
18:53:42 <stevemar> adriant: we could just add  credential lookup to the v2 auth code
18:54:09 <adriant> stevemar: maybe, but it would need to be based on if the v3 auth is using the the "password_totp" plugin
18:54:10 <stevemar> so core team, i'm putting you on the spot here, thoughts on this? y'all are being unusually quiet...
18:54:15 <bknudson> found it: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/auth/controllers.py#n504
18:54:33 <bknudson> my opinion - we need to clean up existing keystone before adding new features.
18:54:39 <stevemar> lbragstad: dstanek bknudson dolphm jamielennox everyone, yay or nay?
18:54:40 <bknudson> otherwise we're just adding technical debt on top of debt.
18:55:11 <rodrigods> bknudson, this is something that has being raised a couple of times
18:55:18 <bknudson> and using crappy existing code as a reason to not support v2 is a poor excuse.
18:55:40 <stevemar> bknudson: in my grand scheme, PCI and MFA were the last "features" i wanted to add, then start paying off technical debt
18:55:53 <stevemar> so i'm a bit biased here
18:56:36 <rodrigods> stevemar, bknudson, can we track somewhere stuff that is simply not good enough and need to be revisited? i guess the next topic falls into that
18:56:39 <dstanek> stevemar: so what is the proposal...to fix v2?
18:56:45 <bknudson> I'm actually fine with the feature since it's optional.
18:57:07 <stevemar> dstanek: whether or not to add MFA as its designed in the currently spec
18:57:18 <bknudson> although we really need to start requiring tempest testing for features.
18:57:29 <jamielennox> i agree with bknudson, i'm concerned about the layers on layers of stuff and how you do things like message that a 2fa cred is required
18:57:38 <jamielennox> the whole pipeline through there is a disaster
18:58:03 <jamielennox> but honestly the scariest parts of this have already been merged so at this point whatever
18:58:05 <dolphm> adding totp auth support to v2 is not an API change, right?
18:58:11 <stevemar> jamielennox: the alternative is we wait until the S release to include new features :P
18:58:36 <bknudson> adding totp to v2 is as much an api change as adding it to v3.
18:58:46 <stevemar> ++
18:58:52 <adriant> dolphm: the problem isn't adding totp auth, it's adding password+totp auth
18:59:04 <stevemar> to the existing password auth
18:59:18 <stevemar> bah, move to -keystone
18:59:23 <stevemar> #endmeeting