Homing requires information from MultiCloud for the following in R2:
- HPA capabilities, indirectly, through AAI
- Aggregate Utilization, directly (through DMaaP
)
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:
- 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