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
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
I'm not sure the pagesize_kb, cores and threads. I guess Sean will have comment on them.
We can't get cores for threads for each numa node. The InstanceNUMACell.cpu_topology is empty only except for the dedicated cpu policy. And the Instance.cpu_topology is for the whole instance.
And we don't support choice page size per numa node.
Thanks for John and Sean's discussion in the PTG, and sorry for loss the conversation in PTG again. Actually, those are the questions Yongli is looking for.