vCPEPoliciesAndInformationSources Copy


AAI Schema Changes  Refer → Persistence of HPA related information in AAI

HPACapabilities

Given a list of HPACapabilities as requirements, return the candidate list of (cloud region + flavor_reference) such that there exist at least one flavor with all HPACapabilities satisfied.

Naive Approach relying of resources micro service

  1. GET /cloud-infrastructure/cloud-regions (depth=0)
  2. From the list of cloud regions return list of cloud region matching all the mandatory HPA capabilities.  (Is there a way to efficiently do this in AAI to avoid step1)
  3. For Each cloud region from cloud_regions (from prev step)
    1. GET /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-region-id}/flavors
    2. For Each flavor 

      1. Get RelationshipList and find the list of capabilities.

      2. Match the requirement with the list of capabilities

      3. Add the (cloud region + flavor_reference) to candidate list of cloud region

Desired Approach

  1. Get all flavors that satisfies all HPACapability requirements (HPA1 AND HPA2 AND HPA3) 
  2. Add all (cloud region + flavor_reference) to candidate list of cloud region

If using Naive approach how to efficiently do step 2 so that we don't have to parse all cloud regions.


Unknowns:

Min Guarantee Capabilities

Get a list of canditate cloud regions and flavor references that satisfies the minimum guarantee requirements. For eg: cpu = 4, memory = 8GB

Question : Similar to HPACapabilities. Can we rely on flavors to get this information?

Location 

Existing Service location.

Given the service details identify the cloud-region and the location details from complex.

Since this is a service we need to identify where it can get cloud-region and Complex

service-instance → cloud-region → complex  → (lat,long)

CloudAffinity

Given a cloud-region identify the location details from complex.

  1. GET /network/generic-vnfs?prov-status=PROV&equipment-role={}
  2. For Each vnf in generic-vnfs
    1. Get RelationshipList and find the list of vservers.
    2. For Each vserver in vservers list
      1. Get RelationshipList and find the pserver.
      2. Using the URL from relationship data get the pserver details /cloud-infrastructure/pservers/pserver 
        1. Get RelationshipList and find the cloud-region
        2. Using the URL from relationship data get the cloud-region details
          1. Get complex information and location information

generic-vnf → vserver → pserver → complex  → (lat,long)

generic-vnf →  complex  → (lat,long)

Unknowns :

  • Does VIM onboarding ensures the complex information is populated and the relationship between Cloud-region and complex established? 
  • Confirm with ESR if this association between complex and cloud-region will be taken care - Looks like yes. Ask ESR.
















  • No labels

5 Comments

  1. Shankaranarayanan Puzhavakath Narayanan

    All,

    If I understand it correctly, the current data model in AAI looks like the following:

    cloud-region1 → flavor1 → [HPA1, HPA2]

    cloud-region1 → flavor2 → [HPA3]

    Assumption is that there will be a one-to-one mapping between a VNF and a flavor. 

    Consider a scenario where a VNF spans two VMs, one of which needs HPA1, HPA2 and the other needs HPA3. Now, would VNF be represented as two resources that need to be homed? Is it always true that there will be only one flavor that a VNF needs to map onto?

    Therefore, either 

    (i) VNF cannot expect to have its requirements across two flavors, or 

    (ii) The assumption of homogeneity may require that there be a flavor with a super set of all capabilities that a cloud-region supports in which case we will end up with one flavor per cloud region (cloud-region1 → flavor3 → [HPA1, HPA2, HPA3, HPA4, HPA5]), or

    (iii) requires the creation of multiple flavors that captures the different combinations of capabilities, which is a combinatorial problem. 



    1. Srinivasa Addepalli

      Hi Shankar,

      VNF term is used little bit loosely by many.  When we say VNF here, we really meant VNFC (that is realized using a VM).  If VNF contains two VNFCs, then there would be two HPA sets.  

      Having said that, a given VNFC can have Multiple VM instances due to scale-out.   That is same VM image and HPA set  is used to bring up multiple instances (to take up load).

      Srini

      1. Shankaranarayanan Puzhavakath Narayanan

        Hi Srini, 

        Thanks for your note. However, I'm still confused with the terminology here. Based on my understanding, a VNF Resource can comprise of multiple VF Modules (analogous to the VDU, I think), and the VF Modules can have multiple VMs (eg., packaged into a single HEAT template), each of which can require different sets of hardware capability, and thereby requiring a different flavor. 

        Since OOF placement decisions are made at the granularity of the VNF Resource, which is two levels of indirection higher than a VM - I'm not clear how this mapping of a specific VM (I'm guessing this is the equivalent of VNFC) to its required flavor would happen during the decision making and during the actual orchestration. 

        Thanks,

        Shankar. 

        1. Srinivasa Addepalli

          Just to level set:

          • One NSD (Network Service Descriptor) can contain multiple VNFs.
          • Each VNF can contain 
            • Multiple VDUs (VNFCs)
            • Internal Virtual Links
            • Internal Connection points
            • Connection points to External Links.
          • Each VDU (VNFC) is normally realized as one VM or set of scale-out VMs.

          Each VDU is  defined with HPA properties that are required for that VDU.

          An example:

          Let us say that a NSD has 2 VNFs. Each VNF has 4 VDUs.

          I believe OOF is passed with NSD by SO or VF-C.

          OOF is expected to determine right region and flavor to use for each VDU.  In above example, I would assume that OOF returns total of 8 regions and one flavor for each region (8 flavors) back to SO.

          Having said that, many times, a VNF consists only one VNFC (one VDU). At least I did not see any real deployment example where a VNF contains multiple VNFCs (VDUs).  Hence, people tend to equate VNF with VNFC (VDU).  But, TOSCA NFV specification do have ability to represent a VNF with multiple VDUs. 

          In any case, it is good for OOF to assume that a VNF contains multiple VDUs.

          Srini

          1. Srinivasa Addepalli

            HPA feature set filter is for each VDU.  So is, distance filter.

            But affinity, anti-affinity are at the scope of VNF and NSD.

            Typical affinity/anti-affinity rules are as follows:

            • Across VDUs of VNF (Few VDUs of VNF be on the same compute node, or in the same rack or at the edge in case of affinity rules or separately  in various compute nodes, various racks or edges).
            • Across VNFs of NSD ( Few VNFs of NSD in the same compute, rack or edge in case of affinity or separately in case of affinity rules, or in different places in case of anti-affinity rules).

            That is why, I think SO needs to pass massaged NSD with VNFs and VDUs of VNFs together for placement decisions based on affinity/anti-affinity policy rules.  Passing the VNF by SO is not good enough if OOF intends to make placement decisions based on affinity and anti-affinity rules.

            Srini