...
- required for evaluating instantaneous/available capacity check constraints
- provided by MultiCloud through a Query or DMaaP
- Example: available_capacity(cloud_region_id) -> {x: vCPU, y: memory, z: storage}
- If a public cloud does not want to reveal exact numbers, they could return ranges of capacities.
- Which of these metrics (cpu, mem, disk, network) are relevant to vCPE
- [Ethan] MultiCloud could provide an API for OOF to query available resources information. In my mind, there are two ways, first is OOF check every VIM’s available capacity from MultiCloud, MultiCloud return {vCPU, Memory, Storage}, the second one is OOF send out VNF resources requests of {vCPU: xx, Memory: yy, Storage: zz} to MultiCloud, and MultiCloud return a list of VIMs that capable for this resources requests.
- [Shankar] I’d probably go with the former, where OOF queries for the available capacity for a given set of VIM IDs. Eg., getCapacities([cpu,mem],[vim-id-1, vim-id-5, vim-id-7]) To me this appears a much more scalable approach, since OOF would have eliminated many VIMs based on other constraints that make them an infeasible choice for a given problem. Please do let me know what you think.
- [Ethan] About get_capacity API, the input format could be {“vcpu”: int, “men”: int, “vims”: [vim1, vim2, vim3]} then the return data would be [vim1, vim3]. What do you think?
- [Shankar] We should probably call it check_vim_capacity() perhaps. Just to make the semantics of this clear, check_vim_capacity({“vcpu”: int, “men”: int, “vims”: [vim1, vim2, vim3]}) would mean that the vims returned have met *both* constraints on vcpu and mem.
- Bin Hu: A hybrid approach seems more ideal, i.e. a definitive "Yes/No" answer plus a list of available capacity information. The following is an example (and only an example):
Request:
check_vim_capacity({“vcpu”: int, “mem”: int, “vims”: [cloud-region-id1, cloud-region-id2, cloud-region-id3]})
Response:
{
cloud-region-1:
{
has_capacity: Yes,
capacities: {
“vcpu”: 20,
“mem”: 100
}
}
cloud-region-2:
{
has_capacity: Yes,
capacities: {
}
}
cloud-region-3:
{
has_capacity: No,
capacities: {
“vcpu”: 0,
“mem”: 10
}
}
}
Here, cloud-region-1 has capacity and is willing to give precise capacity information, cloud-region-2 has capacity, but is unwilling to provide exact numbers, while cloud-region-3 doesn’t have capacity but is willing to provide available capacity information. Therefore, OOF will now be able to recommend placement for both cloud-region-1 and cloud-region-2, and will be able to cache cloud-region-1 and cloud-region-3 capacities for making better placement decisions.
- 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 ?
...