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.
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
17 Comments
Srinivasa Addepalli
Marcus Williams, ramki krishnan, Bin Yang, Huang Haibin, Ruoyu Ying, Dileep Ranganathan, Ethan Lynn
I want to provide my 2 cents, keeping multiple VNFCs in mind and future extensibility in mind.
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
Marcus Williams
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.
Srinivasa Addepalli
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 Ying, Dileep Ranganathan and Huang Haibin, Since you are developers involved in this, can this be proposed to your respective teams and also update JIRA?
Srini
maopeng zhang
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>" } ] } ] } ]Ruoyu Ying
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.
maopeng zhang
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.
Ruoyu Ying
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
Srinivasa Addepalli
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
Brian Freeman
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.
Srinivasa Addepalli
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
Srinivasa Addepalli
Thanks Marcus. It looks good now:-)
ramki krishnan
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.
Srinivasa Addepalli
Hi, Marcus Williams
For completeness, could you also please provide API definitions for
Srini
ramki krishnan
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",},]},]},]},]}Huang Haibin
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",},]},]},]}Ethan Lynn
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",
}
Srinivasa Addepalli
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