Open Stack

On 04/18/2018 11:58 AM, Matt Riedemann wrote:
> On 4/18/2018 9:06 AM, Jay Pipes wrote:
>> "By default, should resources/traits submitted in different numbered 
>> request groups be supplied by separate resource providers?"
> 
> Without knowing all of the hairy use cases, I'm trying to channel my 
> inner sdague and some of the similar types of discussions we've had to 
> changes in the compute API, and a lot of the time we've agreed that we 
> shouldn't assume a default in certain cases.
> 
> So for this case, if I'm requesting numbered request groups, why doesn't 
> the API just require that I pass a query parameter telling it how I'd 
> like those requests to be handled, either via affinity or anti-affinity
So, you're thinking maybe something like this?

1) Get me two dedicated CPUs. One of those dedicated CPUs must have AVX2 
capabilities. They must be on different child providers (different NUMA 
cells that are providing those dedicated CPUs).

GET /allocation_candidates?

  resources1=PCPU:1&required1=HW_CPU_X86_AVX2
&resources2=PCPU:1
&proximity=isolate:1,2

2) Get me four dedicated CPUs. Two of those dedicated CPUs must have 
AVX2 capabilities. Two of the dedicated CPUs must have the SSE 4.2 
capability. They may come from the same provider (NUMA cell) or 
different providers.

GET /allocation_candidates?

  resources1=PCPU:2&required1=HW_CPU_X86_AVX2
&resources2=PCPU:2&required2=HW_CPU_X86_SSE42
&proximity=any:1,2

3) Get me 2 dedicated CPUs and 2 SR-IOV VFs. The VFs must be provided by 
separate physical function providers which have different traits marking 
separate physical networks. The dedicated CPUs must come from the same 
provider tree in which the physical function providers reside.

GET /allocation_candidates?

  resources1=PCPU:2
&resources2=SRIOV_NET_VF:1&required2=CUSTOM_PHYSNET_A
&resources3=SRIOV_NET_VF:1&required3=CUSTOM_PHYSNET_B
&proximity=isolate:2,3
&proximity=same_tree:1,2,3

3) Get me 2 dedicated CPUs and 2 SR-IOV VFs. The VFs must be provided by 
separate physical function providers which have different traits marking 
separate physical networks. The dedicated CPUs must come from the same 
provider *subtree* in which the second group of VF resources are sourced.

GET /allocation_candidates?

  resources1=PCPU:2
&resources2=SRIOV_NET_VF:1&required2=CUSTOM_PHYSNET_A
&resources3=SRIOV_NET_VF:1&required3=CUSTOM_PHYSNET_B
&proximity=isolate:2,3
&proximity=same_subtree:1,3

4) Get me 4 SR-IOV VFs. 2 VFs should be sourced from a provider that is 
decorated with the CUSTOM_PHYSNET_A trait. 2 VFs should be sourced from 
a provider that is decorated with the CUSTOM_PHYSNET_B trait. For HA 
purposes, none of the VFs should be sourced from the same provider. 
However, the VFs for each physical network should be within the same 
subtree (NUMA cell) as each other.

GET /allocation_candidates?

  resources1=SRIOV_NET_VF:1&required1=CUSTOM_PHYSNET_A
&resources2=SRIOV_NET_VF:1&required2=CUSTOM_PHYSNET_A
&resources3=SRIOV_NET_VF:1&required3=CUSTOM_PHYSNET_B
&resources4=SRIOV_NET_VF:1&required4=CUSTOM_PHYSNET_B
&proximity=isolate:1,2,3,4
&proximity=same_subtree:1,2
&proximity=same_subtree:3,4

We can go even deeper if you'd like, since NFV means "never-ending 
feature velocity". Just let me know.

-jay