Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

    • required for evaluating instantaneous/available capacity check constraints
    • provided by MultiCloud through a Query or DMaaP (question)
    • 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 (question)
    • [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.
    • [ethanlynnl] 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] Please make the list of VIM list be possible to be extended. So the input for check_capacity API might looks like:  {“vcpu”: int, “men”: int, “vims”: [{"cloud-owner":"vim1 owner", "cloud-region-id":"region id 1"}, {"cloud-owner":"vim2 owner", "cloud-region-id":"region id 2"}, {"cloud-owner":"vim3 owner", "cloud-region-id":"region id 3}]}. With this format, later OOF could add more constraints to those specified VIMs in list, e.g. for the cloud region with multiple available zone,  and OOF want to check that if required capacity is available on specified AZ, then the vim list could be  [{"cloud-owner":"vim1 owner", "cloud-region-id":"region id 1", "availabe-zone":"az1"}, {"cloud-owner":"vim2 owner", "cloud-region-id":"region id 2","availabe-zone":"az2"}{"cloud-owner":"vim3 owner", "cloud-region-id":"region id 3, "availabe-zone":"az3"}]
    • 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):

...