Open Stack

Sundar-

> Yes. The examples in the storyboard [1] for NUMA affinity use group
> numbers. If that were recast to use named groups, and we wanted NUMA
> affinity apart from device colocation, would that not require a
> different name than T? In short, if you want to express 2 different
> affinities/groupings, perhaps we need to use a name with 2 parts, and
> use 2 different same_subtree clauses. Just pointing out the implications.

That's correct. If we wanted two groupings...

[repeating diagram for context]

CN
|
+---NIC1 (trait: I_AM_A_NIC)
|     |
|     +-----PF1_1 (trait: CUSTOM_PHYSNET1, inventory: VF=4)
|     |
|     +-----PF1_2 (trait: CUSTOM_PHYSNET2, inventory: VF=4)
|
+---NIC2 (trait: I_AM_A_NIC)
       |
       +-----PF2_1 (trait: CUSTOM_PHYSNET1, inventory: VF=4)
       |
       +-----PF2_2 (trait: CUSTOM_PHYSNET2, inventory: VF=4)

  ?resources_TA1=VF:1&required_TA1=CUSTOM_PHYSNET1
  &resources_TA2=VF:1&required_TA2=CUSTOM_PHYSNET2
  &required_TA3=I_AM_A_NIC
  &same_subtree=','.join([
     suffix for suffix in suffixes if suffix.startswith('_TA')])
     # (i.e. '_TA1,_TA2,_TA3')
  &resources_TB1=VF:1&required_TB1=CUSTOM_PHYSNET1
  &resources_TB2=VF:1&required_TB2=CUSTOM_PHYSNET2
  &required_TB3=I_AM_A_NIC
  &same_subtree=','.join([
     suffix for suffix in suffixes if suffix.startswith('_TB')])
     # (i.e. '_TB1,_TB2,_TB3')

This would give us four candidates:
- One where TA* is under NIC1 and TB* is under NIC2
- One where TB* is under NIC1 and TA* is under NIC2
- One where everything is under NIC1
- One where everything is under NIC2

This of course leads to some nontrivial questions, like:
- How do we express these groupings from the operator-/user-facing
sources (flavor, port, device_profile, etc.)? Especially when different
pieces come from different sources but still need to be affined to each
other. This is helped by allowing named as opposed to autonumbered
suffixes, which is why we're doing that, but it's still going to be
tricky to do in practice.
- What if we want to express anti-affinity, i.e. limit the response to
just the first two candidates? We discussed being able to say something
like same_subtree=_TA3,!_TB3, but decided to defer that
design/implementation for now. If you want this kind of thing in Train,
you'll have to filter post-Placement.

Thanks,
efried
.