Skip to end of metadata
Go to start of metadata

DRAFT

This is a work in progress. Comments and suggestions gladly accepted. Draft will be removed once this is finalized.


HPA SO External Sequence Flow for Casablanca

HPA SO External API Interaction for Casablanca

Policy

Still Under Discussion: Utilize existing SO generic-rest-adapter. This is a possible interaction with Policy to obtain service specific flow path decision for Service Model.

OOF

Still Under Discussion: Utilize existing SO Homing code. SO will adhere the OOF/SO R2 APIs updated for R3 to fix issues from R2 and include passing on a set of generic key value pairs that could contain such values as flavor_name:HPA2 or SRIOV attributes. These key value pairs will be passed to Multicloud during instantiation as OOF_Directives. 

OOF-SO Interaction in R2 

OOF/HAS API Specifications


Addition of oofDirectives as part of

"assignmentInfo"

to R2 (doesn't change api): 

                     {  
"key":"oofDirectives",
"value":{
"directives":[
{
"vnfc_directives":[
{
"vnfc_id":"<ID of VNFC>",
"directives":[
{
"directive_name":"<Name of directive,example flavor_directive>",
"attributes":[
{
"attribute_name":"<name of attribute, such as flavor label>",
"attribute_value":"<value such as cloud specific flavor>"
}
]
},
{
"directive_name":"<Name of directive,example vnic-info>",
"attributes":[
{
"attribute_name":"<name of attribute, such as vnic-type>",
"attribute_value":"<value such as direct/normal>"
},
{
"attribute_name":"<name of attribute, such as provider netweork>",
"attribute_value":"<value such as physnet>"
}
]
}
]
}
]
},
{
"vnf_directives":{
"directives":[
{
"directive_name":"<Name of directive>",
"attributes":[
{
"attribute_name":"<name of attribute>",
"attribute_value":"<value>"
}
]
},
{
"directive_name":"<Name of directive>",
"attributes":[
{
"attribute_name":"<name of attribute>",
"attribute_value":"<value >"
},
{
"attribute_name":"<name of attribute>",
"attribute_value":"<value >"
}
]
}
]
}
}
]
}
}

OOF Homing Response:

{  
   "transactionId":"xxx-xxx-xxxx",
   "requestId":"yyy-yyy-yyyy",
   "requestStatus":"completed",
   "statusMessage":"",
   "solutions":{  
      "placementSolutions":[  
         [  
            {  
               "resourceModuleName":"vGMuxInfra",
               "serviceResourceId":"someResourceId",
               "solution":{  
                  "identifierType":"serviceInstanceId",
                  "identifiers":[  
                     "gjhd-098-fhd-987"
                  ]
               },
               "assignmentInfo":[  
                  {  
                     "key":"cloudOwner",
                     "value":"amazon"
                  },
                  {  
                     "key":"vnfHostName",
                     "value":"ahr344gh"
                  },
                  {  
                     "key":"isRehome",
                     "value":"False"
                  },
                  {  
                     "key":"cloudRegionId",
                     "value":"1ac71fb8-ad43-4e16-9459-c3f372b8236d"
                  }
               ]
            },
            {  
               "resourceModuleName":"vG",
               "serviceResourceId":"someResourceId",
               "solution":{  
                  "identifierType":"cloudRegionId",
                  "cloudOwner":"amazon",
                  "identifiers":[  
                     "gjhd-098-fhd-987"
                  ]
               },
               "assignmentInfo":[  
                  {  
                     "key":"cloudOwner",
                     "value":"amazon"
                  },
                  {  
                     "key":"cloudRegionId",
                     "value":"1ac71fb8-ad43-4e16-9459-c3f372b8236d"
                  },
                  {  
                     "key":"oofDirectives",
                     "value":{  
                        "directives":[  
                           {  
                              "vnfc_directives":[  
                                 {  
                                    "vnfc_id":"<ID of VNFC>",
                                    "directives":[  
                                       {  
                                          "directive_name":"<Name of directive,example flavor_directive>",
                                          "attributes":[  
                                             {  
                                                "attribute_name":"<name of attribute, such as flavor label>",
                                                "attribute_value":"<value such as cloud specific flavor>"
                                             }
                                          ]
                                       },
                                       {  
                                          "directive_name":"<Name of directive,example vnic-info>",
                                          "attributes":[  
                                             {  
                                                "attribute_name":"<name of attribute, such as vnic-type>",
                                                "attribute_value":"<value such as direct/normal>"
                                             },
                                             {  
                                                "attribute_name":"<name of attribute, such as provider netweork>",
                                                "attribute_value":"<value such as physnet>"
                                             }
                                          ]
                                       }
                                    ]
                                 }
                              ]
                           },
                           {  
                              "vnf_directives":{  
                                 "directives":[  
                                    {  
                                       "directive_name":"<Name of directive>",
                                       "attributes":[  
                                          {  
                                             "attribute_name":"<name of attribute>",
                                             "attribute_value":"<value>"
                                          }
                                       ]
                                    },
                                    {  
                                       "directive_name":"<Name of directive>",
                                       "attributes":[  
                                          {  
                                             "attribute_name":"<name of attribute>",
                                             "attribute_value":"<value >"
                                          },
                                          {  
                                             "attribute_name":"<name of attribute>",
                                             "attribute_value":"<value >"
                                          }
                                       ]
                                    }
                                 ]
                              }
                           }
                        ]
                     }
                  }
               ]
            }
         ]
      ]
   }
}


MultiCloud

Still Under Discussion: Utilize existing so-opendstack-adapter and extend, or clone to so-multicloud-adapater and extend. Use Multicloud OpenStack Proxy API and extend HEAT API payload with generic-vnf-id, vf-module-id, oof_directives, sdnc_directives and template_type.

API URI            http://{msb IP}:{msb port}/api/multicloud /v1/{cloud-owner}/{cloud-region-id}/infra_workload

REQUEST BODY
( =================== parameters below template type are valid for request with “template_type”:“heat” ===================)

{  
   "generic-vnf-id":"<generic-vnf-id>",
   "vf-module-id":"<vf-module-id>",
   "oof_directives":{  
      "directives":[  
         {  
            "vnfc_directives":[  
               {  
                  "vnfc_id":"<ID of VNFC>",
                  "directives":[  
                     {  
                        "directive_name":"<Name of directive,example flavor_directive>",
                        "attributes":[  
                           {  
                              "attribute_name":"<name of attribute, such as flavor label>",
                              "attribute_value":"<value such as cloud specific flavor>"
                           }
                        ]
                     },
                     {  
                        "directive_name":"<Name of directive,example vnic-info>",
                        "attributes":[  
                           {  
                              "attribute_name":"<name of attribute, such as vnic-type>",
                              "attribute_value":"<value such as direct/normal>"
                           },
                           {  
                              "attribute_name":"<name of attribute, such as provider netweork>",
                              "attribute_value":"<value such as physnet>"
                           }
                        ]
                     }
                  ]
               }
            ]
         },
         {  
            "vnf_directives":{  
               "directives":[  
                  {  
                     "directive_name":"<Name of directive>",
                     "attributes":[  
                        {  
                           "attribute_name":"<name of attribute>",
                           "attribute_value":"<value>"
                        }
                     ]
                  },
                  {  
                     "directive_name":"<Name of directive>",
                     "attributes":[  
                        {  
                           "attribute_name":"<name of attribute>",
                           "attribute_value":"<value >"
                        },
                        {  
                           "attribute_name":"<name of attribute>",
                           "attribute_value":"<value >"
                        }
                     ]
                  }
               ]
            }
         }
      ]
   },
   "sdnc_directives":{  
      "directives":[  
         {  
            "vnfc_directives":[  
               {  
                  "vnfc_id":"<ID of VNFC>",
                  "directives":[  
                     {  
                        "directive_name":"<Name of directive,example flavor_directive>",
                        "attributes":[  
                           {  
                              "attribute_name":"<name of attribute, such as flavor label>",
                              "attribute_value":"<value such as cloud specific flavor>"
                           }
                        ]
                     },
                     {  
                        "directive_name":"<Name of directive,example vnic-info>",
                        "attributes":[  
                           {  
                              "attribute_name":"<name of attribute, such as vnic-type>",
                              "attribute_value":"<value such as direct/normal>"
                           },
                           {  
                              "attribute_name":"<name of attribute, such as provider netweork>",
                              "attribute_value":"<value such as physnet>"
                           }
                        ]
                     }
                  ]
               }
            ]
         },
         {  
            "vnf_directives":{  
               "directives":[  
                  {  
                     "directive_name":"<Name of directive>",
                     "attributes":[  
                        {  
                           "attribute_name":"<name of attribute>",
                           "attribute_value":"<value>"
                        }
                     ]
                  },
                  {  
                     "directive_name":"<Name of directive>",
                     "attributes":[  
                        {  
                           "attribute_name":"<name of attribute>",
                           "attribute_value":"<value >"
                        },
                        {  
                           "attribute_name":"<name of attribute>",
                           "attribute_value":"<value >"
                        }
                     ]
                  }
               ]
            }
         }
      ]
   },
   "template_type":"<heat/tosca/etc.>",





   "files":{  

   },
   "disable_rollback":true,
   "parameters":{  
      "flavor":"m1.heat"
   },
   "stack_name":"teststack",
   "template":"\nheat_template_version: 2013-05-23\ndescription: Simple template to test heat commands\nparameters:\n  flavor: {default: m1.tiny, type: string}\nresources:\n  hello_world:\n    type: OS::Nova::Server\n    properties:\n      key_name: heat_key\n      flavor: {get_param: flavor}\n      image: 40be8d1a-3eb9-40de-8abd-43237517384f\n      user_data: |\n        #!/bin/bash -xv\n        echo \"hello world\" > /root/hello-world.txt",
   "timeout_mins":60
}


HPA SO Casablanca Stories

Key Summary T Created Updated Due Assignee Reporter P Status Resolution
Loading...
Refresh

  • No labels

17 Comments

  1. Marcus Williamsramki krishnanBin YangHuang HaibinRuoyu YingDileep RanganathanEthan Lynn

    I want to provide my 2 cents, keeping multiple VNFCs in mind and future extensibility in mind.

    • At the HEAT/ARM/K8S level, SO talks to Multi-Cloud at the VNF level. That is, the request that is sent to the MultiCloud is for many VNFCs. For example, in case of firewall VNF, there are actually 3 VNFCs -  firewall VNFC,  Generator VNFC and Sink VNFC.  Each VNFC might have its own flavor, its own OAM IP address, its own SRIOV information.  That needs to be considered in the oofDirectives and SDNCDirectives.
    • In the above definition, for a given type (such as flavor,), the assumption is that there is only one value.  Though it is true for flavors, but it is not true for  SRIOV-NIC,  In case of SRIOV-NIC directive, OOF need to pass multiple attributes.  Hence grouping of array of  these attributes is required.
    • In future (when affinity and anti-affinity is implemented in ONAP), there would be need for OOF to pass its directives at the VNF level.

    Keeping above in mind, one definition I can think of is this ( I am taking OOF directives here to make a point, but it is equally applicable for SDNC directives too)

    "oof_directives" : { 
             "vnfc_directives":[
                  { "vnfc_id" : "<ID of VNFC>" //Need not filled in today, but for future purposes
                    "directives" : [
                      {"directive_name": "<Name of directive,example flavor_directive>", 
                       "attributes": [
                           {"attribute_name": "<name of attribute, such as flavor label>", "attribute_value":"<value such as cloud specific flavor>"},
     
                        ]
                      },
                      {"directive_name": "<Name of directive,example vnic-info>", 
                       "attributes": [
                           {"attribute_name": "<name of attribute, such as vnic-type>", "attribute_value":"<value such as direct/normal>"},
                           {"attribute_name":"<name of attribute, such as provider netweork>">, "attribute_value":"<value such as physnet>" 
                        ]
                      }
                    }
                  ]
                          }.
             "vnf_directives": {
                  "directives" : [
                      {"directive_name": "<Name of directive>", 
                       "attributes": [
                           {"attribute_name": "<name of attribute>", "attribute_value":"<value>"},
     
                        ]
                      },
                      {"directive_name": "<Name of directive>", 
                       "attributes": [
                           {"attribute_name": "<name of attribute>", "attribute_value":"<value >"},
                           {"attribute_name":"<name of attribute>">, "attribute_value":"<value >" 
                        ]
                      }
              }
             
    }


    It would be good to provide this flexibility to add new directives and multiple attributes to each directives.

    Srini

    1. Hi Srinivasa Addepalli

      Our discussion, design and plan up to now has been to opaquely pass along a set of directives from OOF to MultiCloud. The above format seems to assume that SO will process OOF response and format it as above, based on what OOF sends today. While this is not necessarily a huge lift, it does increase the scope and change generally agreed upon plans. 


      It seems to me that your above format could fit within what is defined above, as directives takes a list of JSON objects.

      "{ "key": "flavor", "value": "hpa.flavor1" }, { "key": "sriovParam", "value": "param" }"

      is just an example content based on what OOF has sent in the past. See below example:

      {
         "oof_directives":{
            "directives":[
               {
                  "vnfc_directives":[
                     {
                        "vnfc_id":"<ID of VNFC>",
                        "directives":[
                           {
                              "directive_name":"<Name of directive,example flavor_directive>",
                              "attributes":[
                                 {
                                    "attribute_name":"<name of attribute, such as flavor label>",
                                    "attribute_value":"<value such as cloud specific flavor>"
                                 }
                              ]
                           },
                           {
                              "directive_name":"<Name of directive,example vnic-info>",
                              "attributes":[
                                 {
                                    "attribute_name":"<name of attribute, such as vnic-type>",
                                    "attribute_value":"<value such as direct/normal>"
                                 },
                                 {
                                    "attribute_name":"<name of attribute, such as provider netweork>",
                                    "attribute_value":"<value such as physnet>"
                                 }
                              ]
                           }
                        ]
                     }
                  ]
               },
               {
                  "vnf_directives":{
                     "directives":[
                        {
                           "directive_name":"<Name of directive>",
                           "attributes":[
                              {
                                 "attribute_name":"<name of attribute>",
                                 "attribute_value":"<value>"
                              }
                           ]
                        },
                        {
                           "directive_name":"<Name of directive>",
                           "attributes":[
                              {
                                 "attribute_name":"<name of attribute>",
                                 "attribute_value":"<value >"
                              },
                              {
                                 "attribute_name":"<name of attribute>",
                                 "attribute_value":"<value >"
                              }
                           ]
                        }
                     ]
                  }
               }
            ]
         }
      }


      The above can be achieved if OOF sends oof_directives formatted as above, or if SO does some processing and munging on the current OOF homing response. However I don't think the API needs to change to accommodate this.

      1. Hi Marcus,

        You are right that SO does not need to interpret anything in oofDirectives. Internal format of oofDirectives is mainly meant for OOF and Multi-Cloud teams as OOF is the generator of this information and Multi-Cloud is consumer of this information.  

        Ruoyu YingDileep Ranganathan and Huang Haibin,   Since you are developers involved in this, can this be proposed to your respective teams and also update JIRA?

        Srini

        1. should we consider a common directives, considering the TOSCA HEAT, TOSCA R2+, even SDNC, etc?


          Suggestions:
          directives:[

              {
                   "id":"<directive_id>" # unique id of the directives, such as vnf id, vnfc id, etc Option

                   "type":"<directive_type>"   # type of the directives, such as vnfc, vnf,.....     Must
                   "attributes":{<directive_attributes>} # attributes of the directives, key-value pair, Option
                   "directives":[....] # nested directives,  Option

                }
          ]


          enhance the example:

           "directives":[  
                                  { 
                                        "id":"<ID1 of VNFC>",
                                        "type":"vnfc", 
                                        "directives":[                                    
                                                 {  
                                                    "type":"<flavor_directive>",
                                                    "attributes":[  
                                                       {  
                                                          "attribute_name":"<name of attribute, such as flavor label>",
                                                          "attribute_value":"<value such as cloud specific flavor>"
                                                       }
                                                     ]
                                                 },
                                                 {  
                                                    "type":"<vnic_directive>",
                                                    "attributes":[  
                                                       {  
                                                          "attribute_name":"<name of attribute, such as flavor label>",
                                                          "attribute_value":"<value such as cloud specific flavor>"
                                                       }
                                                     ]
                                                  }
                                            ]
                                     },
                                     { 
                                        "id":"<ID2 of VNFC>",
                                        "type":"vnfc", 
                                        "directives":[    
                                                 {  
                                                    "type":"<flavor_directive>",
                                                    "attributes":[  
                                                       {  
                                                          "attribute_name":"<name of attribute, such as flavor label>",
                                                          "attribute_value":"<value such as cloud specific flavor>"
                                                       }
                                                      ]
                                                 }
                                          ]
                                     },
                                     { 
                                        "id":"<ID of VNF>",
                                        "type":"vnf",
                                        "directives":[  
                                              {  
                                                 "type":"<Name of directive>",
                                                 "attributes":[  
                                                     {  
                                                       "attribute_name":"<name of attribute>",
                                                       "attribute_value":"<value>"
                                                      }
                                                   ]
                                               }
                                         ]
                                      }
                         ]
          1. Hi Maopeng Zhang, one thing here, there could be multiple vdu/vnfc inside 'directives', but there would be only one vnf inside. So it would be better if you add a list for that vdu/vnfc part.

            Thanks.

            1. I give the more VNFC directives examples. Please see the previous examples. If VNFC inside the VNF in future,  we can move the vnfc directives into the VNF directives and do not change the API.

    2. Hi Srini, one question here, as you mentioned that the 'vnf_directives'  part may be used in the future(when affinity and anti-affinity are implemented). What should OOF return inside that block now? Do you mean just leave all the values blank inside?

      Thanks.

      Best Regards,

      Ruoyu

      1. Hi Ruoyu,


        For now, I can't think of any values to be passed back until we have affinity and anti-affinity policies across VNFs in a NS.  So,  you could leave them blank.


        Srini


  2. I think maintaining the opaque pass through is important as Marcus has highlighted. Not sure where the translation to VIM specific calls should be but we don't want to do development on the pipeline between the model and the VIM translation.

    1. Brian Freeman

      Some background : In R2, SO is talking to HEAT service directly.   SO, based on OOF returned data, is interpreting it and populating HEAT parameters/values.  Now, this logic of talking to HEAT service is being moved to Multi-Cloud. So, Multi-Cloud will need to interpret the OOF returned data (which is transparently passed by SO to Multi-Cloud), add HOT parameters/values while making HEAT calls. 

      Yes. we are ensuring that SO is opaque to the data being passed from OOF to Multi-Cloud .

      You mentioned this "we don't want to do development on the pipeline between the model and the VIM translation"

      Can you please elaborate on this comment?

      Srini


  3. Thanks Marcus. It looks good now:-)

  4. Thanks Marcus and All. This is a good proposal and aligns well with other Casablanca Proposals such as Intent-driven placement/realization and the future.

  5. Hi, Marcus Williams

    For completeness, could you also please provide API definitions for

    • Response to infra_worikload request.
    • Request and response to delete the infrastructure workload VNF.
    • Contents of sdnc_directives :  As I understand, sdnc_directives would be filled up by the SO based on information it already has from SDNC.  That is, this is not opaque to the SO.

    Srini

  6. Following up our on discussion on – "Edge Scoping MVP for Casablanca - ONAP Enhancements#ONAPEnhancements-Cloud-agnosticPlacement/Networking&HomingPolicies(Phase1-CasablancaMVP,Phase2-StretchGoal)" please add the following cloud-agnostic intent examples to the spec.

    #
    #Example 1: vCPE, Burstable QoS
    #vCPE: Infrastructure Resource Isolation for VNF with Burstable QoS
    #
       "oof_directives":{
          "directives":[
             {
                "vnfc_directives":[
                   {
                      "vnfc_id":"vgw",
                      "directives":[
                         {
                            "directive_name":"Resource-Isolation-Intent-directive",
                            "attributes":[
                               {
                                  "attribute_name""Infrastructure Resource Isolation for VNF",
                                  "attribute_value""Burstable QoS",
                               },
                               {
                                  "attribute_name""Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage",
                                  "attribute_value""25",
                               },      
     
                            ]
                         },
                      ]
                   },
                ]
             },
           ]
         }
     
     
    #
    #Example 2:
    #vCPE: Infrastructure Resource Isolation for VNF with Guaranteed QoS
    #
       "oof_directives":{
          "directives":[
             {
                "vnfc_directives":[
                   {
                      "vnfc_id":"vgw",
                      "directives":[
                         {
                            "directive_name":"Resource-Isolation-Intent-directive",
                            "attributes":[
                               {
                                  "attribute_name""Infrastructure Resource Isolation for VNF",
                                  "attribute_value""Guaranteed QoS",
                               },
                            ]
                         },
                      ]
                   },
                ]
             },
           ]
         }
     
    #
    #Example 3:
    #vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF with Burstable QoS
    #
       "oof_directives":{
          "directives":[
             {
                "vnfc_directives":[
                   {
                      "vnfc_id":"vdns",
                      "directives":[
                         {
                            "directive_name":"Resource-Isolation-Intent-directive",
                            "attributes":[
                               {
                                  "attribute_name""Infrastructure Resource Isolation for VNF",
                                  "attribute_value""Burstable QoS",
                               },
                               {
                                  "attribute_name""Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage",
                                  "attribute_value""25",
                               },      
                            ]
                         },
                         {
                            "directive_name":"Infrastructure-HA-Intent-directive",
                            "attributes":[
                               {
                                  "attribute_name""Infrastructure High Availability for VNF",                             
                               },
                            ]
                         },
                      ]
                   },
                ]
             },
           ]
         }
     
    #
    # Example 4:
    # vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF
    # with Guaranteed QoS
    #
       "oof_directives":{
          "directives":[
             {
                "vnfc_directives":[
                   {
                      "vnfc_id":"vdns",
                      "directives":[
                         {
                            "directive_name":"Resource-Isolation-Intent-directive",
                            "attributes":[
                               {
                                  "attribute_name""Infrastructure Resource Isolation for VNF",
                                  "attribute_value""Guaranteed QoS",
                               },
                            ]
                         },
                         {
                            "directive_name":"Infrastructure-HA-Intent-directive",
                            "attributes":[
                               {
                                  "attribute_name""Infrastructure High Availability for VNF",                             
                               },
                            ]
     
                         },
                      ]
                   },
                ]
             },
           ]
         }

    1. I think this is more simple and also can support requirement what VF-C without vnfc requirement.
      #Example 1: vCPE, Burstable QoS
      #vCPE: Infrastructure Resource Isolation for VNF with Burstable QoS
      #
         "oof_directives":{
            "directives":[
               {
                  "id":"vgw",

                  "type":"vnfc",

                  "directives":[
                      {
                         "type":"Resource-Isolation-Intent-directive",
                         "attributes":[
                             {
                                 "attribute_name""Infrastructure Resource Isolation for VNF",
                                 "attribute_value""Burstable QoS",
                             },
                             {
                                 "attribute_name""Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage",
                                 "attribute_value""25",
                             },      
                           ]
                      },
                   ]
                },
             ]
          }


  7. Marcus Williams Bin Yang Huang Haibin Victor Morales

    I'm thinking if we could make SO → MultiCloud API more generic, maybe SO pass a csar to MultiCloud could be more suitable for all plugins and we don't need to change SO flow or MultiCloud in the future.

    For openstack plugin, extract the heat template and use it. For k8s plugin, exact the helm templates and use it. For azure plugin, extract ARM templates and use it.



       "generic-vnf-id":"<generic-vnf-id>",
       "vf-module-id":"<vf-module-id>",
       "oof_directives": {},
       "template_type":"<heat/tosca/etc.>",

    "csar_content": "xxx",

    }
     
     

    1. Hi Ethan (Ethan Lynn)

      This API is generic enough. It passes "generic vnf id" and "vf module id". Using this, one can get the artifact templates from the SDC if needed.

      HEAT is passed as immediate data (in case of HEAT) to keep the existing API work as is. This can be removed (may be in Dublin).

      Srini