| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-05 | |||
| 09:13:58 | jangutter | it's also unlikely to happen in the short term. | |
| 09:28:23 | johnthetubaguy | bauzas: just checking, partly for pvc, but I didn't think we had any code in place to integrate cyborg in master (yet)? Apart from maybe PCI pass-through? | |
| 09:31:21 | bauzas | johnthetubaguy: AFAIK, cyborg directly modifies nova.conf for using PCI passthru, yes | |
| 09:31:37 | johnthetubaguy | ah, got it, thanks | |
| 09:31:38 | bauzas | johnthetubaguy: there was a YVC session | |
| 09:32:15 | johnthetubaguy | yeah, I was more checking there wasn't post PTG progress I didn't know about while I was out of it | |
| 10:14:19 | openstackgerrit | Silvan Kaiser proposed openstack/nova master: [WIP] Added Qemu libquobyte Support to the Quobyte Driver https://review.openstack.org/546500 | |
| 10:41:51 | lpetrut | Hi, is it acceptable for exceptions to include another exception as message? Asking as exception_to_dict won't handle it properly: https://github.com/openstack/nova/blob/5859741f4d5e08ec15169b9c8d1aae1836442fd2/nova/compute/utils.py#L58-L87 | |
| 11:01:42 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Use links to placement docs in nova docs https://review.openstack.org/614056 | |
| 11:02:22 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove Placement API reference https://review.openstack.org/614437 | |
| 11:06:02 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix best_match() deprecation warning https://review.openstack.org/611204 | |
| 11:36:59 | sean-k-mooney | bauzas: can you reivew https://review.openstack.org/#/c/610034/ | |
| 11:41:23 | adrianc | sean-k-mooney: Hi, i would like to co-author the following commits as i am now working towards aligning the POC code for libvirt sriov live migration: https://review.openstack.org/#/c/607365/ https://review.openstack.org/#/c/607365/ | |
| 11:44:30 | sean-k-mooney | adrianc: hi yes that is fine feel free too. i have been held up with other work for the last 2 weeks so have not made much progress on this since then | |
| 11:44:56 | sean-k-mooney | im currently adressing stephens feedback on the spec but i should get that done today | |
| 11:45:12 | adrianc | great, thanks sean-k-mooney | |
| 12:29:08 | openstackgerrit | Lucian Petrut proposed openstack/nova master: Convert exception messages to strings https://review.openstack.org/615550 | |
| 12:54:24 | aarents | Hi there, can someone may evaluate this issue: https://bugs.launchpad.net/nova/+bug/1801702 | |
| 12:54:24 | openstack | Launchpad bug 1801702 in OpenStack Compute (nova) "Spawn may fail when cache=none on block device with logical block size > 512" [Undecided,New] | |
| 13:03:36 | bauzas | sean-k-mooney: ack, will look | |
| 13:06:46 | Sundar | cdent: Please LMK when you have some time, regarding https://review.openstack.org/#/c/603955/ | |
| 13:07:50 | cdent | Sundar: I'm unlikely to have much time to talk synchronously, a lot going on, but if you leave questions and comments on the review I will respond as soon as I can | |
| 13:08:11 | cdent | but if it is something quick? | |
| 13:08:51 | Sundar | cdent: OK. I was hoping to get and provide clarification on the general comment: "In general it seems like the resources and representations thereof are too closely tied to the specific needs of the API" | |
| 13:09:11 | Sundar | I will respond in the review itself, as best as I can | |
| 13:09:13 | Sundar | Thanks | |
| 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 | |