Friday, 2019-11-22

*** spatel has joined #openstack-keystone00:41
*** gyee has quit IRC00:46
*** openstackstatus has joined #openstack-keystone01:03
*** ChanServ sets mode: +v openstackstatus01:03
*** jistr has quit IRC01:14
*** jistr has joined #openstack-keystone01:15
*** jamesmcarthur has joined #openstack-keystone01:34
*** spatel has quit IRC02:37
*** jamesmcarthur has quit IRC03:13
*** awalende has joined #openstack-keystone03:15
*** awalende has quit IRC03:19
*** dave-mccowan has quit IRC04:58
*** Luzi has joined #openstack-keystone06:06
vishakhao/06:25
*** awalende has joined #openstack-keystone06:58
*** awalende has quit IRC07:02
*** shyamb has joined #openstack-keystone07:11
*** shyamb has quit IRC07:38
*** shyamb has joined #openstack-keystone08:09
*** jawad_axd has joined #openstack-keystone08:11
*** pcaruana has joined #openstack-keystone08:21
*** awalende has joined #openstack-keystone08:30
*** tesseract has joined #openstack-keystone08:35
*** shyamb has quit IRC08:57
*** shyamb has joined #openstack-keystone09:04
*** shyamb has quit IRC09:39
*** shyamb has joined #openstack-keystone09:44
*** shyamb has quit IRC09:44
*** shyamb has joined #openstack-keystone09:45
*** shyamb has quit IRC09:54
*** shyamb has joined #openstack-keystone10:14
*** shyamb has quit IRC11:02
*** raildo has joined #openstack-keystone11:39
*** rcernin has quit IRC12:01
*** jamesmcarthur has joined #openstack-keystone13:04
lbragstado/13:06
*** Luzi has quit IRC13:09
*** awalende has quit IRC13:22
*** awalende has joined #openstack-keystone13:22
*** awalende_ has joined #openstack-keystone13:27
*** awalende has quit IRC13:27
*** awalende_ has quit IRC13:31
*** jawad_axd has quit IRC13:42
*** jawad_axd has joined #openstack-keystone13:43
*** jawad_axd has quit IRC13:48
*** openstackgerrit has joined #openstack-keystone13:52
openstackgerritJohn Garbutt proposed openstack/oslo.limit master: Add flat enforcer  https://review.opendev.org/69531013:52
openstackgerritJohn Garbutt proposed openstack/oslo.limit master: WIP: Two level limit enforcer  https://review.opendev.org/69552713:57
johnthetubaguylbragstad: just wondering about the oslo.limit stuff, it would be great to get a new release out with something we can dev against in Nova, although I know the nova spec isn't yet approved13:59
*** Ben78 has joined #openstack-keystone14:00
johnthetubaguyjust wondering if its looking roughly like you expected, or if it looks odd14:00
*** jaosorior has joined #openstack-keystone14:00
lbragstadjohnthetubaguy i'll be honest, i haven't taken a peak at it, yet14:00
lbragstadlemme look quick14:00
lbragstadstarting here - yeah? https://review.opendev.org/#/c/695310/14:01
johnthetubaguysorry, didn't mean it had to be now, but now is good :)14:01
johnthetubaguyyes, that is the one14:01
johnthetubaguyits honestly the patch is a bit big, ideas welcome14:01
* lbragstad is trying to remember the outcomes the last time we talked about this14:01
johnthetubaguyI changed my view of the world between patchset 1 and 2 (well a little bit)14:03
lbragstadfwiw - i broke my implement up a little bit14:03
lbragstadhttps://review.opendev.org/#/c/666085/9/oslo_limit/limit.py14:03
lbragstadin case that helps you reduce patch size14:03
johnthetubaguyah... that is where I stole it from, sorry I forgot you had stuff up14:03
lbragstadno worries - i honestly haven't touched this stuff in forever, i'm sure it bitrot14:04
lbragstadhttps://review.opendev.org/#/c/666444/7/oslo_limit/limit.py14:04
lbragstad^ then i added in the model stuff14:04
johnthetubaguyoh, sweet14:04
lbragstadthe flat enforcement was just flushing out https://review.opendev.org/#/c/666444/7/oslo_limit/limit.py@165 after14:05
lbragstadhttps://review.opendev.org/#/c/667452/314:05
lbragstadjohnthetubaguy overall - i think what you have in https://review.opendev.org/#/c/695310/4/oslo_limit/limit.py makes sense14:07
johnthetubaguylbragstad: OK, I like how you split yours up, and the docs element, happy to split mine appart and add in some of the enforcement type logic you have14:08
lbragstadjohnthetubaguy i eventually ran into a problem where i was passing a lot of the same data between objects14:09
*** awalende has joined #openstack-keystone14:09
lbragstadlike the enforcer and the enforcement model objects...14:09
lbragstadiirc - the enforcement implementation need things like the projects, services, endpoints, etc...14:09
lbragstadi thought i remember having a awkward time establishing that boundary between the objects14:10
lbragstadwithout duplicating too much stuff14:10
lbragstadi want to say that's where the _BaseEnforcer came from14:11
johnthetubaguyI guess that is why I went for logic blocks in the utils class14:11
lbragstadsure14:11
johnthetubaguynot sure I like it, but the two level enforcer didn't need too much fresh logic14:11
lbragstadi suppose - you're utils class is pretty close to what i was trying to do with base enforcer14:12
*** jamesmcarthur has quit IRC14:12
lbragstadmost of it has to do with grabbing data from keystohne14:12
johnthetubaguyI have just gone off inheritance for that kind of sharing14:12
johnthetubaguyI basically have resource_name to int dicts been passed around, which doesn't feel too bad14:13
lbragstadlooks like the only difference is that enforce() is still in the model implementations in my patch, versus being in the utility14:13
lbragstadyeah... i think that's fine for now?14:13
johnthetubaguythe second patch is the main reason for the structure in the first14:13
lbragstadi always liked the idea of a formal python object that represented the claim14:13
*** awalende has quit IRC14:14
lbragstadbut - if the dict isn't external (or handed back to the service in anyway) it should remain only within oslo.limit, so we can evolve it later...14:14
johnthetubaguyyeah, true14:14
lbragstadi had a script that i should have ported to a functional test14:15
lbragstadhttps://review.opendev.org/#/c/667242/714:15
johnthetubaguydo you have a fake keystone for functional tests, or a real one I guess?14:16
lbragstadwell - that example started as just a way to document how things work for service developers14:16
lbragstadideally, i wanted to give nova that document and say "here's how you can incorporate this stuff into your service"14:17
johnthetubaguyI was hoping the unit tests would get close enough for that, but a script is good14:17
lbragstadbut - i actually used it as a functional test with a devstack deployment14:17
johnthetubaguyah, nice14:17
lbragstadat which point, i should have just added a functional gate to oslo.limit14:17
lbragstadand ported the script to a test14:17
lbragstadsince it exercises most of the cases for flat enforcement14:18
johnthetubaguyso you have resource_filter... what was that for again?14:21
johnthetubaguyah, so I think I rolled that into deltas14:22
johnthetubaguyI only check the resources in the deltas dict14:22
lbragstadoh - it's a way for services to grab specific resource limits14:22
lbragstadinstead of all the things14:23
johnthetubaguyyeah, I just made deltas specify the specific resources to check (if the delta is zero) or any additional resource if > than 014:23
lbragstadoh - sure14:23
johnthetubaguyI think that is just what we did in Nova, more than thinking about it too much14:24
johnthetubaguyI was thinking in Cinder, you limit volumes and snapshots, so you kinda only want to check one of the resources on each API call14:24
lbragstadyeah14:25
johnthetubaguyI was thinking for GPU quotas, if you are using too many GPUs, it shouldn't stop you starting an non-GPU instance, etc14:25
lbragstadright14:28
johnthetubaguylbragstad: if its looking close, I am happy to pull this into a few chunks, and merge it with the patches you have up, what do you think? worth trying?14:29
lbragstadjohnthetubaguy sure - the library isn't past 1.0 yet14:30
lbragstadif we need to back something out, we can14:30
lbragstadat least it gets you a library you can start using in nova14:30
johnthetubaguyyeah, I was kinda expecting we will have to rework that interface as we find out how it feels14:31
lbragstadi expected that we would find oddities after the initial implementation14:31
johnthetubaguy+114:31
johnthetubaguythat point on endpoint_id is interesting... I am just checking our kolla-ansible logic... the problem is remembering a thing we didn't decide in advance (the id) vs stuff we know and set (the region name and endpoint type)14:32
lbragstadah - yeah14:33
lbragstadi think cmurphy and bnemec were having a discussion about that in the patch somewhere?14:33
johnthetubaguyyeah14:34
johnthetubaguyactually... fast forward upgrade (or whatever we call them now)14:35
johnthetubaguyskip level14:35
johnthetubaguyyou need the API off during the upgrade right?14:35
*** jawad_axd has joined #openstack-keystone14:36
johnthetubaguyso no way to fetch the service id you don't have in your config14:36
*** jamesmcarthur has joined #openstack-keystone14:37
*** jawad_axd has quit IRC14:40
bnemecI vaguely recall that, but I can't remember which one I was advocating for. :-)14:43
bnemecProbably the one that doesn't require a lookup, but who knows what me from six months ago was thinking?14:44
johnthetubaguy:)14:46
bnemecAlso, +1 to merging something even if it's not perfect. Until we release a 1.0 we're not committed to anything.14:47
openstackgerritJohn Garbutt proposed openstack/oslo.limit master: Add ksa connection logic  https://review.opendev.org/66608514:48
knikollao/14:52
*** jawad_axd has joined #openstack-keystone15:21
*** ayoung has quit IRC15:40
*** jawad_axd has quit IRC16:08
*** gyee has joined #openstack-keystone16:09
*** jmlowe has joined #openstack-keystone16:41
openstackgerritJohn Garbutt proposed openstack/oslo.limit master: Add ksa connection logic  https://review.opendev.org/66608516:59
openstackgerritJohn Garbutt proposed openstack/oslo.limit master: Pick between Flat and StrictTwoLevel enforcement  https://review.opendev.org/66644416:59
openstackgerritJohn Garbutt proposed openstack/oslo.limit master: Add flat enforcer  https://review.opendev.org/69531016:59
openstackgerritJohn Garbutt proposed openstack/oslo.limit master: WIP: Two level limit enforcer  https://review.opendev.org/69552716:59
openstackgerritJohn Garbutt proposed openstack/oslo.limit master: Fetch limits from keystone  https://review.opendev.org/69572416:59
*** jaosorior has quit IRC17:04
*** jmlowe has quit IRC17:10
*** awalende has joined #openstack-keystone17:23
*** awalende has quit IRC17:27
*** Guest24639 has joined #openstack-keystone17:32
*** Guest24639 is now known as mgagne_17:34
*** tesseract has quit IRC17:35
*** jaosorior has joined #openstack-keystone17:44
*** jamesmcarthur has quit IRC18:00
*** bnemec is now known as beekneemech18:04
*** cmurphy is now known as cmorpheus18:18
cmorpheuslbragstad: i think i was advocating for using endpoint types because it's easier for deployment tools, since they don't need to orchestrate creating the endpoint and getting the id before creating the config18:20
cmorpheusjohnthetubaguy: i don't think the keystone API needs to be off for upgrades? i mean we support rolling upgrades18:21
cmorpheusknikolla: we forgot to talk about it during the ptg but want to propose http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/support-federated-attr.html and http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/expiring-group-memberships.html to the ussuri director?18:22
cmorpheusdirectory*18:22
*** irclogbot_2 has quit IRC18:27
*** irclogbot_0 has joined #openstack-keystone18:30
johnthetubaguycmorpheus: I was just meaning for the skip level ones, I think we have to assume all services are turned off for those, but I might have the all messed up18:31
cmorpheusoh i see18:31
johnthetubaguyah, yeah, fast forward, I always forget the final name18:32
*** jaosorior has quit IRC19:08
*** Ben78 has quit IRC20:37
*** rcernin has joined #openstack-keystone20:49
*** raildo has quit IRC20:58
*** mgagne_ is now known as mgagne21:13
*** awalende has joined #openstack-keystone21:23
*** awalende has quit IRC21:28
*** spatel has joined #openstack-keystone21:38
*** spatel has quit IRC21:39
*** spatel has joined #openstack-keystone22:08
*** spatel has quit IRC22:13
*** spatel has joined #openstack-keystone22:15
*** rcernin has quit IRC22:24
*** spatel has quit IRC22:58
*** jmlowe has joined #openstack-keystone23:15

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