Tuesday, 2018-10-23

*** rcernin has joined #openstack-meeting-alt00:11
*** rcernin_ has quit IRC00:12
*** rcernin has quit IRC00:13
*** rcernin has joined #openstack-meeting-alt00:14
*** tetsuro has joined #openstack-meeting-alt00:45
*** chhagarw has joined #openstack-meeting-alt00:47
*** gouthamr has joined #openstack-meeting-alt00:47
*** chhagarw has quit IRC00:51
*** tetsuro has quit IRC01:06
*** tetsuro_ has joined #openstack-meeting-alt01:06
*** markvoelker has joined #openstack-meeting-alt01:25
*** hongbin has joined #openstack-meeting-alt01:27
*** cloudrancher has quit IRC01:33
*** cloudrancher has joined #openstack-meeting-alt01:34
*** hongbin has quit IRC01:36
*** hongbin has joined #openstack-meeting-alt01:37
*** yamahata has quit IRC01:40
*** hongbin_ has joined #openstack-meeting-alt01:41
*** cloudrancher has quit IRC01:41
*** cloudrancher has joined #openstack-meeting-alt01:42
*** hongbin has quit IRC01:43
*** bhavikdbavishi has joined #openstack-meeting-alt01:43
*** bhavikdbavishi has quit IRC01:50
*** hongbin has joined #openstack-meeting-alt02:05
*** hongbin_ has quit IRC02:07
*** lei-zh has joined #openstack-meeting-alt02:22
*** bhavikdbavishi has joined #openstack-meeting-alt02:23
*** lei-zh has quit IRC02:30
*** lei-zh1 has joined #openstack-meeting-alt02:30
*** bhavikdbavishi has quit IRC02:40
*** dave-mccowan has quit IRC02:57
*** munimeha1 has quit IRC03:01
*** bhavikdbavishi has joined #openstack-meeting-alt03:35
*** lei-zh1 has quit IRC03:39
*** yamahata has joined #openstack-meeting-alt03:48
*** hongbin has quit IRC03:52
*** chhagarw has joined #openstack-meeting-alt03:58
*** yamamoto has quit IRC04:17
*** yamamoto has joined #openstack-meeting-alt04:17
*** yamahata has quit IRC04:19
*** yamahata has joined #openstack-meeting-alt04:19
*** lei-zh1 has joined #openstack-meeting-alt04:54
*** janki has joined #openstack-meeting-alt04:59
*** ttsiouts has quit IRC05:42
*** ttsiouts has joined #openstack-meeting-alt05:43
*** ttsiouts has quit IRC05:47
*** tetsuro_ has quit IRC05:50
*** ccamacho has joined #openstack-meeting-alt06:31
*** slaweq has joined #openstack-meeting-alt06:43
*** bhavikdbavishi1 has joined #openstack-meeting-alt06:53
*** bhavikdbavishi has quit IRC06:55
*** bhavikdbavishi1 is now known as bhavikdbavishi06:55
*** rcernin has quit IRC07:06
*** rdopiera has joined #openstack-meeting-alt07:09
*** alexchadin has joined #openstack-meeting-alt07:10
*** lei-zh1 has quit IRC07:24
*** lei-zh1 has joined #openstack-meeting-alt07:24
*** ttsiouts has joined #openstack-meeting-alt08:17
*** e0ne has joined #openstack-meeting-alt08:23
*** derekh has joined #openstack-meeting-alt08:29
*** gouthamr has quit IRC08:32
*** priteau has joined #openstack-meeting-alt08:45
*** dtrainor has quit IRC08:59
priteau#startmeeting blazar09:00
openstackMeeting started Tue Oct 23 09:00:16 2018 UTC and is due to finish in 60 minutes.  The chair is priteau. Information about MeetBot at http://wiki.debian.org/MeetBot.09:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.09:00
*** openstack changes topic to " (Meeting topic: blazar)"09:00
openstackThe meeting name has been set to 'blazar'09:00
priteau#topic Roll call09:00
*** openstack changes topic to "Roll call (Meeting topic: blazar)"09:00
*** bertys has joined #openstack-meeting-alt09:01
bertyso/09:02
priteauGood morning bertys09:02
bertyshi all09:02
priteaubertys: It's just the two of us from now, should we wait a few minutes to see if masahito and tetsuro join?09:04
bertyssure, have you pinged them on blazar IRC?09:04
priteauThey're not on IRC at all09:05
priteauWell, let's start, maybe they'll join later. I sent them an email.09:09
bertysok, thanks09:09
priteauAgenda:09:09
priteau1. Project Update @ Berlin Summit09:09
priteau2. Project Update @ Berlin Summit09:09
priteau3. OpenStack-wide Goals09:09
priteau4. stein-1 milestone09:09
priteau5. AOB09:09
priteau#topic Project Update @ Berlin Summit09:09
*** openstack changes topic to "Project Update @ Berlin Summit (Meeting topic: blazar)"09:09
priteaubertys: I see you added a slide on How to Contribute, thanks!09:10
*** gouthamr has joined #openstack-meeting-alt09:11
priteauWe have 20 minutes and only 7 slides, we may be able to add one or two to explain how Blazar works in more details, do you think that could be useful?09:11
bertyspriteau: sure, would you be willing to present that part?09:14
*** tetsuro has joined #openstack-meeting-alt09:14
priteaubertys: Sure09:14
priteauHi tetsuro09:14
tetsurosorry to be late09:15
tetsuroAnd masa has told me he can't attend today09:15
priteauOK, thanks for letting us know09:16
priteauWe were just discussing the Project Update talk09:16
priteauI was saying that, given that we have 20 minutes and only 7 slides so far, we may be able to add more content to explain how Blazar works internally09:16
priteauI can take care of it but I am open to suggestions.09:16
tetsuroSounds a good idea.09:17
priteauThere is still some content to add in the existing slide from Masahito and I09:18
priteauLet's try to get it finished by next meeting.09:19
tetsuroI think we can focus on how we can use blazar rather than how it works internally since there are more users than developers09:19
priteautetsuro: That's a good idea :)09:19
tetsuroMasa has told me to tell everyone that he's going to finish it this week09:19
tetsuros/it/the slide/09:20
priteauGood to hear09:20
priteauNext topic09:21
priteau#topic Forum @ Berlin Summit09:21
*** openstack changes topic to "Forum @ Berlin Summit (Meeting topic: blazar)"09:21
priteauI have created the Etherpad for the Blazar forum session and tetsuro created the one for placement09:21
priteauBoth are available on the Forum wiki page09:21
priteau#link https://wiki.openstack.org/wiki/Forum/Berlin201809:21
priteauThank you tetsuro09:22
*** alex_xu has quit IRC09:23
tetsuroOh, no I haven't I think you are referring to the placement extraction etherpad.09:23
tetsuroBut I will today.09:23
priteauYes, I just realized now!09:24
priteauI misread the Etherpad title09:24
priteauI don't think we have much more to do for now. We will need to review any comment that are added to the Etherpad before the session.09:25
priteau#topic OpenStack-wide Goals09:26
*** openstack changes topic to "OpenStack-wide Goals (Meeting topic: blazar)"09:26
priteauWe've received a patch to implement upgrade checkers09:26
priteau#link https://review.openstack.org/#/c/611811/09:27
priteauI haven't had time to review it yet, but it's got a +1 from Matt09:27
*** lei-zh1 has quit IRC09:28
priteauPlease review when you can09:28
priteau#topic stein-1 milestone09:29
*** openstack changes topic to "stein-1 milestone (Meeting topic: blazar)"09:29
priteaustein-1 milestone is this week. As explained in a previous meeting, there is no more tagging for this milestone.09:30
priteau#link https://launchpad.net/blazar/+milestone/stein-109:30
priteauWe've fixed a few issues but a lot are in progress or not yet started09:30
priteauI propose to move all undone bugs and blueprint to the stein-2 milestone, any objection?09:31
priteauAny comment?09:33
tetsuroNo, we should do more reviews.09:33
tetsurotowards stein-209:35
priteauAgreed. My time is limited at the moment due to focus on another project but I am hoping it will get better after the Berlin Summit09:35
priteau#topic AOB09:37
*** openstack changes topic to "AOB (Meeting topic: blazar)"09:37
priteaubertys: Regarding your comment on https://review.openstack.org/#/c/604938/09:39
priteauWhat about we assert that the nova-compute service is enabled and up when we add it to aggregate, and we leave a better handling as a todo for when we test health monitoring?09:40
priteauAt the moment, there is only one host and if it is down, that's an infra or devstack issue.09:43
bertyspriteau: this may be ok for now and I was actually thinking already longer term09:45
priteauSometimes it's more productive to merge early and properly fix later ;-)09:46
priteauCould you update your comment for masahito to explain what is sufficient for merging the patch?09:48
bertysright and as you know, I still have some plans to execute those scenario tests in OPNFV09:48
bertysok, will do09:49
priteauThank you09:50
priteauAny other issue to discuss?09:51
tetsuroI'm on business travel next week to south east Asia, so I can't attend the meeting, but by then I'll fill up the Summit etherpad https://etherpad.openstack.org/p/BER-python-bindings-for-the-placement-api, so please add your comments there next week.09:51
priteauThank you tetsuro!09:52
priteauIf nothing else, we can finish meeting early this week.09:54
priteauThank you for joining!09:54
priteau#endmeeting09:54
*** openstack changes topic to "Documentation (Meeting topic: trove)"09:55
openstackMeeting ended Tue Oct 23 09:54:59 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)09:55
openstackMinutes:        http://eavesdrop.openstack.org/meetings/blazar/2018/blazar.2018-10-23-09.00.html09:55
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/blazar/2018/blazar.2018-10-23-09.00.txt09:55
openstackLog:            http://eavesdrop.openstack.org/meetings/blazar/2018/blazar.2018-10-23-09.00.log.html09:55
*** rossella_s has quit IRC09:57
*** bertys has quit IRC09:57
*** ianychoi has quit IRC10:22
*** ianychoi has joined #openstack-meeting-alt10:25
*** apetrich has quit IRC10:38
*** pbourke has quit IRC10:47
*** dtrainor has joined #openstack-meeting-alt10:48
*** pbourke has joined #openstack-meeting-alt10:48
*** apetrich has joined #openstack-meeting-alt10:54
*** erlon has joined #openstack-meeting-alt10:58
*** yamamoto has quit IRC11:03
*** yamamoto has joined #openstack-meeting-alt11:04
*** ttsiouts has quit IRC11:04
*** yamamoto has quit IRC11:08
*** yikun has quit IRC11:09
*** tetsuro has quit IRC11:12
*** yamamoto has joined #openstack-meeting-alt11:21
*** panda is now known as panda|lunch11:27
*** janki has quit IRC11:41
*** ttsiouts has joined #openstack-meeting-alt11:43
*** markvoelker has quit IRC11:45
*** ttsiouts has quit IRC11:48
*** ttsiouts has joined #openstack-meeting-alt12:02
*** dave-mccowan has joined #openstack-meeting-alt12:07
*** janki has joined #openstack-meeting-alt12:14
*** cloudrancher has quit IRC12:19
*** cloudrancher has joined #openstack-meeting-alt12:19
*** bhavikdbavishi has quit IRC12:22
*** janki has quit IRC12:25
*** janki has joined #openstack-meeting-alt12:25
*** janki has quit IRC12:27
*** tobberydberg has quit IRC12:30
*** janki has joined #openstack-meeting-alt12:34
*** markvoelker has joined #openstack-meeting-alt12:36
*** jcoufal has joined #openstack-meeting-alt12:37
*** markvoelker has quit IRC12:37
*** jchhatbar has joined #openstack-meeting-alt12:38
*** janki has quit IRC12:40
*** jchhatbar is now known as janki12:50
*** dustins has joined #openstack-meeting-alt12:51
*** dustins is now known as dschoenb|worksho12:52
*** dschoenb|worksho is now known as dustins12:52
*** ChanServ changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings/"12:53
*** yamamoto has quit IRC13:02
*** bnemec has joined #openstack-meeting-alt13:08
*** e0ne has quit IRC13:19
*** yamamoto has joined #openstack-meeting-alt13:35
*** cloudrancher has quit IRC13:44
*** cloudrancher has joined #openstack-meeting-alt13:45
*** liuyulong has joined #openstack-meeting-alt13:48
*** Leo_m has joined #openstack-meeting-alt13:58
*** hongbin has joined #openstack-meeting-alt14:00
*** panda|lunch is now known as panda14:04
*** janki has quit IRC14:21
*** e0ne has joined #openstack-meeting-alt14:29
*** alexchadin has quit IRC14:30
*** ccamacho has quit IRC14:57
*** gagehugo has joined #openstack-meeting-alt15:02
*** Leo_m_ has joined #openstack-meeting-alt15:02
*** Leo_m has quit IRC15:04
*** Leo_m_ has quit IRC15:09
*** Leo_m has joined #openstack-meeting-alt15:09
*** cloudrancher has quit IRC15:12
*** cloudrancher has joined #openstack-meeting-alt15:13
*** ccamacho has joined #openstack-meeting-alt15:17
*** ccamacho has quit IRC15:17
*** kopecmartin is now known as kopecmartin|off15:33
*** wxy| has joined #openstack-meeting-alt15:34
*** ianychoi_ has joined #openstack-meeting-alt15:36
*** e0ne has quit IRC15:39
*** ianychoi has quit IRC15:40
*** liuyulong is now known as liuyulong|away15:41
*** ayoung has joined #openstack-meeting-alt15:50
lbragstad#startmeeting keystone16:00
openstackMeeting started Tue Oct 23 16:00:22 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.16:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
*** openstack changes topic to " (Meeting topic: keystone)"16:00
openstackThe meeting name has been set to 'keystone'16:00
lbragstad#link https://etherpad.openstack.org/p/keystone-weekly-meeting16:00
lbragstado/16:00
cmurphyo/16:00
hrybackio/16:01
gagehugoo/16:01
ayoungOyez oyez16:02
wxy|o/16:02
lbragstad#topic Release status16:03
*** openstack changes topic to "Release status (Meeting topic: keystone)"16:03
lbragstad#info next week is Stein-1 and specification proposal freeze16:03
ayoungI assume we have real things to discuss prior to my two agenda items16:03
lbragstadwe should be smoothing out concerns with specs sooner rather than later at this point16:04
kmalloco/16:04
lbragstadif you have specific items wrt to specs and want higher bandwidth to discuss, please let someone know16:04
lbragstador throw it on the meeting agenda16:04
lbragstadayoung do you want to reorder the schedule16:05
lbragstad?16:05
lbragstador is that what you're suggesting?16:05
ayoungNah16:06
ayoungI'm going last16:06
lbragstadok16:06
lbragstad#topic Oath approach to federation16:06
*** openstack changes topic to "Oath approach to federation (Meeting topic: keystone)"16:06
lbragstadlast week we talked about Oath open-sourcing their approach to federation16:07
ayoungso replace uuid3 with uuid5 and I like16:07
ayoungcouple other things;  we could make it so the deployer choses the namespace, and could keep that in sync across their deployments, to get "unique" Ids that are still distributed16:07
lbragstadtl;dr they consume Athenz tokens in place of SAML assertion and have their own auth plugin for doing their version of auto-provisioning16:07
lbragstadyou can find the code here:16:08
lbragstad#link https://github.com/yahoo/openstack-collab/tree/master/keystone-federation-ocata16:08
lbragstadi started walking through it and comparing their implementation against what we have, just to better understand the differences16:08
lbragstadyou can find that here, but i just started working on it16:08
lbragstad#link https://etherpad.openstack.org/p/keystone-shadow-mapping-athenz-delta16:08
ayoungCould Athenz be done as a middleware module?  Something that looks like REMOTE_USER/REMOTE_GROUPS?  Or does it provide more information than we currently accept from SAML etc16:09
lbragstadit doesn't really follow the saml spec at all - from what i can tell, it gets everything from the athenz token and the auth body16:09
lbragstadthe auth plugin decodes the token and provisions users, projects, and roles based on the values16:10
ayoungBecause Autoprovisioning is its own thing, and we should be willing to accept that as a standalone contribution anyway.16:10
lbragstadyeah - i guess it's important to note that Oath developed this for replicated usecases and not auto-provisioning specifically, but the implementation is very similar to what we developed as a solution for auto-provisioning16:11
ayoungalso...Oauth needs predictable Ids.16:12
ayoungI have a WIP spec to support those.  It is more than just Users, it looks like16:12
lbragstadi'm not sure they need those if they come from the identity provider16:12
lbragstadwhich is athenz16:12
ayoungI think the inter-tubes are congested16:12
ayounghttps://review.openstack.org/#/c/612099/16:13
lbragstadwhy does athenz need predictable user ids?16:13
ayounglbragstad, becasue they need to be the same from location to location16:14
ayoungso admin can't be one ABC on region1 and 123 in region216:14
lbragstadhttps://github.com/yahoo/openstack-collab/blob/master/keystone-federation-ocata/plugin/keystone/auth/plugins/athenz.py#L123-L12916:14
ayoungthey state they use uuid3(NAMESPACE, name)16:14
lbragstadthe user id is generated by athens16:14
lbragstadathenz*16:15
lbragstadand keystone just populates it in the database, from what i can tell16:15
*** rdopiera has quit IRC16:15
lbragstadso long as you're using athenz tokens to access keystone service providers, you should have the same user id at each site?16:16
ayoungthat is my understanding, yes16:16
*** ttsiouts has quit IRC16:16
lbragstadso their implementation has already achieved predictable user ids16:16
*** gyee has joined #openstack-meeting-alt16:16
lbragstadright?16:16
*** ttsiouts has joined #openstack-meeting-alt16:17
lbragstadif anyone feels like parsing that code, feel free to add your comments, questions, or concerns to that etherpad16:19
lbragstadit might be helpful if/when we or penick go to draft a specification16:19
lbragstadworst case, it helps us understand their usecase a bit better16:19
wxy|Will take a look later.16:19
lbragstadthanks wxy|16:20
lbragstadany other questions on this?16:20
* knikolla will read back. am stuck in meetings as we have the MOC workshop next week. sorry for being AWOL this time period. 16:20
lbragstadno worries - thanks knikolla16:21
lbragstadalright, moving on16:21
lbragstad#topic Another report of upgrade failures with user options16:21
*** openstack changes topic to "Another report of upgrade failures with user options (Meeting topic: keystone)"16:21
*** ayoung has quit IRC16:21
*** ttsiouts has quit IRC16:21
lbragstad#link https://bugs.launchpad.net/openstack-ansible/+bug/179338916:21
openstackLaunchpad bug 1793389 in openstack-ansible "Upgrade to Ocata: Keystone Intermittent Missing 'options' Key" [Medium,Fix released] - Assigned to Alex Redinger (rexredinger)16:21
lbragstadwe've had this one crop up a few times16:21
lbragstadspecifically, the issue is due to caching during a live upgrade16:22
lbragstadfrom pre-Ocata to Ocata16:22
*** ayoung has joined #openstack-meeting-alt16:22
lbragstadit's still undetermined if this impacts FFU scenarios16:23
lbragstad(e.g. Newton -> Pike)16:23
lbragstadbut it boils down to the cache returning a user reference during authentication on Ocata code that expects user['options'] to be present, but isn't because the user was cached prior to the upgrade16:23
ayoungGah...disconnect.  I'll try to catch up16:24
lbragstaddeployment projects have a work around to flush memcached as a way to force a miss on authentication and refetch the user16:24
lbragstadcmurphy odyssey4me and i were discussing approaches for mitigating this in keystone directly16:25
lbragstadthere is a WIP review in gerrit16:26
lbragstad#link https://review.openstack.org/#/c/612686/16:26
lbragstadbut curious if people have thoughts or concerns about this approach16:26
lbragstador if there are other approaches we should consider16:26
ayoungwouldn't deploying a fix like this flush the cache anyway?16:27
ayoungHow could they ever get in this state?16:27
lbragstadthe memcached instance has a valid cache for a specific user16:28
ayoungIs this a side effect of 0 downtime upgrades?  Keep the cache up, even as we change the data out from underneath?16:28
lbragstadyeah - that's the problem16:28
lbragstadthe cache remains up16:28
lbragstadthus holding the cached data16:28
ayoungthat is going to be a problem in other ways16:28
ayoungneeds to be part of the upgrade.  Flush cache when we do ....16:29
ayoungcontract?16:29
ayoungwe change the schema in the middle.  THe cache will no longer reflect the schema after some point16:29
lbragstadthat's what https://review.openstack.org/#/c/608066/ does16:30
lbragstadbut not in process16:30
cmurphythat's the problem, the question is whether we can be a bit more surgical instead of flushing the whole cache16:30
ayoungI see that, but it is on a row by row basis16:30
ayoungyeah,  that review looks like it is in the right direction16:31
ayoungso...can we tell memcache to flush all of a certain class of entry?  As I recall from token revocations, that is not possible16:31
lbragstadalso - alex's comment on https://review.openstack.org/#/c/612686/ proves this could affect FFU16:31
ayoungit only knows about key/value stores16:31
lbragstadayoung are you asking about cache region support?16:32
ayounglbragstad, maybe.16:32
ayoungdoes each region reflect a specific class of cached objects?16:33
lbragstadsome parts of keystone rely on regions, yes16:33
lbragstadcomputed role assignment have their own region, for example16:33
lbragstadsame with tokens16:33
ayoungare regions expensive?  Is there a reason to avoid using them?16:33
*** iyamahat has joined #openstack-meeting-alt16:33
lbragstadi'm not sure - that might be a better question for kmalloc16:34
kmallocno16:34
lbragstad#link https://review.openstack.org/#/c/612686/1/keystone/identity/core.py,unified is an attempt at creating a region specifically for users16:34
ayoungcould we wrap user, groups, projects etc each with a region, and then, as part of the sql migrations, flush the region16:34
kmallocnot expensive, but we have cases where we cannot invalidate an explicit cache key16:34
kmalloce.g. many entries via kwargs into a single method16:34
kmallocso we need to invalidate the entire region16:34
lbragstad#link https://review.openstack.org/#/c/612686/1/keystone/auth/core.py,unified@389 drops the entire user region (every cached user)16:34
kmallocit is better to narrow the invalidation to as small a subset as possible16:34
kmallocno reason to invalidate *everything* if only computed role assignments needs to be invalidated16:35
ayoungkmalloc, if we change the scheme on, in this case, users, we need to invalidate all cached users.  Is that too specific?16:35
kmallocyou can do so.16:35
ayoungeach class of object gets its own region?16:35
kmallocso far yes16:36
kmallocwell...16:36
kmalloceach manager16:36
ayoungok...so, we could tie in with the migration code, too, to identify what reqions need to be invalidated16:36
lbragstadcorrect - if that region needs to be invalidated16:36
kmallocand some managers have extra regions, eg. computed assignments16:36
ayoungOK,  so users and groups would go together, for example?16:36
kmallocright now, yes16:36
*** yamahata has quit IRC16:36
lbragstadbut - they could be two separate regions if needed16:37
kmalloc++16:37
lbragstaddepends on the invalidation strategy16:37
kmallocit's highly modular16:37
ayoungBackend is probably granular enough16:37
lbragstador what needs to invoke invalidation, how often, etc...16:37
ayoungidentity, assignment, resource16:37
kmallocyou can also force a cache pop by changing the argument(s)/kwargs [once https://review.openstack.org/#/c/611120/ lands] in the method signature16:37
kmallocsince we cache memoized16:38
ayoungyech16:38
ayounglets not count on that.16:38
kmallocit is a way caching works.16:38
ayoungI'd hate to hate to change kwargs just to force a cache pop16:38
ayoungyeah, and it is ok, just not what we want to use for this requirement16:38
kmallocit is a way a lot of things on the internet work, explicit change to the request forcing a cache cycle16:38
kmallocin either case you can force a cache pop. though i would not want to do that in db_sync16:39
kmallocit might make sense to do an explicit region (all region) cache expiration/invalidation on keystone start16:40
kmallocor as a keystone-manage command16:40
kmallochooking in all the cache logic into db_sync seems ... rough16:40
*** iyamahat has quit IRC16:41
lbragstadin that case, a single keystone node could invalidate the memcached instances16:41
ayoungwhat if db_sync set the values that would then be used by the manage-command16:41
lbragstadbut that behavior also depends on cache configuration16:41
ayounglike a scracth table with the set of regions to invalidate?16:41
kmallocayoung: there is no reason to do something like that16:41
kmallocreally, just invalidate the regions16:42
kmallocthey will re-warm quickly16:42
kmallocupgrade steps should be expected to need a cache invalidation/rewarm16:42
lbragstadperformance will degrade for a bit16:42
lbragstadalso - cmurphy brought up a good point earlier that it would be nice to find a solution that wasn't super specific to just this case16:42
kmallocwhich is fine for an upgrade process. we already say "turn everything off except X"16:42
lbragstadsince this is likely going to happen in the future16:42
kmallocso, i'd say keystone-manage that forces a region-wide invalidation16:43
kmalloc[all regions]16:43
ayoungI'll defer.  I thought we were going more specific, to flush only regions we knew had changed, but, this is ok]16:43
kmallocfor the most part our TTLs are very narrow16:44
kmalloci'll bet most cache is popped just by timeout (5m) during upgrade process16:45
kmallocor a restart of memcache servers as part of the deal16:45
kmallocthis is just explicit another option is to add a namespace value that we change per release of keystone16:45
kmallocthat just forces rotation of the cache based upon code base.16:46
ayoungok, so keystone-manage cache-invalidate [region | all ]  ?16:46
*** armstrong has joined #openstack-meeting-alt16:46
kmallocfwiw, a namespace is just "added" to the cache key (before sha calculation)16:46
kmallocwhich then forces a new keystone to always use new cache namespace16:46
kmallocno "don't forget to run this command"16:47
kmalloc(though an explicit cache invalidate command might be generally useful regardless)16:47
ayoungcool.  We good here?16:47
lbragstadi think so - we're probably at a good point to continue the discussion in review16:48
kmallocwe could use https://github.com/openstack/keystone/blob/master/keystone/version.py#L15 anyway. yeah we should continue discussion in review16:48
ayoungCool...ok16:48
lbragstad#topic open discussion16:48
*** openstack changes topic to "open discussion (Meeting topic: keystone)"16:48
ayoungstwo things16:48
ayoung1.  service roles16:48
lbragstadwe have 12 minutes to talk about whatever we wanna talk about16:48
kmallocFlask has 2 more reviews, all massive code removals! yay, we're done with the migration16:48
ayoungwe need a way to convert people from admin-everywhere to service roles16:48
* kmalloc has nothing else to talk about there, just cheering that we got there16:49
ayoungso...short version:16:49
* kmalloc hands the floor to ayoung... and since ayoung is now holding the entire floor, everyone falls ... into the emptyness/botomless area below the floor.16:49
ayoungwe role in rules that say admin(not everywhere) is servicer role or is_admin_project and leae the current mechanism in place16:49
ayoungso, once we enable a bogus admin proejct in keystone, none of the tokens will ever have is_admin_project set16:50
ayoungthen we can remove those rules16:50
ayoungit will let a deployer decide when to switch on service roles as the only allowed way to perform those ops16:51
lbragstadwhy wouldn't we just use system-scope and use the upgrade checks to make sure people have the right role assignments according to their policy?16:51
ayounglbragstad, so...16:51
ayoungthat implied a big bang change16:52
ayoungthose never go smoothly16:52
ayoungwe want to be able to have people get used to using system roles, but not break their existing workflows16:52
lbragstadbut upgrade checkers are a programmable way to help with those types of things?16:52
ayoungwill it make sure that Horizon works?16:52
ayoungWill it make sure 3rd party apps work?16:52
ayoungwe want to leave the existing policy in place until they are ready to throw the switch16:53
ayoungand give them a way to throw it back16:53
ayoungright now, people are misusing admin tokens16:53
ayoungI've seen some really crappy code along those lines16:53
kmallocayoung: that is the idea behind the deprecated policy bits, they just do an logical OR between new and old16:54
ayoungwe want to tell people: switch to using "service scoped tokens" and make it their choice16:54
ayoungyeah, but....16:54
kmallocuntil we remove the declaration of the "this is the deprecated rule"16:54
ayoungI don't want to have to try and synchronize this across all of the projects in openstack16:54
kmallocyou are going to have to.16:54
ayoungso...we absoutelty use those16:54
kmallocit's just how policy works16:55
ayoungre-read what I said16:55
ayoungit allows us to roll in those changes, but keep things working as-is until we throw the switch16:55
kmallocyou can't just wave a wand here.16:55
ayoungI worked long and hard on this wand16:55
*** raildo has joined #openstack-meeting-alt16:55
kmallocit is going to be a "support (new or old) or supply custom policy"16:56
ayoungso, the idea is we get a common definition of service scoped admin-ness16:56
kmallocthe switch is thrown down the line.16:56
ayoungyes!16:56
kmallocand it likely will be an upgrade16:56
kmallocwhere the old declaration is removed16:56
kmallocbut it COULD be re-added with a custom policy override16:56
kmallocthis has to be done per-project in that project's tree16:56
ayoungwhat happens if that breaks a critical component?16:57
ayoungthey are not going to do a downgrade16:57
kmalloc3 things: supply a fixed custom policy16:57
kmalloc(quick remediation)16:57
kmalloc2) do better UAT and/or halt upgrade16:57
kmalloc3) roll back to previous16:57
kmalloccustom policy to the old policy string is immediate and fixes "critical path is broken"16:58
ayoungSo...nothing I am saying is going to break that.  But it ain;'t going to work that smoothly16:58
ayoungso...16:58
ayounghere is the middle piece:16:58
ayoungmake it an organizational decision to enable and disable the service scoped roles as the ONLY way to enforce that policy16:58
ayoungand isolate that decision16:58
lbragstadfinal minute16:59
kmallocthis feels like a deployer/installer choice.16:59
kmallocfwiw16:59
ayoungOK...one other thing16:59
kmallocnot something we can encode directly16:59
kmalloc(just because of how we sucked at building how policy works in the past)16:59
ayoungI propse that the custom policies we discussed last week go to oslo-context instead of olso-policy16:59
kmalloc-216:59
kmallocput them external in a new lib if it doesn't go in oslo-policy16:59
ayoungoslo-context is the openstack specific code. oslo-policy is a generic rules engine.16:59
*** derekh has quit IRC17:00
ayoungthere is a dependency between them for this anyway17:00
kmalloccontext is the wrong place to put things that are policy rules.17:00
ayoungso is olso-policy, tho17:00
kmallocoslo context is a holder object for context data.17:00
ayoungbut we insist on it for enforcing policy17:00
kmallocput them in oslo-policy and then extract to new thing17:00
kmallocor put it in new thing and fight to land it17:00
lbragstadoslo.context is often overridden for service specific implementations, too17:00
ayoungI think it stays in new thing, then17:00
kmallocdo not assume oslo.context even is in use.17:00
kmalloci told you i recommend olos-policy for one reason only17:01
kmallocjust for ease of landing it17:01
kmallocthen extract17:01
lbragstadok - we're out of time folks17:01
kmallocbut, i am happy to support a new thing as well17:01
ayoungcool.  I'll push for new thing17:01
kmallocit will just be painful to get adopted (overall)17:01
lbragstadreminder that we have office hours and we can continue there17:01
lbragstadthanks all!17:01
kmallocbut i am fine with +2ing lots of stuff for that as it comes down the line17:01
lbragstad#endmeeting17:02
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings/"17:02
openstackMeeting ended Tue Oct 23 17:02:10 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:02
openstackMinutes:        http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-10-23-16.00.html17:02
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-10-23-16.00.txt17:02
openstackLog:            http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-10-23-16.00.log.html17:02
* kmalloc is trying to not be in the way, but wants to keep things like that isolated to the general places they belong17:02
kmallocayoung: you're not in -keystone btw17:02
*** wxy| has quit IRC17:05
*** iyamahat has joined #openstack-meeting-alt17:05
*** iyamahat has quit IRC17:05
*** iyamahat has joined #openstack-meeting-alt17:06
*** e0ne has joined #openstack-meeting-alt17:08
*** iyamahat_ has joined #openstack-meeting-alt17:15
*** lbragstad is now known as lbragstad_f00d17:17
*** iyamahat has quit IRC17:18
*** yamahata has joined #openstack-meeting-alt17:24
*** tpsilva has joined #openstack-meeting-alt17:40
*** e0ne has quit IRC17:45
*** lbragstad_f00d is now known as lbragstad17:45
*** cloudrancher has quit IRC18:10
*** cloudrancher has joined #openstack-meeting-alt18:10
*** apetrich has quit IRC18:16
*** apetrich has joined #openstack-meeting-alt18:17
*** e0ne has joined #openstack-meeting-alt18:31
*** e0ne has quit IRC18:31
*** irclogbot_3 has joined #openstack-meeting-alt18:35
*** panda has quit IRC18:45
*** panda has joined #openstack-meeting-alt18:45
*** chhagarw has quit IRC18:57
*** caboucha has joined #openstack-meeting-alt19:11
*** e0ne has joined #openstack-meeting-alt19:15
*** david-lyle has joined #openstack-meeting-alt19:27
*** dklyle has quit IRC19:28
*** armstrong has quit IRC19:46
*** lbragstad has quit IRC19:50
*** lbragstad has joined #openstack-meeting-alt19:53
*** david-lyle is now known as dklyle19:53
*** cloudrancher has quit IRC20:21
*** cloudrancher has joined #openstack-meeting-alt20:22
*** ttsiouts has joined #openstack-meeting-alt20:56
*** erlon has quit IRC21:03
*** e0ne has quit IRC21:04
*** priteau has quit IRC21:09
*** dustins has quit IRC21:19
*** dklyle has quit IRC21:19
*** dklyle has joined #openstack-meeting-alt21:20
*** raildo has quit IRC21:23
*** cloudrancher has quit IRC21:35
*** cloudrancher has joined #openstack-meeting-alt21:36
*** slaweq has quit IRC21:39
*** cloudrancher has quit IRC21:40
*** cloudrancher has joined #openstack-meeting-alt21:40
*** dustins has joined #openstack-meeting-alt21:41
*** slaweq has joined #openstack-meeting-alt22:05
*** ttsiouts has quit IRC22:06
*** ttsiouts has joined #openstack-meeting-alt22:06
*** ttsiouts has quit IRC22:11
*** dustins has quit IRC22:15
*** rcernin has joined #openstack-meeting-alt22:24
*** bnemec has quit IRC22:25
*** slaweq has quit IRC22:38
*** caboucha has quit IRC22:44
*** diablo_rojo has quit IRC22:57
*** diablo_rojo has joined #openstack-meeting-alt23:08
*** hongbin has quit IRC23:10
*** tpsilva has quit IRC23:11
*** slaweq has joined #openstack-meeting-alt23:11
*** slaweq has quit IRC23:45
*** gyee has quit IRC23:46

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!