Ankitkumar Patel:  Summarizing the discussion of this email thread to just make sure that we all are on the same page.

The HPA requirements of a VNF are extracted from a VNF descriptor and captured in a TOSCA model in a tuple format (for the sake of extensibility purpose). Some of these requirements cannot be change during the lifecycle of a service; while the other optional requirements can be overwritten by a service designer or operator (For example, the use of SR-IOV may be preferred by an operator if a VNF can support SR-IOV and a vendor does not have a preference). Once a service model is designed and uploaded into the SDC repository, the policy service is notified. The policy service then fetches the TOSCA model, extracts out the HPA requirements from TOSCA through decomposition, composes the HAP polices for the homing service (OOF-HAS), and stores in the policy repository. When the homing service receives a homing request from SO, the homing service asks for the associated HPA policies from the policy platform. Based on the received HPA policies, the homing solution finds and returns the placement solutions.


  • No labels

5 Comments

  1. Srinivasa Addepalli

    Hi Ankit and Shankar, (Ankitkumar Patel and Shankaranarayanan Puzhavakath Narayanan)

    Please consider following HPA examples and please do let us know how these can be represented. 

    Let us assume that VNF requires following capabilities

    • Mandatory:
      • Numa :
        • NUMA memory on node 0 : 2GB - 4GB
        • NUMA memory on node 1:  4GB - 8GB
        • NUMA cores on node 0 :  2
        • NUMA cores on node 1: 4
      • NIC PCIe:
        • Device ID:  XYZ
        • Vendors ID:  ABC.
    • Preferred:
      • SGX:
        • SGX Encrypted memory size: 128Mbytes to 512Mbytes.
      • AES-NI
      • AVX-512


    How do you represent this in Policy?  Note that for Numa feature,  there is a need for 4 matching expressions.  For PCIe, there is need for two matching expressions.  For SGX, there is one matching expression.  For AES-NI and AVX-512, there is one matching expression required for each.

    We also have a requirement that it is extensible. That is, whenever new HW feature is introduced, no coding is necessary anywhere (except for some normalization code in Multi-Cloud plugin).  That is, no code changes in OOF.

    Keeping above requirements in mind,  would this be the right way to represent this?

    "service": "Some Service",
    "policyName": "OOF_Beijing.vGMuxInfra",
    "description": "HPA policy for vGMuxInfra",
    "templateVersion": "0.0.1",
    "version": "ONAP_Beijing",
    "priority": "3",
    "riskType": "test",
    "riskLevel": "2",
    "guard": "False",
    "content": {

       {
          "hpa_feature": "NUMA"
          "mandatory": "yes"
          "architecture": "intel64"
          "matchingexpressions" :{
             {
                "attribute_name" : "NumaMemory_node0"
                "attribute_value" : {
                    "magnitude": "2-4",
                    "operator": "range",
                    "unit": "GB"
                 }
             },
             {
                "attribute_name" : "NumaMemory_node1"
                "attribute_value" : {
                    "magnitude": "4-8",
                    "operator": "range",
                    "unit": "GB"
                 }
             },
             {
                "attribute_name" : "NumaCores_node0"
                "attribute_value" : {
                    "magnitude": 2,
                    "operator": "=",
                    "unit": ""
                 }
             },
             {
                "attribute_name" : "NumaCores_node1"
                "attribute_value" : {
                    "magnitude": 4,
                    "operator": "=",
                    "unit": ""
                 }
             }
           }
        },


        {
           "hpa_feature" : "PCIePassThrough",
           "mandatory" : "yes",
           "architecture": "intel64"
           "matchingexpressions": {
              {
                 "attribute_name" : "deviceID"
                 "attribute_value": {
                    "magnitude" = 0xXYZ,
                    "operator" = "=",
                    "unit": ""
                 }
              },
              {
                 "attribute_name" : "vendorID"
                 "attribute_value": {
                    "magnitude" = 0xABC,
                    "operator" = "=",
                    "unit": ""
                 }
              }
           }
         },

        {
           "hpa_feature" : "SGX",
           "mandatory" : "no",
           "score" : 10
           "architecture": "intel64"
           "matchingexpressions": {
              {
                 "attribute_name" : "sgx_mem_size"
                 "attribute_value": {
                    "magnitude" = 128,
                    "operator" = "=",
                    "unit": "MB"
                 }
              }
            }
         },



        {
           "hpa_feature" : "AESNI",
           "mandatory" : "no",
           "score" : 10
           "architecture": "intel64"
           "matchingexpressions": {
              {
                 "attribute_name" : "is_present"
                 "attribute_value": {
                    "magnitude" = "yes",
                    "operator" = "=",
                    "unit": "string"
                 }
              }
            }
         },

        {
           "hpa_feature" : "AVX512",
           "mandatory" : "no",
           "score" : 10
           "architecture": "intel64"
           "matchingexpressions": {
              {
                 "attribute_name" : "is_present"
                 "attribute_value": {
                    "magnitude" = "yes",
                    "operator" = "=",
                    "unit": "string"
                 }
              }
            }
         },



        "identity": "hpa_vGMuxInfra",
        "policyScope": {
            "serviceType": ["vCPE"],
            "geoRegion": ["US", "INTERNATIONAL"],
            "networkType": ["ip"],
            "resourceInstanceType": ["vGMuxInfra"]
        },
        "type": "????",
        "resourceInstanceType": ["vGMuxInfra"]

    1. Ankitkumar Patel

      Hi Srini,

      In your policy example, all the HPA requirements are captured in a single policy; however, we plan to capture the HPA requirements through multiple independent policies since different VNFs may require different sets of capabilities/policies. You can find the examples at the Policy Specification and Retrieval for OOF page. 

      Since the HPA requirements/capabilities can change over time as technologies evolve, I agree that we should capture the requirements through policy models that are extensible. One such approach is the use of attribute name-value pairs as you have already considered in your example. However, we would like to postpone such extensible modeling in the later releases for the following reason.

      • Policy templates are auto-generates from policy models in the policy system. You can envision policy templates as web-based forms which can be filled by a policy designer to define policies. If we model a policy using generic attribute name-value pairs, a designer may not get a clear idea on what to insert in each field. Having a specific attribute key may give them some context on what is expected. Once the policy system start supporting either tooltip capability (to provide additional comments for a field) or context-driven dynamic drop down menu (Based on the values of already filled fields, the potential values of the subsequent fields are dynamically populated), we can consider modeling the HPA policies in an extensible manner.

      Please review on the HPA policy examples and provide us your comments/feedbacks.

      Ankit

      1. Srinivasa Addepalli

        Ankitkumar Patel, Shankar Satyanarayanan, Dileep Ranganathan, Alexander Vul, Adolfo Perez-Duran

        Hi Ankit

        My comments embedded.

        In your policy example, all the HPA requirements are captured in a single policy; however, we plan to capture the HPA requirements through multiple independent policies since different VNFs may require different sets of capabilities/policies.

        SRINI> The example I have provided is for VNF.  As discussed in the call on last Tuesday,  there would be as many policies as number of VNFDs.  That is, say, if service designer creates three NSDs (Gold, Silve and Bronze) with 4 VNFs each in each NSD, then there would be 12 policy records created automatically.   What I have shown is one policy as an example. With this, are you okay with one policy per VNFD? Please let us know.

        You can find the examples at the Policy Specification and Retrieval for OOF page. 

        Since the HPA requirements/capabilities can change over time as technologies evolve, I agree that we should capture the requirements through policy models that are extensible. One such approach is the use of attribute name-value pairs as you have already considered in your example. However, we would like to postpone such extensible modeling in the later releases for the following reason.

        • Policy templates are auto-generates from policy models in the policy system. You can envision policy templates as web-based forms which can be filled by a policy designer to define policies. If we model a policy using generic attribute name-value pairs, a designer may not get a clear idea on what to insert in each field. Having a specific attribute key may give them some context on what is expected. Once the policy system start supporting either tooltip capability (to provide additional comments for a field) or context-driven dynamic drop down menu (Based on the values of already filled fields, the potential values of the subsequent fields are dynamically populated), we can consider modeling the HPA policies in an extensible manner.


        SRINI> For us, it is very important to have this as extenible as the rate at which HW/FW features get added (not only due to new processor families, processors, architectures, but also due to add-on cards in compute nodes, various firmware versions with different capabilities) is not small.  If there is any other mechanism, please suggest.  Also, as we discussed other day, HPA policies are normally auto-generated and so many time complexity is limited (I understand that providing GUI is also very important if somebody wants to create policies manually, but in my view GUI can be made simple with little bit more logic in the backend).   It would be good (I feel that it is required) if OF and Policy provide this flexibility for HPA. Let us know.

  2. Srinivasa Addepalli

    Hi Ankit, 

    I based HPA policy based on few examples you had given earlier. I don't see those examples anymore.  In any case, I hope you guys would give some feedback on above.  

    Srini

    1. Ankitkumar Patel

      Hi Srini,

      Optimization Service Design Framework (OSDF) is responsible for modeling optimization constraints/objective functions as policies before/during an application deployment-time, and fetching the policies from the policy platform and translating them back into a format that is consumable by the application during the run-time. You can find more details on policy modeling and interactions/information flow between OSDF and the policy system at the following wiki page; Policy Specification and Retrieval for OOF.