| *** jamesmcarthur has joined #openstack-keystone | 00:07 | |
| *** markvoelker has quit IRC | 00:09 | |
| *** liushuo has joined #openstack-keystone | 00:45 | |
| *** jamesmcarthur has quit IRC | 00:49 | |
| *** jamesmcarthur has joined #openstack-keystone | 00:50 | |
| *** jamesmcarthur has quit IRC | 00:55 | |
| *** markvoelker has joined #openstack-keystone | 01:05 | |
| *** lbragstad has quit IRC | 01:10 | |
| *** lifeless has joined #openstack-keystone | 01:14 | |
| *** jamesmcarthur has joined #openstack-keystone | 01:20 | |
| *** markvoelker has quit IRC | 01:39 | |
| *** gyee has quit IRC | 02:11 | |
| *** whoami-rajat has joined #openstack-keystone | 02:14 | |
| *** jamesmcarthur has quit IRC | 02:15 | |
| *** jamesmcarthur has joined #openstack-keystone | 02:15 | |
| *** jamesmcarthur has quit IRC | 02:18 | |
| *** jamesmcarthur has joined #openstack-keystone | 02:20 | |
| *** jamesmcarthur has quit IRC | 02:33 | |
| *** jamesmcarthur has joined #openstack-keystone | 02:33 | |
| *** markvoelker has joined #openstack-keystone | 02:36 | |
| *** lifeless has quit IRC | 02:38 | |
| *** lifeless has joined #openstack-keystone | 02:44 | |
| *** jamesmcarthur has quit IRC | 03:01 | |
| *** jamesmcarthur has joined #openstack-keystone | 03:02 | |
| *** jamesmcarthur has quit IRC | 03:04 | |
| *** jamesmcarthur has joined #openstack-keystone | 03:04 | |
| *** markvoelker has quit IRC | 03:09 | |
| *** jamesmcarthur has quit IRC | 03:43 | |
| *** jamesmcarthur has joined #openstack-keystone | 03:43 | |
| *** dave-mccowan has quit IRC | 03:54 | |
| *** jamesmcarthur has quit IRC | 03:58 | |
| *** markvoelker has joined #openstack-keystone | 04:06 | |
| *** whoami-rajat has quit IRC | 04:23 | |
| *** markvoelker has quit IRC | 04:40 | |
| *** vishalmanchanda has joined #openstack-keystone | 04:44 | |
| *** shyamb has joined #openstack-keystone | 04:46 | |
| *** vishalmanchanda has quit IRC | 04:49 | |
| *** vishalmanchanda has joined #openstack-keystone | 04:49 | |
| *** shyamb has quit IRC | 04:51 | |
| *** shyam89 has joined #openstack-keystone | 04:51 | |
| *** shyam89 has quit IRC | 04:56 | |
| *** shyamb has joined #openstack-keystone | 04:56 | |
| *** pcaruana|afk| has joined #openstack-keystone | 05:01 | |
| *** shyamb has quit IRC | 05:02 | |
| *** pcaruana|afk| has quit IRC | 05:04 | |
| *** pcaruana has joined #openstack-keystone | 05:04 | |
| *** shyamb has joined #openstack-keystone | 05:11 | |
| *** cmurphy is now known as cmurphy_afk | 05:14 | |
| *** shyamb has quit IRC | 05:31 | |
| *** shyamb has joined #openstack-keystone | 05:32 | |
| *** markvoelker has joined #openstack-keystone | 05:37 | |
| *** takamatsu has joined #openstack-keystone | 05:42 | |
| *** liushuo has quit IRC | 05:50 | |
| *** spsurya has joined #openstack-keystone | 06:08 | |
| *** markvoelker has quit IRC | 06:10 | |
| *** shyamb has quit IRC | 06:18 | |
| *** shyamb has joined #openstack-keystone | 06:37 | |
| *** xek_ has joined #openstack-keystone | 06:53 | |
| *** shyamb has quit IRC | 07:04 | |
| *** markvoelker has joined #openstack-keystone | 07:08 | |
| *** markvoelker has quit IRC | 07:13 | |
| *** vishalmanchanda has quit IRC | 07:14 | |
| *** tesseract has joined #openstack-keystone | 07:21 | |
| *** trident has quit IRC | 07:31 | |
| *** takamatsu has quit IRC | 07:32 | |
| *** trident has joined #openstack-keystone | 07:34 | |
| *** awalende has joined #openstack-keystone | 07:43 | |
| *** liushuo has joined #openstack-keystone | 07:50 | |
| *** gjayavelu has joined #openstack-keystone | 08:07 | |
| *** markvoelker has joined #openstack-keystone | 08:10 | |
| *** whoami-rajat has joined #openstack-keystone | 08:10 | |
| *** markvoelker has quit IRC | 08:14 | |
| *** takamatsu has joined #openstack-keystone | 08:19 | |
| *** rcernin has quit IRC | 08:23 | |
| *** jaosorior has joined #openstack-keystone | 08:29 | |
| *** gjayavelu has quit IRC | 08:36 | |
| *** imacdonn has quit IRC | 08:38 | |
| *** imacdonn has joined #openstack-keystone | 08:39 | |
| *** tkajinam has quit IRC | 08:51 | |
| *** liushuo_ has joined #openstack-keystone | 09:04 | |
| *** liushuo has quit IRC | 09:07 | |
| *** liushuo_ has quit IRC | 09:08 | |
| *** markvoelker has joined #openstack-keystone | 09:10 | |
| *** shyamb has joined #openstack-keystone | 09:15 | |
| *** markvoelker has quit IRC | 09:15 | |
| *** gmann has quit IRC | 09:33 | |
| *** markvoelker has joined #openstack-keystone | 10:11 | |
| *** shyamb has quit IRC | 10:13 | |
| *** markvoelker has quit IRC | 10:15 | |
| *** shyamb has joined #openstack-keystone | 10:18 | |
| *** shyamb has quit IRC | 10:29 | |
| *** shyamb has joined #openstack-keystone | 10:30 | |
| *** awalende has quit IRC | 10:49 | |
| *** awalende has joined #openstack-keystone | 10:50 | |
| *** whoami-rajat has quit IRC | 10:50 | |
| *** shyamb has quit IRC | 11:06 | |
| *** gmann has joined #openstack-keystone | 11:09 | |
| *** shyamb has joined #openstack-keystone | 11:20 | |
| *** awalende has quit IRC | 12:02 | |
| *** awalende has joined #openstack-keystone | 12:03 | |
| *** awalende has quit IRC | 12:07 | |
| *** shyamb has quit IRC | 12:12 | |
| *** markvoelker has joined #openstack-keystone | 12:13 | |
| *** awalende has joined #openstack-keystone | 12:16 | |
| *** markvoelker has quit IRC | 12:17 | |
| *** spsurya has quit IRC | 12:18 | |
| *** shyamb has joined #openstack-keystone | 12:19 | |
| *** shyamb has quit IRC | 12:33 | |
| *** lbragstad has joined #openstack-keystone | 12:37 | |
| ayoung | kmalloc, cmurphy_afk lbragstad this is the kind of thing we should be targetting: replacing keystonemiddleware with HAProxy to validate Keystone/JWT tokens https://www.haproxy.com/blog/using-haproxy-as-an-api-gateway-part-2-authentication/ | 12:49 |
|---|---|---|
| *** awalende has quit IRC | 12:59 | |
| *** awalende has joined #openstack-keystone | 13:00 | |
| *** pcaruana has quit IRC | 13:01 | |
| *** awalende_ has joined #openstack-keystone | 13:02 | |
| *** awalende has quit IRC | 13:04 | |
| *** awalende_ has quit IRC | 13:07 | |
| *** jaosorior has quit IRC | 13:11 | |
| *** markvoelker has joined #openstack-keystone | 13:14 | |
| *** markvoelker has quit IRC | 13:18 | |
| *** awalende has joined #openstack-keystone | 13:30 | |
| *** awalende has quit IRC | 13:35 | |
| *** dave-mccowan has joined #openstack-keystone | 13:40 | |
| *** jamesmcarthur has joined #openstack-keystone | 13:43 | |
| lbragstad | ayoung we'd need to decouple the service catalog from the token, right? | 13:44 |
| lbragstad | that and roles would need to be in the payload i think | 13:44 |
| gagehugo | o/ | 13:45 |
| * lbragstad hopes gagehugo and knikolla will be able to work together today | 13:46 | |
| gagehugo | haha | 13:46 |
| lbragstad | first franchise stanley cup, that's pretty cool | 13:46 |
| knikolla | haha | 13:46 |
| knikolla | i'm tired of everything we've won lately, tbh. | 13:47 |
| gagehugo | yup, it was a fun night last night | 13:47 |
| lbragstad | too much #winning | 13:47 |
| knikolla | too bad we have one of the worst soccer teams in the US... which is what i care about most. | 13:48 |
| gagehugo | heh | 13:49 |
| gagehugo | lbragstad I'm kinda relieved it's over, it's been a stressful 2 months | 13:59 |
| lbragstad | the blues had a helluva season | 13:59 |
| lbragstad | emotional rollcoaster | 13:59 |
| lbragstad | roller coaster* | 13:59 |
| gagehugo | literally a roller coaster | 13:59 |
| gagehugo | from last place to SC | 14:00 |
| lbragstad | crazy | 14:05 |
| lbragstad | last place in the league, too* | 14:05 |
| lbragstad | not just the central conference | 14:05 |
| gagehugo | yup | 14:05 |
| *** szaher has quit IRC | 14:05 | |
| ayoung | lbragstad, decouple? Yes, I think. The service catalog really does not have anything to do with the token these days | 14:06 |
| ayoung | I could see case where we would want to bind a token to a specific service, but that is not what things are doing now | 14:07 |
| lbragstad | right | 14:07 |
| lbragstad | imo - that falls inline with being able to scope a token to specific parts of the system | 14:07 |
| lbragstad | (e.g., breaking the system into a hierarchy, kind of like the service catalog) | 14:07 |
| *** xek_ has quit IRC | 14:13 | |
| *** markvoelker has joined #openstack-keystone | 14:14 | |
| *** szaher has joined #openstack-keystone | 14:19 | |
| *** markvoelker has quit IRC | 14:19 | |
| *** jaosorior has joined #openstack-keystone | 14:37 | |
| *** jaosorior has quit IRC | 14:45 | |
| *** raildo has joined #openstack-keystone | 14:58 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: WIP: use testresources for sharing across unit tests https://review.opendev.org/663065 | 15:03 |
| lbragstad | shoving ^ that to the side for a bit... | 15:04 |
| lbragstad | i'm going to get back to the system-scope+default roles work for a bit to be productive on something else | 15:07 |
| lbragstad | if anyone is interested in that puzzle, don't hesitate to pick away at it | 15:08 |
| johnthetubaguy | lbragstad: on the nova side, I did try to POC how it might look, ending with: https://review.opendev.org/#/c/663721 | 15:27 |
| johnthetubaguy | curious if you had some nice short cuts on your side, its a heap of work | 15:27 |
| *** gyee has joined #openstack-keystone | 15:35 | |
| lbragstad | johnthetubaguy oh - policy stuff? | 15:40 |
| johnthetubaguy | yeah, I saw you mention system-scope+default roles :) | 15:41 |
| lbragstad | oh - yeah | 15:41 |
| lbragstad | i need to finish applying those concepts to a few keystone APIs | 15:41 |
| lbragstad | but i need to look at the nova stuff, too | 15:41 |
| kmalloc | ayoung: i wrote code to do that at one point | 15:41 |
| kmalloc | ayoung: i support that concept | 15:41 |
| johnthetubaguy | lbragstad: yeah, seems like it will be a epic effort, for sure. Just wondering how to stage things in Nova land, to keep making progress. | 15:43 |
| lbragstad | johnthetubaguy right... | 15:43 |
| ayoung | lbragstad, kmalloc, we are going to want to push a change into oslo-context to get rid of the is_admin_context hack | 15:43 |
| lbragstad | ummmm - taking another look quick johnthetubaguy | 15:43 |
| lbragstad | johnthetubaguy starting here, right? https://review.opendev.org/#/c/657696/2 | 15:43 |
| johnthetubaguy | lbragstad: yeah, there is one admin API and one admin_or_owner API in the stack | 15:44 |
| johnthetubaguy | (and I get how much that sucks for a bunch of reasons, but its what we have) | 15:44 |
| kmalloc | ayoung: sure. | 15:45 |
| kmalloc | ayoung: i'm happy to see hacks removed. | 15:45 |
| lbragstad | johnthetubaguy the progression you have makes sense, i think | 15:49 |
| lbragstad | you're starting by moving things into code, then testing them, which is great | 15:50 |
| lbragstad | then it's just a matter of adjusting policies as needed to get the behavior you want | 15:50 |
| lbragstad | by default | 15:50 |
| johnthetubaguy | lbragstad: cool thanks for the sanity check | 15:50 |
| lbragstad | implementation specifics aside, we took a similar approach with keystone | 15:50 |
| johnthetubaguy | we are kinda changing the in code "defaults" based on the oslo_policy.enforce_scope thing, but that seems like the right behaviour, to move forward | 15:51 |
| lbragstad | for example? | 15:51 |
| lbragstad | (i think i know what you mean, but just making sure) | 15:51 |
| johnthetubaguy | lbragstad: this fun bit: https://review.opendev.org/#/c/663717/1/nova/policies/admin_password.py | 15:52 |
| johnthetubaguy | its really just dropping the deprecation, I probably should do a kwargs style thing there | 15:52 |
| lbragstad | oh.... | 15:53 |
| lbragstad | interesting? | 15:53 |
| lbragstad | i think we went about that in a different way | 15:53 |
| lbragstad | we always return the deprecation | 15:54 |
| johnthetubaguy | I was hoping there was a better way :) | 15:54 |
| lbragstad | idk if what we did is "better" | 15:54 |
| lbragstad | but - it always lists the rule as deprecated, we never conditionally deprecate things | 15:54 |
| lbragstad | lemme find an example | 15:54 |
| *** liushuo has joined #openstack-keystone | 15:55 | |
| lbragstad | johnthetubaguy let's look at https://opendev.org/openstack/keystone/src/branch/master/keystone/common/policies/domain.py#L54-L65 | 15:56 |
| lbragstad | in rocky - this is the rule we had for that policy https://opendev.org/openstack/keystone/src/branch/stable/rocky/keystone/common/policies/domain.py#L20 | 15:57 |
| lbragstad | which evaluated to - https://opendev.org/openstack/keystone/src/branch/stable/rocky/keystone/common/policies/base.py#L21-L23 | 15:57 |
| lbragstad | and again to https://opendev.org/openstack/keystone/src/branch/stable/rocky/keystone/common/policies/base.py#L37 | 15:58 |
| johnthetubaguy | cool | 15:58 |
| lbragstad | so - that's the *old* thing | 15:58 |
| johnthetubaguy | yeah | 15:58 |
| lbragstad | which means anyone with role:admin could get domains | 15:58 |
| johnthetubaguy | I think its always having the "OR" with the old rule that was worrying me | 15:58 |
| lbragstad | so - when we wrote the new rule | 15:58 |
| lbragstad | we were implicit in the system user definition | 15:59 |
| lbragstad | https://opendev.org/openstack/keystone/src/branch/master/keystone/common/policies/domain.py#L47 | 15:59 |
| lbragstad | so during the deprecation period - if an operator doesn't override the policy manually | 15:59 |
| lbragstad | you end up with | 15:59 |
| lbragstad | a system user OR domain user OR project user being able to get a domain (within reason) | 16:00 |
| lbragstad | if all of those fail | 16:00 |
| lbragstad | a project administrator can still get a domain (since the old policy was OR'd with the new policy) | 16:00 |
| lbragstad | but - role:reader and system_scope:all only works if a system-scoped token is used | 16:01 |
| lbragstad | it's just really explicit | 16:02 |
| lbragstad | johnthetubaguy that specific policy (identity:get_domains) isn't a great example of why oslo_policy.enforce_scope is important though | 16:04 |
| lbragstad | since the API can be called with multiple token scopes, we need to build that protection into the policy checks directly | 16:04 |
| lbragstad | to handle each case | 16:04 |
| johnthetubaguy | its a great example for the problems we were seeing mind | 16:05 |
| johnthetubaguy | that config stuff was basically to drop the OR-ing of the deprecated check that was missing the scope check | 16:06 |
| johnthetubaguy | so you know only "good new" tokens are allowed | 16:06 |
| lbragstad | otoh - if you have an api that is only supposed to be called with one specific scope, enforce_scope is more useful since you only need to set the role and the scope_types | 16:06 |
| johnthetubaguy | yeah | 16:06 |
| lbragstad | so there are a couple of options open to how you want to do it | 16:07 |
| johnthetubaguy | I hadn't quite gone through that thought process properly till doing that chain of patches | 16:07 |
| lbragstad | ++ | 16:07 |
| lbragstad | do you think you're still going to drop the OR'ing in nova manually? | 16:07 |
| lbragstad | or will the native deprecation logic in oslo.policy help you now? | 16:08 |
| johnthetubaguy | I might be miss-understanding what oslo.policy is giving me | 16:08 |
| johnthetubaguy | its the option to drop the deprecated rules, as an operator, if I know I am ready for "the new world" | 16:09 |
| johnthetubaguy | part of me wants us to first check the non-deprecated rule, and log a warning if we only pass a rule due to the deprecation | 16:09 |
| johnthetubaguy | a bit more like the scope enforement I guess | 16:10 |
| johnthetubaguy | my worry is operators that want the Reader roles, so can't have the "or anyone" fallback still active | 16:11 |
| johnthetubaguy | the real problem is we have checks that basically mean "any token with project scope x" as the deprecated rule | 16:11 |
| lbragstad | so - if operators want to jump into the new world | 16:12 |
| lbragstad | and policies are still deprecated | 16:12 |
| kmalloc | right. the transition built into olso.policy is to allow NEW or OLD (if nothing is overridden, deprecated is the old) | 16:12 |
| lbragstad | then they need to explicitly override the old policies with the new policies | 16:12 |
| kmalloc | if they want only the new form, they can override with just the NEW rule. | 16:12 |
| lbragstad | then oslo.policy won't OR anything | 16:12 |
| johnthetubaguy | yeah, that's true | 16:13 |
| lbragstad | when the deprecations are removed | 16:13 |
| kmalloc | if a rule is supplied in policy.json, no or is done | 16:13 |
| kmalloc | eventually you as Nova drop the deprecated, which means only new-style works. | 16:13 |
| kmalloc | but that is on your timeline | 16:13 |
| kmalloc | (if ever) | 16:13 |
| lbragstad | when the deprecations are removed, they're just dealing with defaults that are in code, and the oslo policy CLI tools will tell them they can remove those redundant policies | 16:13 |
| johnthetubaguy | true... | 16:14 |
| kmalloc | lbragstad: we should check... if someone supplies the new rule in policy.json, it should prevent an OR with the deprecated | 16:14 |
| johnthetubaguy | the way I wrote the POC patch, at least its only six rules they need to override, or something like that | 16:14 |
| kmalloc | even if the new rule is the same as the in-code new. | 16:14 |
| kmalloc | just realized that may not be the case | 16:14 |
| lbragstad | that's the way it works, the last time i tested it | 16:14 |
| kmalloc | ok good. | 16:14 |
| johnthetubaguy | kmalloc: my reading of the code said that is the case | 16:14 |
| lbragstad | i recorded a demo with domain admin support for the user API | 16:14 |
| johnthetubaguy | I discounted that option before... but it does work | 16:15 |
| lbragstad | and i opted into using only the new policies for that recording | 16:15 |
| kmalloc | yeah, it's the easiest way to not break people | 16:15 |
| lbragstad | it's kind of a hot mess code-wise | 16:15 |
| lbragstad | the deprecation logic in oslo.policy specifically | 16:15 |
| johnthetubaguy | so I just discovered that :D | 16:16 |
| lbragstad | i'm sorry :( | 16:16 |
| lbragstad | my condolences | 16:16 |
| *** markvoelker has joined #openstack-keystone | 16:16 | |
| kmalloc | oslo.policy was somewhat of a hot mess before we got to it | 16:16 |
| kmalloc | making new stuff not really less of a hot mess | 16:16 |
| johnthetubaguy | ah, I meant my code not oslo.policy | 16:16 |
| lbragstad | to be fair... it's trying to do a lot of stuff... | 16:16 |
| kmalloc | and your code is based on oslo.policy | 16:16 |
| kmalloc | sooooo | 16:16 |
| johnthetubaguy | FWIW, I didn't find oslo.policy too bad | 16:16 |
| johnthetubaguy | but that is a Nova person talking, so... | 16:17 |
| lbragstad | and having oslo.policy be smart during the migration is attributing to some of the cruft | 16:17 |
| bnemec | kmalloc: I don't know what you mean. :-P | 16:17 |
| bnemec | You should have seen the old quota module in oslo-incubator. | 16:17 |
| lbragstad | once projects define scope types properly, add testing, and fix check strings, we should be able to clean up some of oslo.policy | 16:17 |
| kmalloc | bnemec: i did. remember i worked on openstack back in diablo, essex, folsom :) | 16:17 |
| kmalloc | bnemec: specifically nova to start | 16:18 |
| * johnthetubaguy remembers having one half of glance for swift as a backport, fun times | 16:18 | |
| johnthetubaguy | yeah... simpler, but more broken times | 16:19 |
| bnemec | :-) | 16:19 |
| johnthetubaguy | anyways, I kinda like the proposal here, just overide the policy rule with the code default to opt in | 16:19 |
| johnthetubaguy | I discounted it, but its like four rule overrides, doesn't seem too bad | 16:19 |
| johnthetubaguy | Thinking about lines 69-85 in here: https://review.opendev.org/#/c/663716/1/nova/policies/base.py | 16:20 |
| lbragstad | i imagine that to be a pretty low bar for people who have been wanting this for a long time | 16:20 |
| johnthetubaguy | I might need to "tweak" the description in there | 16:20 |
| johnthetubaguy | lbragstad: ++ | 16:20 |
| *** markvoelker has quit IRC | 16:20 | |
| lbragstad | once they specify those overrides, they just need to wait for the deprecations to be removed and they can use tooling to detect that | 16:21 |
| johnthetubaguy | yeah, the more I think about your idea, the more I am liking it | 16:23 |
| johnthetubaguy | sweet, I think this was the missing bit in head (till I find the next one!) | 16:23 |
| lbragstad | awesome! | 16:24 |
| lbragstad | clear as mud, right? | 16:24 |
| johnthetubaguy | yeah, a nice muddy puddle | 16:25 |
| johnthetubaguy | :) | 16:25 |
| *** jamesmcarthur_ has joined #openstack-keystone | 16:29 | |
| lbragstad | johnthetubaguy i also took another look at the unified limit stuff you have up for review | 16:31 |
| lbragstad | (spec and code) | 16:31 |
| *** jamesmcarthur has quit IRC | 16:32 | |
| lbragstad | johnthetubaguy i need to take a look at the oslo.policy changes, but i'm wondering about the terminilogy? | 16:33 |
| lbragstad | terminology* | 16:34 |
| lbragstad | not sure if you saw my comment about that | 16:34 |
| johnthetubaguy | yeah, I spotted that | 16:34 |
| johnthetubaguy | I am not sure about "claim" if I am honest, but that might be because I keep thinking of how Nova used to write claims/reservations in the DB | 16:34 |
| lbragstad | oh - so that term is already overloaded in nova? | 16:35 |
| johnthetubaguy | well, that might be just in my head | 16:37 |
| * lbragstad nods | 16:38 | |
| lbragstad | i was originally thinking about having something like a ProjectClaim object | 16:39 |
| lbragstad | https://review.opendev.org/#/c/600266/6/oslo_limit/limit.py | 16:39 |
| *** joshualyle has joined #openstack-keystone | 16:40 | |
| lbragstad | and a claim would have a one to many relationship with resources | 16:40 |
| lbragstad | then you'd pass a claim object to the enforcer | 16:40 |
| johnthetubaguy | with counting I quite like the delta model, where a delta of zero means just check the current usage | 16:41 |
| johnthetubaguy | you need to pass zero so you know which resources to check, I guess | 16:42 |
| johnthetubaguy | but clearly that is quite a different sort of API | 16:42 |
| lbragstad | ok - so would delta just be an integer? | 16:47 |
| lbragstad | or would it be an object that represents the resource and delta to check? | 16:47 |
| lbragstad | my thinking behind representing all of this as an object of some kind is that it would prevent the services from doing things like: | 16:48 |
| lbragstad | enforcer.check_limit('cores', 8) | 16:49 |
| lbragstad | enforcer.check_limit('ram_mb', 16) | 16:49 |
| lbragstad | enforcer.check_limit('server_count', 1) | 16:49 |
| johnthetubaguy | so I think we need to pass multiple at once | 16:49 |
| lbragstad | so - that would just be: | 16:49 |
| lbragstad | enforcer.check(delta, project_id) | 16:50 |
| johnthetubaguy | check_limits({cores: 8, ram_mb: 9}) | 16:50 |
| johnthetubaguy | yeah | 16:50 |
| lbragstad | ok - right | 16:50 |
| lbragstad | so we're not expecting multiple round-trips into oslo.limit | 16:50 |
| johnthetubaguy | my reason is purely efficiency, we basically get a count of all resources in one go | 16:50 |
| johnthetubaguy | yeah | 16:50 |
| lbragstad | ++ | 16:50 |
| lbragstad | cool - i think we agree on that then | 16:50 |
| johnthetubaguy | yeah, +1 | 16:51 |
| lbragstad | so - i think the big question left is what that specific API looks like and how we represent resources and deltas from the service being passed into oslo | 16:51 |
| lbragstad | that and we need to figure out how the current usage gets passed into oslo, too | 16:52 |
| johnthetubaguy | yeah, something simple is my preference, but beyond that | 16:52 |
| johnthetubaguy | ah... so I think I had an example that might help with that | 16:52 |
| lbragstad | ok - let's start with the usage | 16:52 |
| johnthetubaguy | yeah | 16:52 |
| lbragstad | because we know that *has* to come from the service and we've discussed a couple of options for it | 16:52 |
| lbragstad | one of which was to give oslo.limit a callback to calculate enforcement | 16:53 |
| lbragstad | that didn't seem to get much traction | 16:54 |
| johnthetubaguy | https://github.com/JohnGarbutt/oslo.limit/commit/a5b908046fd904c25b6cd15c65266c747774b5ab#diff-10204c54762346cb8b1e7dda368866ecR45 | 16:54 |
| lbragstad | mmmm | 16:54 |
| lbragstad | so - you kept that in your implementation | 16:54 |
| johnthetubaguy | so callback is my preference, because it makes the hierarchy simple | 16:54 |
| lbragstad | oh - sure | 16:55 |
| lbragstad | because oslo.limit gets a list of projects from keystone | 16:55 |
| lbragstad | and it iterates the list with the callback, that's right | 16:55 |
| johnthetubaguy | yeah | 16:55 |
| johnthetubaguy | means you can count each project_id once, even though one project goes into two calculations | 16:55 |
| johnthetubaguy | i.e. you could the whole tree usage, and the per project usage | 16:56 |
| johnthetubaguy | but we might be getting ahead of things | 16:56 |
| lbragstad | well - once we populate the tree | 16:56 |
| lbragstad | with usage information | 16:56 |
| lbragstad | you should be able to do both calculations | 16:56 |
| johnthetubaguy | yeah | 16:56 |
| lbragstad | limits will already be calculated, obviously | 16:57 |
| *** jamesmcarthur_ has quit IRC | 16:57 | |
| johnthetubaguy | I was thinking this is the simple flat checker: https://github.com/JohnGarbutt/oslo.limit/commit/a5b908046fd904c25b6cd15c65266c747774b5ab#diff-0766eeec835e4f691c335a86b858b788R150 which calls this: https://review.opendev.org/#/c/615180/9/nova/limits/keystone.py@49 | 16:57 |
| *** jamesmcarthur has joined #openstack-keystone | 16:58 | |
| johnthetubaguy | as you say, you just expand out for the tree case | 16:58 |
| lbragstad | sure | 16:58 |
| lbragstad | so, flat enforcement only cares about one thing | 16:58 |
| lbragstad | and that's the current project | 16:58 |
| johnthetubaguy | yeah | 16:58 |
| johnthetubaguy | just gets called multiple times in the tree case | 16:59 |
| lbragstad | checking the tree will be more complicated implementation details of the strict-two-level model | 16:59 |
| johnthetubaguy | yeah, I think so | 16:59 |
| lbragstad | ok - assuming each enforcement model implements an interface in oslo.limit | 17:00 |
| lbragstad | what should that interface look like? | 17:00 |
| johnthetubaguy | I went for this: https://review.opendev.org/#/c/615180/9/nova/limits/keystone.py@127 | 17:01 |
| johnthetubaguy | hence you question on the delta name I guess | 17:01 |
| johnthetubaguy | I should run soon I am afraid... | 17:02 |
| johnthetubaguy | would love to understand the alternatives though, and see if they work better | 17:03 |
| lbragstad | ok - this helps, let me take another look after having this discussion | 17:04 |
| lbragstad | if i come up with an alternative interface, i'll leave it on the review | 17:04 |
| * lbragstad remembers a mess of callbacks being an issue | 17:05 | |
| lbragstad | but i think that was related to the verification/race condition functionality | 17:05 |
| johnthetubaguy | cool | 17:05 |
| lbragstad | and what to do with resources if they needed to be cleaned up | 17:05 |
| johnthetubaguy | ah yeah, I think its easier to skip all that for v1 | 17:05 |
| lbragstad | ok - good to know | 17:06 |
| johnthetubaguy | currently can't see a use for it in Nova | 17:06 |
| johnthetubaguy | ironically | 17:06 |
| lbragstad | verification, you mean? | 17:06 |
| johnthetubaguy | sorry, running off now | 17:06 |
| lbragstad | ok - catch up with you later | 17:06 |
| *** pcaruana has joined #openstack-keystone | 17:09 | |
| *** whoami-rajat has joined #openstack-keystone | 17:38 | |
| *** jamesmcarthur has quit IRC | 17:58 | |
| *** gyee has quit IRC | 18:04 | |
| *** markvoelker has joined #openstack-keystone | 18:17 | |
| *** gyee has joined #openstack-keystone | 18:19 | |
| *** markvoelker has quit IRC | 18:22 | |
| *** raildo has quit IRC | 18:53 | |
| *** raildo has joined #openstack-keystone | 18:54 | |
| *** hoonetorg has quit IRC | 18:55 | |
| *** jamesmcarthur has joined #openstack-keystone | 18:56 | |
| *** hoonetorg has joined #openstack-keystone | 19:00 | |
| *** bnemec has quit IRC | 19:06 | |
| *** markvoelker has joined #openstack-keystone | 19:18 | |
| *** markvoelker has quit IRC | 19:23 | |
| *** jamesmcarthur has quit IRC | 19:24 | |
| *** takamatsu has quit IRC | 19:32 | |
| openstackgerrit | Merged openstack/keystone master: Remove deprecated admin_endpoint https://review.opendev.org/664246 | 19:38 |
| *** whoami-rajat has quit IRC | 19:48 | |
| *** xek has joined #openstack-keystone | 19:50 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Implement system scope and default roles for token API https://review.opendev.org/665231 | 20:18 |
| *** markvoelker has joined #openstack-keystone | 20:19 | |
| *** markvoelker has quit IRC | 20:24 | |
| *** pcaruana has quit IRC | 20:36 | |
| *** bnemec has joined #openstack-keystone | 20:52 | |
| *** xek has quit IRC | 20:57 | |
| lbragstad | in case anyone really *really* missed reviewing patches for scope and default roles - you're in luck | 20:59 |
| lbragstad | ^ | 20:59 |
| *** mchlumsky has quit IRC | 21:07 | |
| gagehugo | :) | 21:09 |
| *** takamatsu has joined #openstack-keystone | 21:13 | |
| *** markvoelker has joined #openstack-keystone | 21:20 | |
| *** markvoelker has quit IRC | 21:24 | |
| *** bnemec has quit IRC | 22:05 | |
| *** jamesmcarthur has joined #openstack-keystone | 22:18 | |
| *** takamatsu has quit IRC | 22:25 | |
| *** dave-mccowan has quit IRC | 22:26 | |
| *** rcernin has joined #openstack-keystone | 22:45 | |
| *** tesseract has quit IRC | 22:48 | |
| *** liushuo_ has joined #openstack-keystone | 22:48 | |
| *** dave-mccowan has joined #openstack-keystone | 22:49 | |
| *** tkajinam has joined #openstack-keystone | 22:51 | |
| *** liushuo has quit IRC | 22:52 | |
| *** raildo has quit IRC | 23:04 | |
| *** dave-mccowan has quit IRC | 23:20 | |
| *** markvoelker has joined #openstack-keystone | 23:22 | |
| *** jamesmcarthur has quit IRC | 23:24 | |
| *** markvoelker has quit IRC | 23:26 | |
| *** dave-mccowan has joined #openstack-keystone | 23:39 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!