On 12/18/2018 2:20 AM, yonglihe wrote:
Base on IRC's discuss, we may have 3 options about how to deal with those blobs:
1) include those directly in the server response details, like the released POC does: https://review.openstack.org/#/c/621476/3
I would think these are potentially admin-level sensitive details as well and thus only exposed based on a policy check. A user requests a certain topology, but I'm not sure how low-level the user needs/should see what nova is doing for satisfying that topology, especially for things like pinning CPUs on the host. I thought the main use case for this spec (and several like these discussed at the PTG) was more about being able to get information (reporting) out of the REST API for debugging (by admins and/or support team members), less about user need.
2) add a new sub-resource endpoint to servers, most likely use key word 'topology' then: "GET /servers/{server_id}/topology" returns the NUMA information for one server.
Similar to (1) in that I'd think there would be a new policy check on this which defaults to admin-only. I think this would be better than (1) since it wouldnt' be confused with listing servers (GET /servers/detail).
3) put the NUMA info under existing 'diagnostics' API. "GET /servers/{server_id}/diagnostics" this is admin only API, normal user loss the possible to check their topology.
By default it's an admin-only API, but that is configurable in policy, so if a given cloud wants to expose this for admin or owner of the instance, they can do that, or alternatively expose it to support team members via a special role in keystone.
when the information put into diagnostics, they will be look like: { .... "numa_topology": { cells [ { "numa_node" : 3 "cpu_pinning": {0:5, 1:6}, "cpu_thread_policy": "prefer", "cpuset": [0,1,2,3], "siblings": [[0,1],[2,3]], "mem": 1024, "pagesize": 4096, "sockets": 0, "cores": 2, "threads": 2, }, ... ] # cells } "emulator_threads_policy": "share"
"pci_devices": [ { "address":"00:1a.0", "type": "VF", "vendor": "8086", "product": "1526" }, ] }
I tend to prefer option (3) since it seems topology is a much more natural fit with the existing information (low-level CPU/RAM/disk usage) we expose out of the diagnostics API and is already restricted to admins by default in policy (but again as noted this can be configured). -- Thanks, Matt