Information required from MultiCloud for Homing in R2:
- HPA capabilities, indirectly, through AAI
- CPU Pinning, NUMA
- required for evaluating HPA constraints
- Aggregate Utilization, directly (through DMaaP
)- CPU, Mem, Network, Disk, etc
- required for evaluating instantaneous/available capacity check constraints
- Aggregate capacity, indirectly (through AAI)
- CPU, Mem, Network, Disk, etc
- Does this fold naturally under the aggregate utilization - when do we actually need aggregate static capacity for decision making ?
R3 and beyond:
- Host-level affinity/anti-affinity capability, indirectly through AAI
- Min-guarantee capability, indirectly through AAI
Open Questions:
- Evaluating constraint combinations:
- Example: consider the following two constraints
- Is there sufficient number of CPUs in the (cloud) cluster ? - (Yes)
- Does the (cloud) cluster support NUMA ? - (Yes)
- But, is there sufficient number of CPUs that support NUMA ? - Maybe not !
- Example: consider the following two constraints
Reservations (R3 + ):
- Based on prior discussions with SO, OOF and MultiCloud, reservations may be a desirable feature.
- Actual orchestration of resources may take long enough during the SO service instantiation workflows, during when homing recommendations provided by OOF may become potentially infeasible. It is highly desirable to reduce this window of vulnerability.
- Infeasibility may happen even if a "capacity check" is performed by OOF
- A possible solution is to have soft reservations, which is made by OOF to MultiCloud. The response to soft reservation requests can be binary (Success/Failure) from MultiCloud. OOF would be responsible rollback of resources when only a part of reservation succeeds. Soft reservations have a timeout which bounds the time for which resources are locked by MultiCloud.
Open Questions:
- Trade-off: cost of implementing soft reservations in MultiCloud vs cost of failed orchestration attempts at SO
- Do all VIMs support reservations ?
- Start with Openstack reservations