Hi, My main worry was to not expose host related information to end users, but noting administrators probably do what the information. Looking again at the Stein spec we merged, the proposed policy rules already take care of all that. I think the next step is to re-propose the spec for the Train release. I couldn't find it, but maybe you have done that already? Thanks, johnthetubaguy On Fri, 10 May 2019 at 08:51, yonglihe <yongli.he@intel.com> wrote:
Hi, Everyone
I synced up with Alex about comments we got at PTG. It's a long discussion, I might lost something.
What i got lists below, fix me:
* Remove sockets * Remove thread_policy
Not sure about following comments:
* Remove the cpu topology from the proposal? * Using the cpu pinning info instead of cpu set?
By apply the suggestion, the API ``GET /servers/{server_id}/topology`` response gonna to be like this,
and let us align what it should be:
{ # overall policy: TOPOLOGY % 'index "nodes":[ { # Host Numa Node # control by policy TOPOLOGY % 'index:host_info' "host_numa_node": 3, # 0:5 means vcpu 0 pinning to pcpu 5 # control by policy TOPOLOGY % 'index:host_info' "cpu_pinning": {0:5, 1:6}, "vcpu_set": [0,1,2,3], "siblings": [[0,1],[2,3]], "memory_mb": 1024, "pagesize_kb": 4096, "cores": 2, # one core has at least one thread "threads": 2 } ... ], # nodes }
links:
ptg: https://etherpad.openstack.org/p/nova-ptg-train L334
spec review:
https://review.opendev.org/#/c/612256/25/specs/stein/approved/show-server-nu...
code review: https://review.openstack.org/#/c/621476/
bp: https://blueprints.launchpad.net/nova/+spec/show-server-numa-topology
Regards Yongli He