Versions Compared

Old Version 7

changes.mady.by.user Shankaranarayanan Puzhavakath Narayanan

Saved on

compared with

New Version 8

changes.mady.by.user Ethan Lynn

Saved on

Key

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

...

  • Latency (air distance)
    • Location/Coordinates of customer 
      • MultiCloud may not have an active role in providing this information, which would come from SO as a part of the customer order
      • [Ethan]: MultiCloud won’t populating that information.
    • Location of existing service instances (or the cloud-region)
      • [Ethan]: The relationship information between VNF and cloud-region was populated by SO if I remember correctly.
      • In AAI, each cloud-region (GET /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-region-id}) record points to a complex (GET /cloud-infrastructure/complexes/complex/{physical-location-id}) and the complex relates to a lat and long. Is it correct that a VIM needs to register with MultiVIM? Does that registration have enough information for MultiVIM to create the region and complex data in A&AI?
      • Example: service instance → cloud-region → complex  → (lat,long)
      • [Ethan]: Currently we use A&AI/ESR portal to register a new VIM, some basic information like cloud-owner and cloud-region and credentials could be input from this portal and put into A&AI db, but not the complex info. After we nail down the information that OOF might need, we can discuss with ESR team to extend it. What exactly field you need in complex schema?
      • [Shankar] The minimal information required in the complex schema for homing in R2, would be the geographical coordinates (latitude, longitude). But I’m guessing it will be more than that - physical-location-id, complex-name, data-center-code, url, etc.. based on the R1 API of AAI (v11, I think)
      • Ethan Who will create a complex object? Can we pre-load the complex information into A&AI and provide a list of locations in ESR portal for customer to select? Since multiple open stack instance could share a same location (us-west etc)
  • Cloud Affinity
    • Location of cloud-regions (same as above)
    • [Ethan] If it’s the same as above, this do not fall into the scope of MultiCloud.

...

    • 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.
    • 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?
  • 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 ?

...