| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-21 | |||
| 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 | jroll | oooo | |
| 18:50:36 | dansmith | jroll: also an old filter-based approach (google for filter_tenant_id) | |
| 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 | |
| 19:07:12 | dansmith | amodi: and is the tempest tenant mentioned in there? | |
| 19:07:50 | dansmith | amodi: I'd have to see what all you have and the logs, but you can see from the functional tests how it's supposed to work (and that it does) so it must be config-related | |
| 19:07:51 | mriedem | amodi: why do we need a tempest test for that placement request filter? we have in-tree functional testing which should be sufficient | |
| 19:08:10 | sean-k-mooney | dansmith: well cern were using the tenant isolation filter to window a set of host down to a cell based on the teant then runing the rest of the filters on that reduced set or somthing like that right. so when the went the cells v2 + placement they had some scaling issue where by if the use the placement limit feature they could get no valid host so you impmented this feature to give the same | |
| 19:08:12 | sean-k-mooney | fucntionaliy the previously had in a placement native way. at lest that is more or less my memory of events | |
| 19:08:31 | amodi | dansmith: yeah the filter_tenant_id= $tempest_generated_tenant_id | |
| 19:09:45 | dansmith | sean-k-mooney: because they look for a small number of placement results it was just not working, not really scale-related, although this does/should perform better yes | |
| 19:10:23 | dansmith | amodi: yep, well, should be working then, if the host(s) are in that aggregate.. see the functional test for details :) | |
| 19:10:38 | amodi | mriedem: well im checking functional tests | |
| 19:10:41 | amodi | dansmith: sure | |
| 19:10:41 | sean-k-mooney | dansmith: didnt the look at a small number of host because when they did not limit the got too much data back form placment and it was slowing down schduling | |
| 19:11:44 | dansmith | sean-k-mooney: okay, yes, they limit placement to a very small number for performance reasons. And then that affects the correctness of the multi-tenant filter. | |
| 19:11:51 | sean-k-mooney | basically the "this tiny vm fits on all host so return all host proablem" | |
| 19:12:01 | sean-k-mooney | ya | |
| 19:12:16 | dansmith | I'm *so* glad we hashed that out. | |