Open Stack

On 2018/12/20 下午10:47, Matt Riedemann wrote:
> 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).
>
Matt, thanks point this out.  (3)  is more clear and less configuration 
mess, so (3) winning, spec is gonna be revised.

Regards
Yongli He