18:00:14 <stevemar> #startmeeting keystone 18:00:15 <openstack> Meeting started Tue Sep 13 18:00:14 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:18 <openstack> The meeting name has been set to 'keystone' 18:00:20 <stevemar> hey everyone! 18:00:23 <topol> o/ 18:00:24 <gagehugo> o/ 18:00:28 <spilla> o/ 18:00:28 <ezpz> o/ 18:00:29 <jaugustine> o/ 18:00:29 <knikolla> o/ 18:00:34 <dolphm> o/ 18:00:36 <nk2527> o/ 18:00:47 <raildo> olá! o/ 18:01:08 <dstanek> o/ 18:01:12 <stevemar> topol: joining us today :) 18:01:20 <rderose> o/ 18:01:20 <stevemar> henrynash is AFK, on a plane 18:01:28 <gagehugo> no wifi? 18:01:31 <jamielennox> o/ 18:01:37 <stevemar> gagehugo: excuses excuses eh 18:01:42 <jaugustine> $10 for a flight ?! pshhh 18:02:00 <stevemar> #link agenda: https://etherpad.openstack.org/p/keystone-weekly-meeting 18:02:11 <bknudson> hi 18:02:15 <stevemar> hey bknudson 18:02:29 <stevemar> i think we're at a close enough consensus 18:02:39 <stevemar> we need ayoung and lbragstad eventually 18:02:40 <anteaya> quorum 18:02:45 <breton> o/ 18:02:48 <ayoung> I was here first 18:02:48 <stevemar> anteaya: tru tru 18:02:51 <lbragstad> stevemar i'm here homes 18:02:53 <stevemar> ayoung: damn 18:02:59 <stevemar> i give up 18:03:06 <rodrigods> o/ 18:03:08 <lbragstad> stevemar need a nap? 18:03:08 <ayoung> 2 laws of thermo 18:03:12 <stevemar> #topic project stuff 18:03:19 <ayoung> 1. you can't win, best you can do is break even 18:03:25 <ayoung> 2. you can't break even 18:03:40 <stevemar> if you're interested in serving as PTL, send a review request 18:03:59 <stevemar> i think to here: https://github.com/openstack/election 18:04:01 <notmorgan> o/ 18:04:02 <ayoung> https://review.openstack.org/#/q/status:open+project:openstack/election 18:04:06 <dolphm> mailing list is also appreciated / helps advertise your candidacy, but it's not a required step anymore 18:04:13 <stevemar> dolphm: ++ 18:04:34 <stevemar> #topic newton release status 18:04:56 <stevemar> we'll be tagging RC1 this week 18:05:03 <samueldmq> hi keystoners 18:05:03 <stevemar> so keep an eye out for critical bugs 18:05:32 <ayoung> where are we WRT KSA and KC releases relative to the Newton release? 18:05:33 <bknudson> looks like requirements is incorrect 18:05:39 <bknudson> so should get that fixed before release 18:05:39 <stevemar> ayoung: those are closed out 18:06:04 <stevemar> bknudson: requirements meaning the blocking out a specific ksm version? 18:06:13 <stevemar> i saw a bug for that this morning 18:06:13 <bknudson> yes. 18:06:21 <jamielennox> bknudson: which requirements are incorrect? they're frozen now 18:06:27 <stevemar> bknudson: we can ask for that, but they are frozen 18:06:59 <bknudson> then we need to revert a bunch of changes that require a newer version of ksm 18:06:59 <stevemar> someone want to create a patch for that? and push it to requirements? 18:07:32 <bknudson> https://bugs.launchpad.net/keystone/+bug/1623091 18:07:34 <openstack> Launchpad bug 1623091 in OpenStack Identity (keystone) "keystonemidleware dependency should be > 4.0.0" [Undecided,In progress] - Assigned to tamil vanan (tamilhce) 18:07:47 <ayoung> someone locked the python-requests-Kerberos version out, but only for Py3+ ...more KSA brokeness due to global deps 18:08:28 <stevemar> OK, i guess i'll submit a patch to requirements 18:09:07 <stevemar> bknudson: let's hope the requirements team allows it 18:09:36 <stevemar> dolphm: you opened bug 1623117 recently, is that needed? 18:09:37 <openstack> bug 1623117 in OpenStack Identity (keystone) "Prevent keystone from serving requests when schema or data migrations are not up to date" [Medium,New] https://launchpad.net/bugs/1623117 18:09:42 <bknudson> probably won't like it since this will affect several projects 18:10:07 <dolphm> stevemar: not strictly, but it's something that if we have a fix ready for ocata, i'd like to slip it into the newton release IF we have an actual release blocker to warrant a respin / etc 18:10:36 <ayoung> I like that one 18:10:42 <stevemar> dolphm: fair enough, i'll mark it as rc-potential 18:10:49 <dolphm> stevemar: ++ 18:10:50 <ayoung> it will catch pain at a reportable point in the deploy process 18:10:53 <dolphm> ayoung: ++ 18:11:16 <stevemar> last one is bug 1621200 18:11:17 <openstack> bug 1621200 in OpenStack Identity (keystone) "MySQLOpportunisticIdentityDriverTestCase.test_change_password fails in UTC+N timezone" [Undecided,In progress] https://launchpad.net/bugs/1621200 - Assigned to Ron De Rose (ronald-de-rose) 18:11:21 <ayoung> "It is never a keystone bug" 18:11:35 <stevemar> rderose and breton have been hacking away at it 18:11:44 <stevemar> whats the news there you two 18:12:11 <rderose> I have fix that address that bug and another issue with the timestamp default 18:12:25 <stevemar> rderose: is the bug not reflective of the change? 18:12:34 <stevemar> cause i thought it was just a test issue 18:12:35 <ayoung> https://review.openstack.org/#/c/367374/ 18:13:01 <rderose> stevemar: no, the other issue is that the created_at value may not be UTC with the default datetime 18:13:11 <rderose> I'll update the bug to include that 18:13:56 <stevemar> rderose: yeah, i'll mark it as rc-potential, i'm not sure its a blocker 18:13:57 <rderose> the patch is mostly ready, but we're having an issue with the migration tests running out of order 18:14:14 <ayoung> server_default=sqlalchemy.func.now() that is new to me 18:14:40 <rderose> stevemar: dstanek is working on that issue. my patch will likely be based off of his fix 18:15:05 <stevemar> rderose: okay, we could probably slip it into rc2 if needed, i'll re-evaluate once you update the bug 18:15:23 <breton> stevemar: rderose: i have a much simpler fix 18:15:25 <dstanek> rderose: i'm not working on the timestamp issue at all. is that what you are talking about? 18:15:26 <rderose> ayoung: recommended by zzzeek at the time, but problematic with some versions of mysql 18:15:44 <breton> stevemar: rderose: and actually i am not sure which bug rderose tries to fix :p 18:15:44 <rderose> dstanek: no, tests running out of order issue 18:15:55 <ayoung> yeah, looks strange. Why but default is not sufficient because not-null needs a value ? 18:16:06 <notmorgan> ayoung: pretty much 18:16:13 <ayoung> Toy 18:16:19 <dstanek> rderose: yeah, that i'm looking into 18:16:34 <rderose> breton stevemar: https://bugs.launchpad.net/keystone/+bug/1621200 + the UTC issue 18:16:35 <openstack> Launchpad bug 1621200 in OpenStack Identity (keystone) "MySQLOpportunisticIdentityDriverTestCase.test_change_password fails in UTC+N timezone" [Undecided,In progress] - Assigned to Ron De Rose (ronald-de-rose) 18:17:06 <notmorgan> rule 1 of keystone: ALWAYS store/convert/workwith date time objects in UTC/TZ agnostic forms 18:17:13 <notmorgan> rule 2 of keystone: see rule 1 18:17:26 <breton> i proposed https://review.openstack.org/#/c/367374/ and it worked for me, since i reported the bug :p 18:17:52 <breton> so maybe a new bugreport needs to be opened for what Ron's doing 18:18:02 <notmorgan> rule 3: if you're relying on the system clock to be consistent in tests, you're doing it wrong. control the clock in tests directly 18:18:03 <rderose> breton: I don't trust that it will work for all versions of mysql 18:18:05 <bknudson> maybe our unit tests could set a random timezone 18:18:22 <rderose> notmorgan: agree 18:18:30 <ayoung> why is that not: server_default=datetime.datetime.utcnow 18:18:41 <notmorgan> ayoung: because that is calculated once iirc 18:19:09 <bknudson> server_default is calculated on mysql server 18:19:11 <rderose> ayoung: server_default=datetime.datetime.utcnow doesn't work for setting the server default 18:19:23 <notmorgan> bknudson: ah wait that is passed to the server yeah no doesn'tmwork then 18:19:26 <notmorgan> it's not python 18:19:34 <dstanek> usually i use something like server_default='CURRENT_TIMESTAMP' 18:19:47 <ayoung> but...wait 18:19:50 <ayoung> OK, no. 18:19:54 <dstanek> i don't think python code will work there 18:19:56 <ayoung> that is not what is meant by not null 18:20:00 <notmorgan> so, uhm. this is a bad plan to set a datetime default at the server level 18:20:01 <bknudson> you might want to look at what sqlalchemy generates for the SQL 18:20:03 <ayoung> that is making a null value that is just trash 18:20:06 <notmorgan> don't do that. 18:20:13 <ayoung> it says "the user can insert a row and if they don' 18:20:25 <ayoung> t provide a value, one will be provided for them" 18:20:25 <notmorgan> this is going to make you sad because you're getting whatever TZ the server is in 18:20:29 <ayoung> which is not what we want 18:20:47 <ayoung> so...no there should not be a server_default 18:20:48 <notmorgan> dstanek: ^ 18:20:53 <rderose> dstanek: server_default='CURRENT_TIMESTAMP' will automatically update the timestamp column whenever any other column is updated 18:21:10 <ayoung> it should be a Not Null column, with a value required to be passed in when a record is created...am I wrong? 18:21:19 <notmorgan> ayoung: or a server default can be set to a known bad value (0?) that we can directly check for. 18:21:25 <notmorgan> but same argument 18:21:27 <ayoung> Or does SQL A somehow make it painful 18:21:35 <bknudson> you can't add a not null column without a default value 18:21:44 <rderose> ayoung: my latest patch is removing the server_default 18:21:47 <ayoung> notmorgan, I don't want to "check" I want it to be required at dataload 18:21:51 <ayoung> rderose, excellent 18:21:53 <bknudson> maybe you can drop the default value after adding the column. 18:22:27 <notmorgan> bknudson: unlikely 18:22:32 <ayoung> anyway...not for this meeting...drive on 18:22:38 <ayoung> shout if it is readyu for review 18:22:40 <breton> btw: the bug i reported happens to me only on unit tests 18:22:42 * ayoung adding myself 18:22:49 <breton> not in production 18:22:50 <stevemar> thank you ayoung 18:23:00 <stevemar> let's discuss the timezone thing in -keystone 18:23:01 <bknudson> breton: do you have a different timezone in production servers? 18:23:23 <notmorgan> again, our code and tests are wrong if we rely on system TZ ever. 18:23:27 <notmorgan> we should make sure we aren't 18:23:37 <notmorgan> but carry on in -keystone after meeting 18:23:40 <breton> bknudson: my localhost production keystone doesn't suffer that :p 18:23:52 <stevemar> rderose: sounds like you need more investigation here 18:24:05 <stevemar> move to -keystone for this later, bah 18:24:09 <stevemar> #topic encrypted credentials update 18:24:22 <ayoung> so, while painful, this is not a stop ship. It sounds like a test only issue, and should be fixed in the tests 18:24:22 <rderose> stevemar: will do 18:24:30 <stevemar> just a quick note that i wanted to give lbragstad a round of applause for saving our bacon last week 18:24:43 <ayoung> most of the patches are throug Tripleo, so I think I'm good on encrypted creds 18:24:58 <stevemar> tripleo / rdo was broken cause of the credential encryption work, and required key setup 18:25:04 <ayoung> of course, that is a brushoff to the rest of the installers 18:25:21 <lbragstad> fwiw - we added support to grenade for a proper update 18:25:26 <stevemar> but lbragstad came up huge by including a null key if no fernet keys are seen 18:25:35 <stevemar> so thanks! :D 18:25:46 <rderose> lbragstad: ++ 18:25:53 <samueldmq> lbragstad: thanks 18:25:57 <ayoung> https://review.openstack.org/#/q/topic:keystone/credentials all merged and I wanted to keep lance's work quiet so they got through 18:25:59 <bknudson> more great work from lbragstad 18:26:08 <lbragstad> it was dolphm's idea, i was just the gnome that did the finger work ;) 18:26:11 <stevemar> it made ayoung happy, you know it was hard! 18:26:30 <stevemar> well thanks to dolphm too :) 18:26:44 <dolphm> go lbragstad go 18:26:46 <lbragstad> glad we got something worked out, thanks for all the reviews 18:26:52 <ayoung> Actually, forcint Tripleo to be able to support encrypted creds and fernet made me happy, I just didn't want to be too obvious about it 18:27:10 <stevemar> ayoung: :) 18:27:14 <stevemar> ayoung: you're up next 18:27:18 <stevemar> and possibly jamielennox 18:27:21 <stevemar> #topic Bug 968696 update 18:27:25 <openstack> bug 968696 in Glance ""admin"-ness not properly scoped" [High,In progress] https://launchpad.net/bugs/968696 - Assigned to Sharat Sharma (sharat-sharma) 18:27:36 * stevemar cue the daunting music, DUM DUM DUM 18:27:44 <ayoung> So...according to Jamie, we stil have 2-3 services that are not compliant 18:27:49 <samueldmq> 968696 I know that number 18:27:53 <stevemar> i've lost track of what is left to do for this one 18:27:59 <ayoung> to get this bug fixed required changes to Keystone (long done) 18:28:02 <ayoung> then oslo-context 18:28:07 <ayoung> also long sinve done 18:28:13 <samueldmq> stevemar: ++ 18:28:21 <stevemar> ayoung: all good so far :) 18:28:22 <jamielennox> i think we have the majority of services not compliant 18:28:26 <samueldmq> ayoung: could you give a quick recap in what's the plan ? what's missing ? 18:28:31 <ayoung> and then each of the services needed to load all of the value from oslo conf to policy check 18:28:42 <jamielennox> all the oslo.context work is done, and most took on the helper functions that are needed 18:28:53 <ayoung> so there are patches out for nova nca cinder, and one not even written for neutron 18:29:06 <ayoung> bottom line, we are not going to have this closed out for Newton 18:29:22 <jamielennox> the last step is to make them use context.to_policy_values() as the dict, however this is a bit more of a concern for most projects as we are changing the values that go into the policy engine 18:29:30 <ayoung> https://review.openstack.org/#/c/340195/ 18:29:32 <jamielennox> and keeping compatibility there is harder than you would think 18:29:41 <ayoung> and https://review.openstack.org/#/c/341905/ are examples of what needs to happen 18:30:38 <stevemar> ayoung: jamielennox simple enough changes 18:31:06 <stevemar> ayoung & jamielennox what do you need from the keystone team, or is this striclty an update? 18:31:13 <jamielennox> they are, but technically backwards incompatible because currently everyone drops context.to_dict into the enforcement 18:31:21 <stevemar> do you need some of us to patch other projects? 18:31:23 <stevemar> ah 18:31:39 <ayoung> jamielennox, why is is_admin_project not part of that? 18:31:44 <stevemar> can i help with that by allocating a fishbowl to this topic? 18:31:48 <ayoung> Yes 18:32:00 <jamielennox> ayoung: is_admin_project comes from the base context object 18:32:11 <jamielennox> stevemar: i've had a request to do an oslo.context as a cross-project already 18:32:23 <jamielennox> stevemar: i need to follow up on that, just not sure with whom at the moment 18:32:48 <ayoung> I still don't get it 18:33:11 <stevemar> jamielennox: sounds good to me 18:33:14 <ayoung> do we need to inject is_admin_project into context.to_dict ? Why would that break anything? 18:33:45 <jamielennox> ayoung: https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L136 18:34:09 <jamielennox> ayoung: no, i want to stop people using to_dict because it throws a whole lot of crap into policy enforcement that there is no reasonable way you would ever want to use 18:34:41 <jamielennox> i just need to convince people it's ok to let that stuff go 18:34:43 <stevemar> ayoung & jamielennox thanks for the update 18:35:06 <stevemar> can we move on? 18:35:13 <jamielennox> sure 18:35:25 <stevemar> #topic The identity v3 gate (non-voting) is broken 18:35:37 <stevemar> looks like raildo already volunteered to look at this 18:35:50 <stevemar> it's been failing for a month :( 18:35:53 <dolphm> this is the devstack job that does not run v2? 18:35:53 <stevemar> its a devstack job 18:36:06 <stevemar> dolphm: i believe so 18:36:27 <raildo_> yes, i`ve been working on it in the last months, and I want to help on it 18:36:28 <notmorgan> having it not have teeth is the same as not testing. it will continue to break unless we get it working. 18:36:37 <jamielennox> thanks raildo, i hadn't noticed this 18:36:49 <notmorgan> and make it voting 18:36:51 <raildo_> jamielennox: np 18:37:09 <raildo_> dolphm: yes, it is 18:37:16 <stevemar> #link bug that is seen: https://bugs.launchpad.net/tempest/+bug/1620999 18:37:17 <openstack> Launchpad bug 1620999 in tempest "gate-tempest-dsvm-neutron-identity-v3-only-full-nv 100% failure rate" [Undecided,New] 18:37:38 <stevemar> they are posting the removal since clarkb is moving it from trusty to xenial 18:37:44 <stevemar> postponing* 18:37:57 <raildo_> stevemar: ++ 18:38:05 <samueldmq> as the goal is now to get it voting 18:38:11 <samueldmq> we need to make sure they're stable 18:38:14 <stevemar> raildo_: i'll leave it to you to look at, i'll put it on next weeks agenda for an update 18:38:22 <raildo_> the problem is when the devstack try to get the image in glance, it`s not related to keystone v3 18:38:25 <samueldmq> otherwise project teams won't want to add it as voting 18:38:39 <raildo_> stevemar: ok, thanks 18:38:53 <jamielennox> right, the problem is this one gets broken because other teams don't configure for v3 18:39:01 <stevemar> raildo_: i suggest you see what went into glance around the time it started to fail 18:39:03 <raildo_> samueldmq: ++ the idea is to make this voting asap 18:39:03 <ayoung> ok, is this service catalog nonsense? 18:39:03 <jamielennox> the intent was to get it voting to stop that from happening 18:39:05 <samueldmq> raildo_: if it is not related to keystone v3, there is a proejct that CI is broken for 1+ month? 18:39:21 <ayoung> I notice that, at least in tripleo, we append versions to the URLs in the service catalog 18:39:29 <ayoung> so the identiyt one ends int /v2.0 18:39:47 <stevemar> ayoung: no one has any clue what the cause of this is, we're just guessing, no one has actually done any investigation 18:39:58 <raildo_> samueldmq: CI is broken because they couldn`t set the job properly, since this glance image issue 18:40:05 <stevemar> i'd rather not toss darts blindly, it was just a PSA for someone to look at it 18:40:11 <samueldmq> raildo_: ok 18:40:30 <raildo_> samueldmq: but i have to investigate deeper 18:40:32 <samueldmq> raildo_: I suggest to keep a very close eye on the jobs if we want to get them voting :) 18:40:35 <dolphm> raildo_: thank you! 18:40:43 <samueldmq> raildo_: kk gotcha, thanks for working on it 18:40:46 <dolphm> we should make that job voting around summit time :) 18:40:47 <stevemar> dolphm: ++ thanks for looking at it raildo_ 18:40:51 <raildo_> samueldmq: i wil :) 18:41:08 <bknudson> devstack doesn't put /v2.0 on the identity endpoint anymore 18:41:18 <ayoung> YAY! 18:41:18 <stevemar> moving on, i like this next topic 18:41:21 <raildo_> dolphm: stevemar no problem, I hope to get it fixed asap 18:41:33 <stevemar> #topic Newton post-mortem 18:41:42 <ayoung> He was killed by an apple 18:41:51 <stevemar> the Neutron team is having one: https://review.openstack.org/#/c/360207/12 18:41:56 <dolphm> ba dum tsh 18:42:00 <stevemar> ayoung: thats actually pretty funny, +1 18:42:14 <dolphm> stevemar: ayoung: +1 18:42:20 <stevemar> i usually just clean up the spec repo, but i like this idea 18:42:25 <ayoung> ++ 18:42:34 <ayoung> We want to have it prior to the summit, I assume 18:42:47 <stevemar> i've always found it frustrating that we just skimp on docs, testing, and client changes, when we mark the BP for the server complete 18:43:13 <stevemar> i think having a post mortem would hold feet to the fire, before we continue implementing new features 18:43:34 <bknudson> identifying technical debt? 18:43:42 <stevemar> *cough* domain specific config support for keystoneclient 18:43:49 <ayoung> That was my original complaint about specs. I felt that that they should have bee written as docs, and had a lifespan accordingly 18:43:50 <stevemar> bknudson: is that what we're calling it now? :) 18:44:04 <stevemar> thoughts on trying this out? 18:44:13 <ayoung> ++ 18:44:20 <jamielennox> +1 18:44:20 <ayoung> are there rules to the game? 18:44:29 <stevemar> ayoung: no rules, and the points don't count! 18:44:44 <stevemar> ayoung: honestly, none yet, i think we just want to identify where we missed 18:44:50 <ayoung> "Alex, I'll take lighting things on fire for 500" 18:44:58 <bknudson> I think of a postmortem as "what went well, what didn't go well" 18:45:00 <stevemar> and tack on names for things that missed 18:45:17 <ayoung> http://www.au.af.mil/au/awc/awcgate/army/tc_25-20/tc25-20.pdf 18:45:19 <stevemar> bknudson: i'm used to that definition too 18:45:42 <dstanek> what's missing is a task management system of some sort 18:45:49 <stevemar> bknudson: maybe port mortem isn't the right term here, but it would be "did we actually deliver on what we initially scoped" 18:45:54 <stevemar> dstanek: yeah 18:45:55 <ayoung> one thing that the AAR format suggests is a neutral 3rd party to moderate 18:45:57 <dstanek> we software engineer without the engineer... so do we just software? 18:46:23 <stevemar> OK, let me take this as a TODO and repropose this in a few days 18:46:27 <ayoung> ++ 18:46:31 <stevemar> i'll think of the outcomes I want to see 18:46:32 <samueldmq> stevemar: ++ 18:46:37 <lbragstad> dstanek please software responsibly 18:46:42 <stevemar> keep an eye on the mailing list 18:46:49 <dolphm> lbragstad: ++ 18:47:00 <bknudson> https://review.openstack.org/#/c/360207/12/specs/newton/postmortem/postmortem.rst -- here's the doc 18:47:23 <stevemar> #topic Mitaka status 18:47:57 <stevemar> we've got 2 different attempts to backport dstanek's cache fix 18:48:07 <breton> i am working on it 18:48:11 <stevemar> breton: awesome 18:48:12 <breton> and have only 2 tests failing 18:48:18 <stevemar> that sounds promising 18:48:24 <breton> a lot of things changed from mitaka to newton. 18:48:35 <dstanek> it's hard to duplicate awesome 18:48:57 <dstanek> ... which one is closer? 18:48:58 <dolphm> lol 18:49:29 <stevemar> we've got a few changes in stable/mitaka that haven't been released yet: https://github.com/openstack/keystone/compare/9.1.0...stable/mitaka 18:50:03 <stevemar> so it would be nice to get the cache fix in, and we release 9.2.0 18:50:21 <breton> mine i guess 18:50:35 <stevemar> since in a few weeks it'll be n-2 and only security fixes get merged :( 18:50:46 <dstanek> breton: cool, i'll review that one today then 18:50:52 <stevemar> thanks dstanek 18:51:19 <stevemar> todo, breton to code, dstanek tor review, stevemar to propose new release when ready 18:51:36 <stevemar> lbragstad: got 9 minutes! 18:51:42 <stevemar> #topic Update on making fernet the default 18:51:54 <lbragstad> well - here it is 18:51:55 <lbragstad> #link https://review.openstack.org/#/c/345688/19 18:52:02 <stevemar> i've seen a lot of action for this lately, thanks for picking this one up 18:52:16 <lbragstad> that patch is dependent on everything needed to make fernet the default token provider 18:52:39 <lbragstad> looks to be passing the transient issue we noticed the first time we made the switch 18:52:50 <lbragstad> which appears to be a mysql rounding thing 18:53:05 <lbragstad> I've doc'd that here - https://bugs.launchpad.net/keystone/+bug/1622010 18:53:06 <openstack> Launchpad bug 1622010 in OpenStack Identity (keystone) "MySQL rounds timestamps" [High,In progress] - Assigned to Lance Bragstad (lbragstad) 18:53:17 <samueldmq> lbragstad: you merged a fix for that (mysql rounding up the timestamp) ? 18:53:30 <lbragstad> samueldmq i didn't merge it - i just proposed one solution 18:53:36 <lbragstad> happy to see others though 18:53:43 <samueldmq> lbragstad: ++ 18:53:49 <samueldmq> so, other solutions could be : 18:53:51 <ayoung> Can we hack the tests in Tempest instead? 18:53:57 <samueldmq> store subsecond precision in another column 18:54:12 <ayoung> "we never promised that a revoked token would be seen immeditatly, your tests are too aggresive" 18:54:33 <dolphm> ayoung: ++ 18:54:39 <bknudson> we couldn't promise that anyways due to caching 18:54:47 <ayoung> "revocations will not be visible for 5 minutes. Deal with it" 18:54:47 <stevemar> yep 18:54:49 <samueldmq> or just have a long int column storing the time 18:54:50 <lbragstad> ayoung the issue is when mysql would round a timestamp up 18:54:56 <stevemar> ayoung: i think that is fair 18:55:02 <samueldmq> lbragstad: and that is an issue 18:55:15 <dolphm> samueldmq: if you go that route, it'd be far easier to just store a bigger integer in one column and divide it by 10^x to get the subsecond precision you want 18:55:51 <samueldmq> dolphm: yes, just listed as the second option .. ^ have a long int column storing the time (from 1970s I think) 18:56:10 <stevemar> lbragstad: have you spoke with sdague and the qa team about this? 18:56:21 <stevemar> give them plenty of heads up 18:56:30 <samueldmq> and we can be as precise as we want to be, without worring about rounding/truncating anything 18:56:44 <lbragstad> stevemar about making fernet the default? 18:56:51 <stevemar> lbragstad: yes 18:56:55 <lbragstad> stevemar I figured we would only consider that once ocata opens 18:57:05 <stevemar> lbragstad: that'll be in 2 weeks or so :P 18:57:10 <lbragstad> but yes - we'll for sure need to give them a heads up 18:57:14 <stevemar> but OK, i guess it can wait 18:57:41 <lbragstad> stevemar i have a list under the topic on the meeting etherpad asking who we need to update 18:57:44 <lbragstad> or reach out to, 18:57:57 <lbragstad> is anyone else aware of other groups that need to be on that list? 18:58:34 <samueldmq> I think a cp thread would be nice 18:58:41 <samueldmq> to let everyone know what our intentions are 18:58:52 <stevemar> talking with the the install guide folks will be an interesting talk 18:58:59 <stevemar> it does complicate setup 18:59:14 <samueldmq> stevemar: ++ 18:59:20 <bknudson> can we do the same null-keys trick with fernet? 18:59:29 <samueldmq> it's nice we have dedicated teams for those thigns 18:59:32 <bknudson> that would be dangerous 18:59:48 <stevemar> bknudson: you'll still be left with a bearer token 19:00:03 <stevemar> lbragstad: i'll add to the list if i think of more 19:00:10 <stevemar> lbragstad: probably RDO / tripleo 19:00:13 <samueldmq> yes, you token is : role:admin,project:admin 19:00:14 <stevemar> #endmeeting