| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-05 | |||
| 13:09:16 | cdent | thank you | |
| 13:28:03 | bauzas | sean-k-mooney: +2d with a few nits | |
| 13:28:24 | sean-k-mooney | bauzas: thanks ill check them out | |
| 13:46:00 | tssurya | melwitt: is there any reason on why we calculate the quota for instances/ram/cores per user per project ? (https://review.openstack.org/#/c/569055/2/nova/quota.py@1342), like do we practically use the counts for per user over projects anywhere ? | |
| 13:47:07 | sean-k-mooney | tssurya: i belive we used to use the per user qoats in the past i assuemd we still do | |
| 13:47:44 | tssurya | sean-k-mooney: we now do per project quotas right ? I am gessing only for keypairs we do per user ? | |
| 13:48:00 | sean-k-mooney | tssurya: i was under the impression we had both | |
| 13:48:07 | tssurya | ah okay | |
| 13:48:15 | tssurya | let me check the documentation | |
| 13:48:29 | sean-k-mooney | tssurya: personally i would consider it a fairly big regression if we drop the user quotas | |
| 13:49:08 | sean-k-mooney | it was not that uncommon for people to deploy one project per department/team in private cloude and then have a user level quota too | |
| 13:49:45 | tssurya | sean-k-mooney: hmm correct looks like we have user quotas also heh, | |
| 13:50:12 | sean-k-mooney | so the test team project can have 100 instances but each tester can only have 10 personally | |
| 13:50:20 | tssurya | okay sounds fair enough that restricting resources on users also is valid | |
| 13:50:45 | sean-k-mooney | i dont know what the plans for this were with unified limits however | |
| 13:50:59 | sean-k-mooney | best to ask melwitt et al for comment | |
| 13:51:15 | tssurya | thanks sean-k-mooney , yea I don't know about tha unified limits stuff althought there is a spec worked upon by John | |
| 13:52:16 | johnthetubaguy | tssurya: currently the operator can specify per user limits, there are no plans to support this post unified limits | |
| 13:52:49 | johnthetubaguy | well basically, the plan is hierarchical limits replace that feature | |
| 13:52:51 | sean-k-mooney | johnthetubaguy: really | |
| 13:52:58 | tssurya | johnthetubaguy: ah thanks, so we are going to drop user quotas altogether ? | |
| 13:53:03 | leakypipes | johnthetubaguy: I'm getting close... | |
| 13:53:13 | johnthetubaguy | tssurya: that is what I propose in the spec and my patches, yeah | |
| 13:53:14 | leakypipes | johnthetubaguy: sigh, these quota unit test are ugly-as-f... | |
| 13:53:26 | sean-k-mooney | johnthetubaguy: so each user would have there own project in that case as a subproject of there teams project | |
| 13:53:30 | johnthetubaguy | leakypipes: not been in them yet! | |
| 13:53:32 | tssurya | johnthetubaguy: thanks I will go read the spec | |
| 13:53:51 | jaypipes | johnthetubaguy: bring a decanter of scotch. | |
| 13:53:54 | jaypipes | you'll need it. | |
| 13:54:05 | jaypipes | hopefully I'll have the worst of them cleaned up shortly. | |
| 13:54:22 | jaypipes | 9 failures left to fix (after converting them from test.TestCase to test.NoDBTestCase) | |
| 13:54:31 | johnthetubaguy | OK, nice | |
| 13:58:06 | sean-k-mooney | jaypipes: johnthetubaguy so has there been any push back on the fact that users with acess to multiple project will nolong have a global limit on the resouce that user can use | |
| 13:59:15 | sean-k-mooney | i know you can kindo of model that with per user project nested under a larger project but with only 2 levels of nesting that is not as flexible as what could be done before | |
| 13:59:39 | johnthetubaguy | sean-k-mooney: so I should be more precise, it was per user within a project, if my memory is correct | |
| 14:00:42 | jaypipes | sean-k-mooney: no, no pushback. | |
| 14:00:43 | johnthetubaguy | sean-k-mooney: the only users we know about, prefer and want to move to two level project quotas (they used the user thing as a workaround) | |
| 14:00:55 | sean-k-mooney | johnthetubaguy: wait could you have a per user qoat that was different form the users global quota for a specific porject before | |
| 14:00:57 | jaypipes | sean-k-mooney: what johnthetubaguy said. | |
| 14:00:57 | johnthetubaguy | yeah, the opposite, we have support for this direction | |
| 14:01:25 | jaypipes | sean-k-mooney: what's a "qoat"? Quota Of All Time? :) | |
| 14:01:33 | johnthetubaguy | sean-k-mooney: there was no global user quota, it was per user within a specific project. Maybe I answered tssurya's question badly | |
| 14:02:15 | sean-k-mooney | oh then i totally missunder stood how that option worked and always gave my team memebr more instance then i planned lol | |
| 14:03:01 | tssurya | johnthetubaguy: no I think you answered my question correctly. we currently support per user quota within projects, after unified limits we won't right ? | |
| 14:03:12 | johnthetubaguy | tssurya: yeah, that's right | |
| 14:03:31 | sean-k-mooney | i assumed the user quota applied across all project so when i gave them acess to a second project outside there main one i used the user quotat to limit there use of th unlimited project | |
| 14:03:54 | tssurya | yea so I guess sean-k-mooney was worried of this to be a big bad regression ? | |
| 14:04:00 | johnthetubaguy | tssurya: the folks who used that also modified policy so you couldn't delete someone elses instance, so its all a bit strange around those parts | |
| 14:04:33 | tssurya | johnthetubaguy: oh yea that is strange if its all in the same project | |
| 14:04:45 | sean-k-mooney | tssurya: from what johnthetubaguy and jaypipes explained there is no regression that i can see so all good | |
| 14:04:45 | johnthetubaguy | sean-k-mooney: yeah, I thought that too till I reviewed melwitt's patches, turns out it doesn't do that | |
| 14:05:58 | sean-k-mooney | johnthetubaguy: well it was a private developer cloud so no harm in my case but ya | |
| 14:06:43 | sean-k-mooney | having to adjust both the project and user limits was always a bit of a pain so it soundls like its an improvment overall | |
| 14:06:54 | johnthetubaguy | cool | |
| 14:06:58 | tssurya | sean-k-mooney: okay :) | |
| 14:44:27 | efried | tssurya: I saw Belmiro respond on the ML; does this mean y'all have tried the patch in your env somewhere? | |
| 14:45:14 | tssurya | efried: well no all we do it increase the config's value to a very high number, ever since we added the config in queens | |
| 14:45:26 | tssurya | so if you allow setting the config to "0" | |
| 14:45:35 | tssurya | that will disable it its good for us | |
| 14:45:40 | efried | tssurya: The patch actually goes quite a bit further than that. | |
| 14:46:07 | efried | I believe with the refresh interval very high, you're still getting the inventory polls. | |
| 14:46:14 | efried | Now you won't even get those anymore. | |
| 14:46:41 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Add Unified Limits Spec https://review.openstack.org/602201 | |
| 14:46:45 | efried | ...I think. | |
| 14:47:32 | tssurya | efried: oh just read the commit (message) | |
| 14:47:55 | tssurya | yea we don't currently have any of those yet downstream (meaning our code is the same as upstream at the tracker level) | |
| 14:48:15 | tssurya | but it would be cool to optimize the calls to placement to the maximum | |
| 14:49:01 | sean-k-mooney | efried: by the way if you have time can you review https://review.openstack.org/#/c/610034/ | |
| 14:49:07 | tssurya | because in rocky you have more stuff than in queens right ? the way the updates are done with pulling the prodiver tree info and everything (meaing the new update_to_placement function)? | |
| 14:49:35 | efried | tssurya: What I think we'll be really looking for in order to have enough confidence to merge this is for deployments such as yours and mnaser's to put this in place and verify, not so much that the number of placement calls drops off a cliff - that should be a given - but that we don't wind up with the RT getting out of sync with placement's view. | |
| 14:49:43 | efried | tssurya: I don't believe there's much more in rocky than queens, no. | |
| 14:50:11 | tssurya | we are also investigating on our end | |
| 14:50:28 | tssurya | I can see if we can test this patch in our deployment | |
| 14:50:37 | tssurya | and give feedback | |
| 14:51:11 | efried | One thing about mnaser's comments, which I will also mention in a response on the thread, is that this should not affect *allocations* at all. IIUC, it was allocations getting out of sync that mnaser observed. I will be interested to know if he or you have ever observed anything else (inventories, etc.) getting out of sync. | |
| 14:51:29 | efried | Especially you, since you've been running the long-poll in production for a while, right? | |
| 14:51:52 | tssurya | efried: well the long poll used to only switch off traits and aggregates | |
| 14:52:21 | efried | tssurya: It would also affect inventory updates. | |
| 14:52:26 | efried | oh | |
| 14:52:41 | efried | yeah, I see what you're saying now. I think you're right. | |
| 14:52:50 | efried | and we're not doing much with those in q/r. | |
| 14:53:00 | tssurya | yea I am pretty sure it was only the traits and aggregates syn that was off | |
| 14:53:09 | tssurya | the inventory sync was like normal for us | |
| 14:53:28 | efried | the poll you're stretching would also update inventories, but there was an additional, separate inventory update that was happening outside of that one, so yeah. | |
| 14:53:45 | tssurya | ah yea that makes sense | |
| 14:54:00 | tssurya | because we didn't have that much out of syn inventory issues | |
| 14:54:04 | tssurya | sync* | |
| 14:55:16 | efried | tssurya: The theory behind the patch is that you shouldn't have those issues anyway, even if we *never* poll. | |
| 14:55:20 | efried | but | |
| 14:55:30 | efried | I'm not sure I hit the code paths that do that separate inventory update | |
| 14:55:32 | efried | sad face | |
| 14:55:53 | jaypipes | three more unit test failures to address... closing in... | |
| 14:55:56 | tssurya | haha, I am trying to go through your commit now... but | |
| 14:56:08 | tssurya | so idea is a inventory refresh only if something changes right ? | |
| 14:57:08 | efried | tssurya: well, at least in this code path, yes. Basically, if you set the refresh interval to zero, the only time you would get a refresh is if e.g. the virt driver pushes a change via update_provider_tree. | |
| 14:57:31 | efried | jaypipes: IYO, should there be a bp and/or spec for this? And should it be multiple patches? | |
| 14:58:06 | jaypipes | efried: the cache change stuff? | |
| 14:58:09 | efried | y | |
| 14:58:44 | jaypipes | efried: I think it would be useful to have a bp for tracking purposes, sure. spec, not so much. | |
| 14:58:56 | efried | ight, we'll start there. | |