| *** edmondsw has joined #openstack-keystone | 00:28 | |
| *** edmondsw has quit IRC | 00:33 | |
| empty_cup | when operating devstack, should it run from the master branch? | 00:57 |
|---|---|---|
| empty_cup | is the master branch a "develop" branch? | 00:58 |
| empty_cup | i'm rerunning ./stack.sh while on the stable/queens branch. Originally it was situated on master. | 01:05 |
| empty_cup | What prompted this path was the user showing as unauthenticated when originally set with a password and options showing up as empty | 01:06 |
| *** edmondsw has joined #openstack-keystone | 02:16 | |
| *** edmondsw has quit IRC | 02:21 | |
| *** d0ugal has quit IRC | 02:49 | |
| *** d0ugal has joined #openstack-keystone | 02:50 | |
| *** empty_cup has quit IRC | 03:51 | |
| *** dikonoor has joined #openstack-keystone | 03:51 | |
| *** pooja_jadhav has joined #openstack-keystone | 04:30 | |
| *** links has joined #openstack-keystone | 04:39 | |
| *** pcichy has quit IRC | 04:55 | |
| *** jaosorior has joined #openstack-keystone | 05:12 | |
| *** belmoreira has joined #openstack-keystone | 05:37 | |
| *** masber has joined #openstack-keystone | 05:41 | |
| *** d0ugal has quit IRC | 05:48 | |
| *** masuberu has joined #openstack-keystone | 05:51 | |
| *** edmondsw has joined #openstack-keystone | 05:53 | |
| *** d0ugal has joined #openstack-keystone | 05:54 | |
| *** masber has quit IRC | 05:55 | |
| *** edmondsw has quit IRC | 05:58 | |
| *** masuberu has quit IRC | 06:02 | |
| *** martinus__ has joined #openstack-keystone | 06:33 | |
| *** Guest1988 has joined #openstack-keystone | 07:10 | |
| *** Guest1988 has quit IRC | 07:17 | |
| *** hoonetorg has quit IRC | 07:41 | |
| *** edmondsw has joined #openstack-keystone | 07:42 | |
| *** edmondsw has quit IRC | 07:47 | |
| *** hoonetorg has joined #openstack-keystone | 07:55 | |
| *** panbalag has joined #openstack-keystone | 09:30 | |
| *** Horrorcat has left #openstack-keystone | 10:12 | |
| *** Horrorcat has joined #openstack-keystone | 10:17 | |
| *** Horrorcat has left #openstack-keystone | 10:23 | |
| *** Horrorcat has joined #openstack-keystone | 10:28 | |
| *** nicolasbock has joined #openstack-keystone | 10:30 | |
| *** raildo has joined #openstack-keystone | 10:45 | |
| openstackgerrit | Merged openstack/keystone master: Invalidate the shadow user cache when deleting a user https://review.openstack.org/561908 | 10:53 |
| *** panbalag has quit IRC | 11:14 | |
| *** aloga has quit IRC | 11:14 | |
| *** dave-mccowan has joined #openstack-keystone | 11:27 | |
| *** dave-mccowan has quit IRC | 11:31 | |
| *** mvk has quit IRC | 11:32 | |
| *** dave-mcc_ has joined #openstack-keystone | 11:33 | |
| *** edmondsw has joined #openstack-keystone | 12:07 | |
| *** ninag has joined #openstack-keystone | 12:22 | |
| *** ninag has quit IRC | 12:22 | |
| *** mvk has joined #openstack-keystone | 12:28 | |
| *** panbalag has joined #openstack-keystone | 12:41 | |
| *** panbalag has left #openstack-keystone | 12:42 | |
| *** jaosorior has quit IRC | 12:43 | |
| *** mchlumsky has joined #openstack-keystone | 12:44 | |
| *** mchlumsky has quit IRC | 13:07 | |
| *** mchlumsky has joined #openstack-keystone | 13:09 | |
| *** panbalag has joined #openstack-keystone | 13:17 | |
| *** panbalag has left #openstack-keystone | 13:20 | |
| *** links has quit IRC | 13:22 | |
| gagehugo | O/ | 13:24 |
| *** superdan is now known as dansmith | 13:29 | |
| *** ayoung has quit IRC | 13:30 | |
| *** belmorei_ has joined #openstack-keystone | 13:31 | |
| *** belmoreira has quit IRC | 13:34 | |
| *** jroll has quit IRC | 13:36 | |
| *** lbragstad has joined #openstack-keystone | 13:37 | |
| *** ChanServ sets mode: +o lbragstad | 13:37 | |
| *** jroll has joined #openstack-keystone | 13:38 | |
| *** jmlowe_ has quit IRC | 13:45 | |
| *** panbalag has joined #openstack-keystone | 13:47 | |
| *** panbalag has left #openstack-keystone | 13:47 | |
| *** r-daneel has joined #openstack-keystone | 13:47 | |
| hrybacki | o/ | 13:55 |
| kmalloc | Zzzz | 13:56 |
| kmalloc | ;) | 13:56 |
| lbragstad | o/ | 14:00 |
| *** felipemonteiro has joined #openstack-keystone | 14:05 | |
| *** aloga has joined #openstack-keystone | 14:06 | |
| *** felipemonteiro_ has joined #openstack-keystone | 14:07 | |
| *** felipemonteiro has quit IRC | 14:11 | |
| openstackgerrit | Matt Riedemann proposed openstack/oslo.policy master: make the sphinxpolicygen extension handle multiple input/output files https://review.openstack.org/564627 | 14:11 |
| *** jmlowe has joined #openstack-keystone | 14:21 | |
| *** panbalag has joined #openstack-keystone | 14:29 | |
| *** panbalag has left #openstack-keystone | 14:39 | |
| *** spilla has joined #openstack-keystone | 14:53 | |
| *** felipemonteiro_ has quit IRC | 15:19 | |
| mordred | kmalloc, lbragstad there's a failure in the openstacksdk patch that I made to have it consume the ksa alias/discovery stuff that looks real - although it looks VERY strange | 15:22 |
| kmalloc | Hmm | 15:22 |
| mordred | kmalloc, lbragstad: tl;dr - it looks like cinder endpoints in devstack are being discovered incorrectly - missing the version | 15:22 |
| kmalloc | Doh! | 15:23 |
| mordred | I'm digging in now to figure out if it's a bug in ksa or a bug in sdk's use of ksa | 15:23 |
| kmalloc | This is KSA master or a release? | 15:23 |
| mordred | master | 15:23 |
| mordred | this is the "test the new ksa patches with shade/sdk before landing them" | 15:23 |
| kmalloc | Ok. Good hope that means no release with the bug. ;) | 15:24 |
| kmalloc | Also yay for that test. | 15:24 |
| mordred | http://logs.openstack.org/94/564494/1/check/openstacksdk-functional-devstack-tips/52ba4b2/testr_results.html.gz is the failed test run | 15:25 |
| knikolla | o/ | 15:25 |
| mordred | kmalloc: yah. I mean, also it's a patch to remove discovery related logic from sdk and replace it with just passing parameters to ksa ... which is awesome - but it's entirely possible there's a nuance in that patch that's bong | 15:26 |
| kmalloc | Walking teh dog, those.logs don't load well (too big) on mobile (any logs) | 15:26 |
| kmalloc | Will look as soon as I am home. | 15:26 |
| mordred | kmalloc: bah. get a bigger phone | 15:26 |
| kmalloc | It is actual data volume | 15:26 |
| kmalloc | This is a pixel XL 2. Chrome just crashes with our logs | 15:26 |
| kmalloc | (it is also a bad phone imo) | 15:26 |
| mordred | well, you could use a laptop as a phone and then you could look at logs on your phone while you walk the dog | 15:27 |
| kmalloc | Oh that is the report not the full log | 15:28 |
| kmalloc | That loaded ok | 15:28 |
| mordred | the first failure actually looks like it's doing the right things (ignore for a sec the fact that it's a test of v2 and it's talking to v3) | 15:30 |
| kmalloc | Ahh | 15:30 |
| kmalloc | Hehe | 15:30 |
| *** Horrorcat has left #openstack-keystone | 15:36 | |
| *** Horrorcat has joined #openstack-keystone | 15:41 | |
| *** ayoung has joined #openstack-keystone | 15:43 | |
| *** Horrorcat has left #openstack-keystone | 15:47 | |
| *** Horrorcat has joined #openstack-keystone | 15:52 | |
| *** belmorei_ has quit IRC | 16:03 | |
| *** Kumar has joined #openstack-keystone | 16:11 | |
| *** felipemonteiro has joined #openstack-keystone | 16:12 | |
| *** Kumar has quit IRC | 16:21 | |
| *** felipemonteiro_ has joined #openstack-keystone | 16:26 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Use the provider_api module in limit controller https://review.openstack.org/562712 | 16:26 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Add configuration option for enforcement models https://review.openstack.org/562713 | 16:26 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Add policy for limit model protection https://review.openstack.org/562714 | 16:26 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Implement enforcement model logic in Manager https://review.openstack.org/562715 | 16:26 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Expose endpoint to return enforcement model https://review.openstack.org/562716 | 16:26 |
| *** felipemonteiro has quit IRC | 16:29 | |
| *** itlinux has joined #openstack-keystone | 16:33 | |
| * lbragstad goes to take a run over lunch | 16:43 | |
| *** felipemonteiro_ has quit IRC | 16:46 | |
| *** felipemonteiro_ has joined #openstack-keystone | 16:46 | |
| *** mchlumsky has quit IRC | 16:56 | |
| *** mchlumsky has joined #openstack-keystone | 16:58 | |
| *** mchlumsky_ has joined #openstack-keystone | 17:02 | |
| *** mchlumsky has quit IRC | 17:03 | |
| *** mchlumsky has joined #openstack-keystone | 17:07 | |
| *** mchlumsky_ has quit IRC | 17:07 | |
| *** dikonoor has quit IRC | 17:18 | |
| *** itlinux has quit IRC | 17:29 | |
| *** r-daneel has quit IRC | 18:06 | |
| *** r-daneel has joined #openstack-keystone | 18:06 | |
| *** mvk has quit IRC | 18:14 | |
| *** itlinux has joined #openstack-keystone | 18:17 | |
| *** dave-mcc_ has quit IRC | 18:21 | |
| *** dave-mccowan has joined #openstack-keystone | 18:28 | |
| *** felipemonteiro__ has joined #openstack-keystone | 18:29 | |
| *** sonuk has joined #openstack-keystone | 18:30 | |
| *** felipemonteiro_ has quit IRC | 18:32 | |
| *** mvk has joined #openstack-keystone | 18:47 | |
| lbragstad | dims: just got done parsing the google doc link you added to the jwt spec | 18:57 |
| lbragstad | it sounds like they are iterating on jwt to provide service tokens? | 18:57 |
| dims | right, this one seems to be under discussion still | 18:57 |
| lbragstad | so a workload is equivalent to a service then? | 18:58 |
| lbragstad | i'm still trying to build a mapping of terms | 18:59 |
| lbragstad | it appears they're looking to do nested jwts to limit the power of service scoped token? | 19:03 |
| *** sonuk has quit IRC | 19:04 | |
| *** Horrorcat has left #openstack-keystone | 19:05 | |
| *** jmlowe has quit IRC | 19:07 | |
| *** itlinux has quit IRC | 19:07 | |
| dims | @lbragstad : i am not sure :) we may have to go to one of their meetings may be in a week or so (this week is KubeconEU) | 19:08 |
| lbragstad | oh - right | 19:09 |
| lbragstad | dims: is there a spec for just the jwt work they did? | 19:09 |
| lbragstad | this seems like it's reusing some of that to solve a different problem, so i'm just wondering if there is another document that has more context | 19:10 |
| dims | @lbragstad : let me check | 19:14 |
| dims | @lbragstad : https://github.com/kubernetes/community/pull/1460/commits/6e209490c441d8df84b6b5d8e352c0e2491a41bd may be? | 19:19 |
| dims | @lbragstad : was looking through notes from the container identity work group - https://docs.google.com/document/d/1uH60pNr1-jBn7N2pEcddk6-6NTnmV5qepwKUJe9tMRo/edit?ts=59a03344#heading=h.n00r55m5f4gw | 19:20 |
| *** jmlowe has joined #openstack-keystone | 19:23 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Implement enforcement model logic in Manager https://review.openstack.org/562715 | 19:25 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Expose endpoint to return enforcement model https://review.openstack.org/562716 | 19:25 |
| lbragstad | dims: thanks | 19:25 |
| *** d0ugal has quit IRC | 19:45 | |
| *** d0ugal has joined #openstack-keystone | 19:46 | |
| *** d0ugal_ has joined #openstack-keystone | 20:00 | |
| *** dave-mccowan has quit IRC | 20:02 | |
| *** d0ugal has quit IRC | 20:02 | |
| *** itlinux has joined #openstack-keystone | 20:06 | |
| *** pcichy has joined #openstack-keystone | 20:12 | |
| *** felipemonteiro__ has quit IRC | 20:12 | |
| *** dave-mccowan has joined #openstack-keystone | 20:17 | |
| *** itlinux has quit IRC | 20:17 | |
| *** d0ugal_ has quit IRC | 20:18 | |
| *** itlinux has joined #openstack-keystone | 20:19 | |
| *** d0ugal_ has joined #openstack-keystone | 20:19 | |
| *** jmlowe has quit IRC | 20:21 | |
| *** d0ugal_ has quit IRC | 20:36 | |
| *** itlinux has quit IRC | 20:36 | |
| *** raildo has quit IRC | 20:39 | |
| *** d0ugal_ has joined #openstack-keystone | 20:43 | |
| *** pcichy has quit IRC | 20:45 | |
| *** dave-mccowan has quit IRC | 20:55 | |
| lbragstad | anyone around to talk limits? | 20:56 |
| *** martinus__ has quit IRC | 21:02 | |
| *** edmondsw has quit IRC | 21:07 | |
| *** edmondsw_ has joined #openstack-keystone | 21:11 | |
| *** edmondsw_ has quit IRC | 21:15 | |
| *** d0ugal_ has quit IRC | 21:32 | |
| ayoung | lbragstad, I am, but I don't think I count. Have not really thought about limites in a while. | 21:35 |
| ayoung | Just need a sounding board, fire away | 21:35 |
| *** d0ugal_ has joined #openstack-keystone | 21:35 | |
| * lbragstad thanks ayoung for being his rubber duck | 21:37 | |
| lbragstad | ok | 21:37 |
| lbragstad | i'm reviewing the current specification for CERNs limit use cases | 21:37 |
| lbragstad | https://review.openstack.org/#/c/540803/9/specs/keystone/rocky/hierarchical-unified-limits.rst | 21:37 |
| lbragstad | it's expected to be a "strict" model, it in that appears to lean on the side of being explicit versus implicit | 21:38 |
| *** d0ugal_ has quit IRC | 21:38 | |
| ayoung | Good | 21:38 |
| lbragstad | in queens we implemented registered limits and project limits | 21:38 |
| *** d0ugal_ has joined #openstack-keystone | 21:39 | |
| lbragstad | where registered limits are something that need to be created before a limit can be associated to a project | 21:39 |
| ayoung | "A child may have no more quota than it's parent. The | 21:39 |
| ayoung | sum of all **direct children** is must be <= the | 21:39 |
| ayoung | parent. all children would have to have default quota | 21:39 |
| ayoung | equal to its parent's." | 21:39 |
| ayoung | } | 21:39 |
| lbragstad | they also act as a default | 21:39 |
| lbragstad | so an operator could registered a limit of 10 cores for the compute service for a deployment | 21:39 |
| ayoung | So...management of Quota happens inside Keystone, where we have full access to all data. Enforcement makes a call to Keystone? | 21:40 |
| lbragstad | yeah - pretty much, the limit and it's validation is stored within keystone | 21:40 |
| ayoung | go on...I have about 5 minutes | 21:40 |
| lbragstad | and exposed to services and consumed via a library to make it easier to adopt/understand | 21:40 |
| lbragstad | so - given a registered limit of 10 cores | 21:41 |
| lbragstad | each project without an explicit limit "override" or project limit | 21:41 |
| lbragstad | will assume a default limit of 10 core | 21:41 |
| lbragstad | cores* | 21:41 |
| lbragstad | now - imagine you have project A, whose limit is 20 and usage is 1 | 21:41 |
| lbragstad | and A has two children projects | 21:41 |
| lbragstad | B and C | 21:41 |
| lbragstad | neither have project overrides | 21:42 |
| lbragstad | so - they assume the default value for cores set by the registered limit | 21:42 |
| lbragstad | (e.g. 10 a piece) | 21:42 |
| ayoung | a piece? | 21:42 |
| lbragstad | yeah - becaues of the registered limit | 21:42 |
| *** felipemonteiro has joined #openstack-keystone | 21:42 | |
| ayoung | so the default is each project gets 10, including child projects | 21:42 |
| lbragstad | let's say the parent is A in this example and it has a project limit of 20 cores | 21:43 |
| lbragstad | (so overriding the default | 21:43 |
| ayoung | and that is OK, cuz there are two, and the parent project has 20 | 21:43 |
| lbragstad | and B and C are siblings | 21:43 |
| lbragstad | ok - here's where it get's confusing | 21:43 |
| lbragstad | (for me at least) | 21:43 |
| lbragstad | should you be able to create project D, which is a sibling to B and C without a project limit override? | 21:44 |
| ayoung | I never found a solution to this problem that I liked | 21:44 |
| lbragstad | because SUM(B.limit, C.limit, D.limit) > A.limit | 21:44 |
| ayoung | I would say yes | 21:44 |
| lbragstad | ok - so let's say we can do that | 21:45 |
| lbragstad | we now have B, C, and D under A | 21:45 |
| ayoung | So... | 21:45 |
| lbragstad | all children are relaying on the default value of 10 cores and A's limit is still 20 | 21:45 |
| *** felipemonteiro_ has joined #openstack-keystone | 21:46 | |
| ayoung | If A has a quoate of 20, and A creates B and assignes to it 10, A then has 10 remaining...right? | 21:46 |
| ayoung | it is tracked that way? | 21:46 |
| lbragstad | yeah - i think so | 21:46 |
| lbragstad | so - let's assume | 21:47 |
| lbragstad | A.usage = 1 | 21:47 |
| lbragstad | B.usage = 2 | 21:47 |
| lbragstad | C.usage = 10 | 21:47 |
| ayoung | But usage is not tracked in Keystone | 21:47 |
| lbragstad | right... | 21:47 |
| ayoung | only in Nova | 21:47 |
| lbragstad | this is where is get's really fuzzy | 21:47 |
| lbragstad | D.usage = 0 | 21:47 |
| lbragstad | let's say you want to use 10 cores in D | 21:48 |
| lbragstad | and the interface for oslo.limit from the service handing out cores is: | 21:48 |
| lbragstad | enforce(project_usage, project_id) | 21:49 |
| lbragstad | so, leaving oslo.limit to use the project ID get the hierarchy of limits from keystone and evaluate the usage to say "yes" or "no" | 21:49 |
| lbragstad | don't we have a circular dependency because oslo.limit still needs more usage information from the other children in the tree to make the decision? | 21:50 |
| *** felipemonteiro has quit IRC | 21:50 | |
| lbragstad | the current method signature doesn't allow oslo.limit to determine if (A.usage + B.usage + C.usage + D.usage) <= A.limit (which it finds by querying keystone for limit information) | 21:51 |
| lbragstad | to me, it seems like we have to problems... 1.) there is a certain level of ambiguity in the model and 2.) requiring services to pass in *all* resources and their owning projects to oslo.limit is going to be painful | 21:57 |
| *** d0ugal_ has quit IRC | 21:57 | |
| lbragstad | s/to problems/two problems/ | 21:58 |
| *** d0ugal_ has joined #openstack-keystone | 21:59 | |
| ayoung | lbragstad, yes, that is the problem with usage not being recorded in Keystone. That has always been the tough-to-solve problem | 22:04 |
| lbragstad | right | 22:04 |
| *** jmlowe has joined #openstack-keystone | 22:05 | |
| lbragstad | so - what about this | 22:05 |
| * lbragstad whips out the crazy idea notebook | 22:05 | |
| ayoung | I had thought about an idea of a resource pool | 22:05 |
| ayoung | so you have a unified identifier for the quota. Additional level of indirection | 22:05 |
| ayoung | parent project ID could be the resource pool id by default | 22:06 |
| lbragstad | what if all limit validation operations assumed the registered limit for all projects without an explicit override? | 22:06 |
| ayoung | not sure it is a solution | 22:06 |
| lbragstad | ayoung: the resource pool? | 22:06 |
| ayoung | I need to parse that | 22:06 |
| lbragstad | does the resource pool just push usage the leaves of the tree? | 22:06 |
| ayoung | yeah, resource pool requires the projects to keep track of what project is in what resource pool | 22:06 |
| ayoung | I think that was why I discarded it last time It came up...let me turn to your statement | 22:07 |
| lbragstad | ok | 22:07 |
| ayoung | So...I kindof think that all quotas should be explicit, and at the project level | 22:07 |
| ayoung | like, if I have 100 quota, and 10 proejcts, each get 10, or each get 5 and I keep 50 at the parent or something] | 22:08 |
| lbragstad | so - let's back up the example | 22:08 |
| lbragstad | A.limit is still 20 | 22:08 |
| ayoung | and then push back on the user to request/authorize push-down and automate reclaim | 22:08 |
| lbragstad | B and C are still children of A and are siblings | 22:08 |
| ayoung | resetting to your problems initial state? | 22:09 |
| lbragstad | yep | 22:09 |
| ayoung | q(A)=20 | 22:09 |
| ayoung | no children | 22:09 |
| ayoung | create proejct B child of A | 22:09 |
| ayoung | by default, 0 quota | 22:09 |
| lbragstad | if we assume A.limit to be divisible by the number of children in the tree, then it's clear that project D shouldn't be created, right? | 22:09 |
| ayoung | explicitly grab 5 quota from A, and now q(A)=15, q(B)=5 | 22:09 |
| ayoung | B quickly burns through quota. | 22:10 |
| lbragstad | well - by default, B and C get 10 each because of the registered limit | 22:10 |
| ayoung | A has a policy of "allow 5 floating" | 22:10 |
| ayoung | so, automated, Nova could say "requiest more quota for B" | 22:10 |
| ayoung | and Keystone would grab 1 (or whatever) from "Floating:" and now q(A)=14 q(B)=6 | 22:11 |
| ayoung | now once B deletes a VM, the question is how to rebalance | 22:12 |
| lbragstad | so - the interesting part is that the default limit established by the registered limit resource keeps the service from having to pass in all resources and owning projects when calculating usage | 22:12 |
| ayoung | OK...so if the default is each get 10, then the question is, would we want to split A, or force the new quota to come from outside A | 22:12 |
| ayoung | like...maybe A is just a polaceholder project, and should never have a VM | 22:13 |
| lbragstad | maybe | 22:13 |
| lbragstad | it depends | 22:13 |
| *** dklyle has joined #openstack-keystone | 22:13 | |
| lbragstad | but you'd have to go to A to update A.limit to 30 in order to create another child project under A | 22:13 |
| *** rcernin has joined #openstack-keystone | 22:13 | |
| ayoung | right | 22:13 |
| ayoung | OR, more likely, new projects get 0 quota, or the create-project call fails | 22:14 |
| ayoung | or some other reasonable failure mode | 22:14 |
| lbragstad | the outcome would be the same, in that case you'd have to supply explicit overrides | 22:14 |
| ayoung | If the goal is to say "give explicit quota to A, and then let that float among all of A's childre" it is one value system | 22:15 |
| ayoung | if the goal is "each proejct should have a strict quota" it is a different one | 22:15 |
| ayoung | strict quota is easier to enforce | 22:15 |
| ayoung | floating...I still suspect needs to use Keystone as a clearing house | 22:15 |
| lbragstad | the more i think about it - the more i think they should be separate models | 22:15 |
| ayoung | and...I suspect that clearing through Keystone is OK | 22:15 |
| ayoung | yes, they are def separate models | 22:15 |
| lbragstad | because they affect how the service passes usage information to oslo.limit | 22:16 |
| ayoung | if request/approve quota are easy and light weight, then explict quota makes sense | 22:16 |
| lbragstad | and ideally, that should be consistent regardless of the enforcement model configured in keystone | 22:16 |
| ayoung | the question quickly becomes one of churn | 22:17 |
| ayoung | Since Keystone can't call into Nova to free up Quota, nova has to trigger the free-action when the VM is deleted | 22:17 |
| lbragstad | well - it is possible for keystone to store a limit that is higher than a project's usage for a given resource | 22:18 |
| lbragstad | if H.limit is 15 and H.usage is 15, you can update H.limit to be 10 if you want | 22:19 |
| lbragstad | the usage enforcement check should prevent any more resources to be allocated to project H until usage is back under a limit of 10 | 22:20 |
| lbragstad | that can be done by an admin, or members of the project | 22:20 |
| ayoung | It was this veruy discussion that got the Cinder folks to withdraw "have keystone record quota" the first time around...I want to say that discussion happened in Portland | 22:21 |
| lbragstad | keystone is just storing the limit information though | 22:21 |
| lbragstad | we're still not tracking the actual usage information | 22:21 |
| lbragstad | if the usage exceeds the limit, that's fine and should be handled by the oslo.limit library during the usage calculation | 22:23 |
| lbragstad | at least until the usage is back under the limit threshold | 22:24 |
| ayoung | You hit my trigger word | 22:24 |
| ayoung | "just" | 22:24 |
| lbragstad | lol - it's *just* that easy ayoung | 22:24 |
| ayoung | So, I think that we need to make all quotas explicit | 22:24 |
| lbragstad | that makes the code easier to write i think | 22:25 |
| *** jmlowe has quit IRC | 22:37 | |
| *** jmlowe has joined #openstack-keystone | 22:53 | |
| *** felipemonteiro_ has quit IRC | 22:56 | |
| *** felipemonteiro has joined #openstack-keystone | 23:02 | |
| *** felipemonteiro_ has joined #openstack-keystone | 23:02 | |
| *** lbragstad has quit IRC | 23:05 | |
| *** felipemonteiro has quit IRC | 23:06 | |
| *** r-daneel has quit IRC | 23:09 | |
| *** d0ugal__ has joined #openstack-keystone | 23:11 | |
| *** jmlowe has quit IRC | 23:13 | |
| *** d0ugal_ has quit IRC | 23:14 | |
| *** spilla has quit IRC | 23:14 | |
| *** jmlowe has joined #openstack-keystone | 23:15 | |
| *** felipemonteiro__ has joined #openstack-keystone | 23:23 | |
| *** felipemonteiro_ has quit IRC | 23:23 | |
| kmalloc | ayoung: as in, no floating quotas (within children)? | 23:28 |
| *** d0ugal__ has quit IRC | 23:29 | |
| kmalloc | ayoung: remember, all nodes are strictly leaning on keystone for limits -- it is on the services to do "reserve" and "consume" and "free" for active quota usage -- we don't want to hold what is in use for every service. | 23:30 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!