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