Description of problem: Currently, hosts are not filtered based on used VCPU's on the system (upstream was proposed and abandoned at https://review.openstack.org/#/c/379525/ ) And systems can get over subscription Version-Release number of selected component (if applicable): How reproducible: Initial status: compute-0: host (source) migrating instances (4 instances, 2 vCPU each) compute-1: 2 free vCPUs compute-2: 2 free vCPUs compute-3: 4 free vCPUs Results: - 1 VM (2 vCPU) to compute-1 (could hold 1 vm, got 0) ← OK: should got 1 VM's got 1 - 0 VM to compute-2 (could hold 1 vm, got 1) ← WRONG should got 1 VM's not 0 - 3 VM (6 vCPU) to compute-3 (could hold 2 vm, got 3) ← WRONG should got 2 VM's not 3 Actual results: Hosts get oversubscribed Expected results: No oversubscription of VCPU's Additional info:
https://review.openstack.org/#/c/379525/ was abandoned. Reason (from Launchpad - sfinucan): The real concern I see with that change is that we're working on using the placement API for providing the best destinations related to the existing resources (CPU, memory, disk). While it's fine to merge that one, it would mean that it's not waiting for the scheduler using the placement API, which could be a bit sad. The real issue is that it's really easy to add a custom weighter out-of-tree without needing to add it in the Nova tree, so that's not really needed, see? I did this fairly quickly while working on the PCI-NUMA filter here. The reason for doing this is that it seemed like a filter that had a clear use case and one I really expected to see there already. If you don't think it's as useful as I think it is, then I'm fine to abandon this :)
Following the abandon of upstream bug (see comment #3), Can engineering provide more info about how to achieve a better match of placement destinations in OSP 10?
Apologies for the delay - I have been on PTO. I have discussed this upstream and it seems this is something that will *not* be covered by placement. As such, I have reopened the review. However, this kind of feature requires a blueprint and the deadline for this during the current cycle closed some time ago. We do not carry features that are not available upstream, so this is something that would not be available until OSP 14 at the earliest. In addition, we do not tend to backport features (compared to bugfixes), though this might (might) qualify as an exception. I will ask.
Hi Stefan, Any update? Aviv
@Aviv. Unfortunately this is considered a feature so it would require an approved blueprint to continue work on it. The window for this during the Queens cycle (what will become OSP 17) has already closed, so this will be delayed until Rocky (OSP 18). Fortunately this is something that would be easily backported, at least from a code perspective, and once merged upstream we could assess the viability of doing so. I'll also note that weighers and filters are an area that the nova team explicitly allow custom code to run. It's possible that the customer could use the upstream filter in their own code. I don't know if this is supported from a Red Hat perspective though, so you'll need to ask around for info on this.
Hi Stephen, I think you missed the OSP release numbers, Queens will be OSP 13, Rocky 14. Using upstream code by the customer is optional, but unsupported. We're urging them not to do that and we'll try to avoid it asap. Is a one-of backport for OSP 10 is feasible somehow? Aviv
Oops - I was using the upstream nova release numbers. A one-off backport might be possible and is something I need to discuss. However, just to set expectations for there to be a backport, there must first be a feature to backport. As noted above, this can't happen until OSP 14.
Hi Stephen, Can you suggest (if any) a workaround for OSP 10? Aviv
I think the weigher is the only practical approach, unfortunately. Given that the Rocky window is open upstream, I will see if we get this approved for the upcoming release.
*** Bug 1246461 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:0045