Open Stack

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