...
- Is it possible to get capacities and capabilities for logical groups of resources (like host aggregates)
- Example: available_capacity(cloud_region, host_aggregate)?
- Would there be a logical group for every combination of capabilities
- grows into a large # of combinations very quickly!
- 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 Query: available_capacity(cloud_region, {HPA1, HPA2}) and the output should give the available capacity where the two HPA attributes are satisfied.
- [Ethan] Since HPA information will be populated into A&AI, and OOF can directly query from A&AI and do the match. Do you still need this API in MultiCloud and MultiCloud return a list of available VIM for you?
- [Shankar] I think we will still need support for such holistic capacity checks from MultiCloud. As shown in the example above, the two constraints can independently be satisfied, but may not be satisfiable when looked at in combination. Since the VIM is the only place that has this holistic view, I’m guessing MultiCloud is the right entity capable of making these associations. Please let me know if this is still confusing, and I’ll try to elaborate more on this.
- [Ethan] About the available_capacity(cloud_region, {HPA1, HPA2}), I’m still confused. I was thinking it works like OOF get all VIMs from A&AI, and select those with HPA1 and HPA2 supported, e.g. vim1, vim3, then call multi cloud get_capacity API get_capacity({cpu: 5, mem: 64, vims:[vim1, vim3]}), and multi cloud return satisfied vim list [vim1].
- [Shankar] The flow that you have mentioned is absolutely correct. However, consider a scenario where vim1 has 10 vCPUs 5 of which supports HPA, and 5 that don’t support HPA. Assume that the 5 vCPUs that support HPA are already allocated and not available. So, when OOF checks the following constraints: Evaluating, Constraint (i) Does vim1, vim3 support {HPA1, HPA2} ? The answer is Yes. Now evaluating, Constraint (ii) Does vim1, vim3 have 5 vCPUs ? The answer is VIM1, which has 5 vCPUs. However, as you can see from the example, this doesn’t guarantee that the 5 vCPUs that VIM1 has available supports HPA. OOF has knowledge of whether constraints (i) and (ii) are independently met, but will not be able to know that both (i) and (ii) can be simultaneously met. This association is something that only the MultiCloud can make given its holistic view into the VIM.
- [Matti] I was thinking how this would work in OpenStack. It seems you could do it like this. Assume each HPA attribute matches with a metadata attribute associated with a host aggregate.
- List all the host aggregates (nova aggregate-list)
- Determine which ones match all the HPA attribute metadata attributes (nova aggregate-details)
- Get the list of hosts in these matching host aggregates
- Get the remaining capacity on these hosts and see if it is larger than the specified amount
- Bin Hu: Assume we have [cpupin, numa, largepages] as the HPA capabilities for vCPU resource, "Holistic Check" of a vCPU with those HPA means:
cpupin AND numa AND largepages AND capacity(vcpu: 5)
- 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.
...