| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-21 | |||
| 17:16:19 | cdent | mriedem: thanks queued | |
| 17:16:40 | kashyap | I definitely think it is backport-worthy. See mdbooth's comment earlier | |
| 17:17:19 | sean-k-mooney | kashyap: in which case it can be proposed for backport to stable/stien and the other stable branches | |
| 17:17:30 | sean-k-mooney | so its not really that much of an issue | |
| 17:17:30 | kashyap | mriedem_grooming: I don't agree with your emphatic "no". But whatever. I have 1000 other things that need my attention | |
| 17:17:52 | kashyap | sean-k-mooney: Yep, so it's fine, if it's merged tomm. | |
| 17:18:19 | sean-k-mooney | mdbooth: do you consider qemu vert type to be a bug | |
| 17:18:21 | kashyap | sean-k-mooney: But, I'd prefer it to be in Stein. I didn't "plan" this work. | |
| 17:18:45 | sean-k-mooney | mdbooth: you can say yes :) | |
| 17:18:48 | mdbooth | kashyap: I don't think it's worthy of Stein at this stage. | |
| 17:18:55 | kashyap | mdbooth: Okido... | |
| 17:18:56 | mdbooth | kashyap: Focus on the backport. | |
| 17:19:05 | kashyap | I don't know; I'll focus on dinner first | |
| 17:19:11 | mdbooth | kashyap: Good call :) | |
| 17:19:47 | kashyap | sean-k-mooney: mdbooth: But as noted, The two volume drivers patches should _also_ merge at the same time | |
| 17:19:54 | kashyap | For the "minimum possible doc" to make sense. | |
| 17:24:25 | mriedem_grooming | listen guys, i didn't say it wasn't a bug, i sait it wasn't a regression in stein, it's latent, therefore it doesn't need to be held up for rc1 which is already stressful | |
| 17:24:30 | mriedem_grooming | so we'll deal with backports | |
| 17:24:48 | mriedem_grooming | if people don't like my input on it then don't ask | |
| 17:25:45 | kashyap | mriedem_grooming: Hey, I do like your input very much :-) | |
| 17:26:14 | efried | I was content at :14:52 | |
| 17:26:17 | kashyap | mriedem_grooming: But yep, please go ahead with RC1 stuff (after your grooming) | |
| 17:27:08 | sean-k-mooney | efried: what change ad 14:53 | |
| 17:27:13 | sean-k-mooney | * at | |
| 17:27:52 | kashyap | sean-k-mooney: If I have to guess it's the "not an RC1 candidate" remark :-) | |
| 17:27:57 | efried | :14:52, as in 14 mins 52s after whatever hour you're in (Unless you're in one of those bizarre time zones that's off by a half hour) | |
| 17:28:08 | efried | when I said "k, swhat I figured". | |
| 17:28:36 | sean-k-mooney | oh ha i see | |
| 17:29:01 | efried | which was shorthand for, "I was pretty sure this wasn't a candidate for rc1, but I wasn't positive, so I asked mriedem. He voiced a similar opinion. So that is what we shall go with." | |
| 17:29:35 | bauzas | honestly, not a big deal (again) | |
| 17:29:59 | bauzas | we always cut RC1 after things we wanna wait | |
| 17:30:21 | bauzas | the question is : should the bug we discuss be in the waitlist ? obviously not in my mind, period | |
| 17:30:39 | sean-k-mooney | efried: by the way have you looked at the nova ptg etherpad to see what should be moved to placemetn or nova placement cross project stuff | |
| 17:30:57 | efried | sean-k-mooney: Yes, I did that yesterday, but it will need constant mriedem_groominging | |
| 17:31:30 | efried | could have been Tuesday | |
| 17:31:49 | efried | no, yesterday: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004030.html | |
| 17:32:07 | sean-k-mooney | efried: i originally adde the resource provider yaml but topic but is that something that anyone is going to pursue in train? | |
| 17:32:33 | efried | sean-k-mooney: IMO that's a straight-up Nova topic, as it doesn't ask for any changes to the placement API. | |
| 17:32:52 | sean-k-mooney | oh sorry yes it is | |
| 17:32:55 | efried | I haven't felt a whole lot of excitement behind that effort, so I haven't been pushing it. | |
| 17:33:03 | efried | but if you're excited, I'll get excited with you. | |
| 17:33:11 | efried | since I proposed the thing | |
| 17:33:13 | sean-k-mooney | i partly context switch and was wondering if there was still a desire to discuss it | |
| 17:34:10 | sean-k-mooney | well i think there is a pain point there but im not sure if that is the solution | |
| 17:34:40 | efried | Had this revelation recently when talking about https://etherpad.openstack.org/p/placement-inter-provider-affinity -- would rather do small, simple, easy-to-understand things that have limited scope and power than try to do a super generic one-size-fits-all thing. | |
| 17:34:50 | efried | and that yaml spec leans much more toward the latter. | |
| 17:35:43 | sean-k-mooney | ok. im going to grab lunch too. | |
| 17:37:06 | bauzas | oh man, I'm getting mad at devstack deployments | |
| 17:37:25 | sean-k-mooney | bauzas: something specificlly? | |
| 17:39:04 | bauzas | neutron fails to install | |
| 17:39:10 | bauzas | but meh, I'll fix it | |
| 17:39:17 | sean-k-mooney | ah ok | |
| 17:40:38 | bauzas | yeah, it's a reqs thing | |
| 17:41:43 | bauzas | let's go for a RECLONE=yes | |
| 17:45:01 | NobodyCam | fyi incase anyone ever runs in to this again: issue was bad rabbit ip in nova_api/cell_mappings.transport_url | |
| 17:52:18 | dansmith | efried: cdent: what's the status on this eventlet monkeypatch thing? I saw some discussion this morning, but when I looked the other day it had changed since my review for reasons I wasn't sure about | |
| 17:52:37 | efried | dansmith: tldr we think it's good, but wait for after rc1 | |
| 17:53:03 | dansmith | efried: ah right, because they said it was okay in train, cool | |
| 17:53:04 | efried | dansmith: was gonna bug you tomorrow (after rc1 cut) to re-up your +2 | |
| 17:53:18 | efried | well, they want it backported. We just don't want to drop it into rc1 | |
| 17:53:27 | dansmith | right | |
| 17:59:19 | melwitt | mriedem_grooming, efried: thanks for getting the cycle highlights updated | |
| 17:59:34 | efried | yw | |
| 18:09:38 | efried | our last rc1 patch just hit the 2h mark unstarted in the check queue :( | |
| 18:29:04 | openstackgerrit | Merged openstack/nova master: Move libvirt calculation of machine type to utils.py https://review.openstack.org/644554 | |
| 18:41:40 | openstackgerrit | melanie witt proposed openstack/nova master: Move creation of rpcapi.ComputeAPI object from __init__ https://review.openstack.org/644998 | |
| 18:44:16 | openstackgerrit | melanie witt proposed openstack/nova master: Move create of ComputeAPI object in websocketproxy https://review.openstack.org/644998 | |
| 18:45:36 | jroll | afaik there is no way to limit the project(s) which can boot an instance on a given set of compute nodes, right? surely someone has proposed this before, is it a hard no? | |
| 18:49:11 | dansmith | tenant isolation yo! | |
| 18:50:20 | dansmith | jroll: new placementy way to do it: https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/placement-req-filter.html | |
| 18:50:36 | dansmith | jroll: also an old filter-based approach (google for filter_tenant_id) | |
| 18:50:36 | jroll | oooo | |
| 18:51:53 | jroll | dansmith: this should work perfectly, thanks! | |
| 18:52:13 | dansmith | finally, FINALLY, I do something to make jroll happy. | |
| 18:52:20 | jroll | it only took 5 years | |
| 18:52:32 | dansmith | better late than never | |
| 18:53:32 | sean-k-mooney | the tenant isolation filter has some edgecases | |
| 18:54:24 | sean-k-mooney | the main one being it limits the set of host a project can boot instnace on but does not prevent other project form booting instnaces on those same host | |
| 18:54:50 | dansmith | sean-k-mooney: you should read that spec | |
| 18:55:21 | dansmith | there's a provision (unlike the filter approach) that will reject if the tenant is not confined, so you can avoid that situation | |
| 18:56:05 | mriedem | melwitt: did you want to re-propose the counting quotas spec so we can line that up for landing early in train? | |
| 18:56:09 | sean-k-mooney | oh cool. well it was not really a edgecase in the old filter i guess as a desing choice | |
| 18:56:13 | mriedem | the code i mean, after the spec is re-approved | |
| 18:56:26 | sean-k-mooney | dansmith: nice to know the placement version accounts fot that | |
| 18:56:38 | melwitt | mriedem: oh, yes, I do. thanks for reminding me | |
| 18:57:08 | melwitt | let me do it now so I don't forget a third time | |
| 18:58:54 | jroll | dansmith: the use case mentions segregate users into cells, but it sounds like the solution only depends on aggregates, not cells, am I reading that right? | |
| 18:59:58 | mriedem | the scheduler does might be more clear than the spec https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#tenant-isolation-with-placement | |
| 19:00:01 | mriedem | *docs | |
| 19:00:32 | jroll | mriedem: thanks, that answers it | |
| 19:00:39 | dansmith | jroll: correct | |
| 19:01:40 | sean-k-mooney | jroll: the original usecase was a cellv1 -> cellv2 perfromcne regration which is why the spec focused on cells but ya it just needs aggreates | |
| 19:01:54 | jroll | sean-k-mooney: right, figured as much | |
| 19:01:57 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Re-propose count quota usage from placement https://review.openstack.org/645302 | |
| 19:03:12 | amodi | dansmith: mriedem additional question related to this: im currently developing a test case on this, im getting a Scheduling error, No Hosts found. Is tempest generated project/tenant not able to execute this? cz i can run the same from admin project and it works | |
| 19:03:52 | amodi | sorry this error: "No valid host was found. Scheduling failed: No hosts available for tenant" | |
| 19:04:51 | dansmith | amodi: if the tenant is not allowed to any aggregate and the "require" flag is set, then that's expected yes | |
| 19:05:42 | dansmith | sean-k-mooney: not really performance regression, but replicating the inate behavior/feature of being able to schedule to specific cells, yes | |
| 19:05:52 | amodi | yes thats set placement_aggregate_required_for_tenants=True | |
| 19:06:47 | amodi | dansmith: i do set the filter_tenant_id metadata to the aggregate | |