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