allow explicit numa pinning in flavor extra specs or image metadata

Registered by Chris Friesen

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_api.create() call in api/openstack/compute/plugins/v3/servers.py.

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
Completed by
Chris Friesen

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:bp/numa-node-pinning,n,z

Addressed by: https://review.openstack.org/169026
    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://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nested-resource-providers.html
https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/granular-resource-requests.html
https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/add-trait-support-in-allocation-candidates.html
https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/request-traits-in-nova.html

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
========================================================

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.