OOF - MultiCloud interaction in R2



Homing Policies and corresponding information required from MultiCloud for Homing in R2:

  • 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)

      • [Shankar] This is a good question to ask, and I’m not sure who creates these complex information in AAI. That said, I do know from the ECOMP parlance that multiple openstack instances (cloud-regions) could share the same complex. 

      • [Matti] Complex is the physical location (e.g., data center) where the cloud-regions (= OpenStack instance = set of compute nodes managed by one instance of OpenStack control plane) reside. Is the model in MultiVIM that each cloud-region registers with MultiVIM individually even if there may be multiple cloud-regions in the same data center? 

      • [Bin ] The relationship between a service instance or more specifically a generic VNF of that service instance and the complex can be inferred by the relationship chain: generic-vnf → vserver → cloud region → complex.  Please note that the cloud region is the parent node of vserver, so you can find out the cloud region by the vserver easily .

  •  

    • For R2

      • @ethanlynnl Based on discussion of last meeting, the location info like latitude and longitude are existed in A&AI complex schema, and if anyone wants to find a location of vnf, it could query the info in A&AI and follow the relationship to find the cloud-region and latitude/longitude info in complex.  The only problem is ESR portal need to allow cloud admin to input these information.


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

      • [Bin] The location information is coming along with complex which is populated by robot script in In Release 1. ESR might be able to help since complex belongs to external system information logically.

    • For R2

      • @ethanlynnl Same as above.

  • HPA capabilities, indirectly, through AAI

    • CPU Pinning, NUMA as key value pairs 

    • Example: cloud-region-id: {CPU Pinning: True, NUMA: False, Large Pages: True}

    • required for evaluating HPA constraints

    • Is this provided by MultiCloud during VIM registration 

      • [Ethan] Yes, When a new VIM was registered through ESR portal, ESR will call MultiCloud to update VIM informations like networks or images in A&AI, we could populate HPA during register in R2 release.  What kind of HPA features that might need in R2?

      • [Shankar] The exact HPA attributes relevant in R2 is still being determined. That said, it is most likely to be a list of attributes that are associated with a cloud-instance in AAI. Does that sound a reasonable way to capture capabilities ?

      • [Ethan] About HPA, using a list [hpa1, hpa2] sounds not good to me since it will make filtering harder, I would prefer a map {hpa1: true, hpa2: false}. 

      • [Shankar] A map works just fine from an OOF perspective. However, I wonder when a HPA:false check will need to be performed