allow explicit numa pinning in flavor extra specs or image metadata
There are cases where the host compute nodes may have software services or hardware that is associated with a specific NUMA node. For high-performance guests to make use of these services the software in the guest should run on virtual NUMA nodes that are explicitly mapped to the desired host NUMA nodes. In order to allow this, the proposal is to allow explicitly specifying this mapping via flavor extra specs of the form "hw:numa_node.X = Y", or image metadata of the form "hw_numa_node.X=Y" where X is the integer numa node in the guest, and Y is the integer numa node on the host.
As currently envisioned it wouldn't directly change the API, but it would add some exceptions to the list of expected exceptions to the self.compute_
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Chris Friesen
- Direction:
- Needs approval
- Assignee:
- Chris Friesen
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
- Unknown
- Milestone target:
- None
- Started by
- Completed by
- Chris Friesen
Related branches
Related bugs
Sprints
Whiteboard
Gerrit topic: https:/
Addressed by: https:/
Allow explicit numa pinning in flavor extra specs or image metadata
=======
Looking at the blueprint, it sounds very much like the nested resource providers, granular resource provider request and traits specs that the Nova team is currently working on:
• https:/
• https:/
• https:/
• https:/
I think those changes at least get us the capability to know, from an external service (e.g. a MANO system), which compute nodes in a nova deployment have NUMA nodes, what the capacity is on those NUMA nodes, and what, if any, special traits they have (qualitative traits of the hardware). Then we can couple flavor extra specs to those specific traits.
What those specs don’t provide, however, is a reservation system to make sure the compute node / NUMA resource is available when the external service actually makes the server create request. It sounds like that might be possible using Blazar, but I don’t know all of the details about that project.
We are currently in the final milestone upstream for the Queens development release, and entering the US Christmas holiday where a lot of people are going to be taking vacation over the final weeks of December. The next best opportunity to talk about this with the upstream community is going to be at the PTG in Dublin which is the week of February 26th.
In summary, I think the majority of what you need out of Nova is already agreed upon in those specs linked above, so that shouldn’t be a problem. The problem with those specs, like all things, is getting the development resources focused on getting those changes written, reviewed and tested so they can be merged upstream.
-- mriedem 20171213
=======