Date of merge: 9-Sep-2017

Change Management Requests

New VNF Update and VNF Replace requests/flows were implemented.  Both include policy-controlled error handling logic using the rainy day building block and manual tasks. Both include pre/post checks on a per vnf basis to do healthchecks/vnf lifecycle operations as supported by APP-C, offload traffic, etc. as needed.

VNF Update

• Supported at the vnf level.

• Can change only the openstack image, not vfModule assignments or structure.

• When VID sends a vnf level (macro-like) update request, SO will attempt to update EACH vfModule child for that vnf as represented in A&AI inventory (base vfModule first, then addons in any order).

• Functionally like a delete and rebuild.

• Supported at the vnf level.

• Could be done to perform a software upgrade (openstack image change) or to re-build the vnf’s vfModules using the existing image.

• When VID sends a vnf level (macro-like) replace request, SO will attempt to replace EACH vfModule child for that vnf as represented in A&AI inventory. SO will delete any addon vfModules first, then delete the base module last, however the ECOMP provided assignments will be retained and will be re-used on the subsequent “create”.  SO will then create the base vfModule first, then addons in any order.  If so desired by VID user, any associated volumeGroups for each vfModule could be re-built as well (assumed not typically desired since volumeGroups are used to store persistent data).

VNF Replace

• Functionally like a delete and rebuild.

• Supported at the vnf level.

• Could be done to perform a software upgrade (openstack image change) or to re-build the vnf’s vfModules using the existing image.

• When VID sends a vnf level (macro-like) replace request, SO will attempt to replace EACH vfModule child for that vnf as represented in A&AI inventory. SO will delete any addon vfModules first, then delete the base module last, however the ECOMP provided assignments will be retained and will be re-used on the subsequent “create”.  SO will then create the base vfModule first, then addons in any order.  If so desired by VID user, any associated volumeGroups for each vfModule could be re-built as well (assumed not typically desired since volumeGroups are used to store persistent data).

Error Handling for VNF Update and VNF Replace

If a failure is hit during the above flows, policy is consulted. If no policy is found, or if the policy states to perform manual handling, then a manual task is created in Camunda.  The VID user can search for and respond to manual tasks.  VID uses a new API exposed by the infrastructure API Handler for this).  The user can respond with directives: “skip”, “abort”, “retry”, or “rollback”.

Published v5 infrastructure service instantiation API

• Added new REST vnf requests to support change management actions for update (aka upgrade) and replace (aka delete and rebuild).

• Added the /replace command as an operation for a vnf instance.

• Indicated that instanceName cannot be changed on a replace.

• Indicated for a REPLACE, when modelType = vnf,  VID must send modelCustomizationName and/or modelCustomizationId.

• Indicated usePreload as optional for a vnf update/replace request.

• Updated the relatedInstance common data structure to note it is mandatory for replace requests and also updated the note for relatedInstance.modelInfo to indicate when VID should supply modelInfo for the existing service model vs. new service model, depending on request type.

• Added Boolean requestParameter.replaceVolumeGroups so VID user can indicate if volumeGroup(s) should be preserved or not during a vnf replace request.

• Added serviceInstance activate/deactivate requests (commands/actions)

• Updated the logic MSO will use to lookup recipes depending on the presence (or not) of the aLaCarte flag on serviceInstance requests.

• Added new MSOManualTask API requests to support manual tasks (GET and POST) completion via the rainy day building block.

• Added ‘requestExecutionDate’ as a filter param for a GET orchestrationRequest query.

Consumption of TOSCA Model from SDC

When SO receives a distribution notification from SDC, it determines if the service model has already been imported, as follows:

1. Within the notification json, extract the serviceUUID value and query SO’s service table by MODEL_UUID.  If there is a match then ignore the distribution.  If no match then proceed.

2. Within the notification json, extract the artifactUUID of the “TOSCA_CSAR” artifactType entry within the serviceArtifacts list and use the value to query the tosca_csar catalog table by artifact_uuid.  If a match is found, proceed with the distribution, but return indication that the artifact has already been downloaded (if possible), or at least write a debug log indicating such.  It is unclear if a tosca_csar can or will contain more than one service model in it (most likely not, currently), however to cover that potential case we should not fail/ignore the distribution if we DON’T have the service table record, but DO already have the tosca_csar table record.

When a distribution is to be processed, the following is expected from SO after downloading the TOSCA_CSAR artifact:

• Initiate the parser with the CSAR.  The ASDC Controller logic in SO was changed to use the TOSCA parsing library provided by SDC.

• If the parser returns an “Old Model” error indication, MSO should fallback to use the 1702 processing approach.

• If the parser successfully returns the TOSCA model instance, SO shall retrieve the TOSCA information by using the parser model call functions.

• When working with parser, MSO shall use the new namespaces (“org.openecomp”).

After invoking the TOSCA parser and being returned a model, when processing networks from TOSCA, i.e. network node_templates (metadata.type = VL):

• If properties.provider_network.is_provider_network = true, set network_resource.neutron_network_type = PROVIDER, else set to BASIC.

TOSCA (and thus the parser) will not return the artifacts list for a vfModule.  SO still downloads the VF_MODULES_METADATA artifact per the distribution notification as done in 1702.  But now, SO will combine the information about the vfModule returned from the TOSCA parser with its list of artifacts retrieved (and then downloaded) from VF_MODULES_METADATA.  The resulting combination is inserted into the catalog DB.

An artifactVersion property value is no longer required in an artifact’s metadata.. If it is present, the appropriate heat_* catalog table is populated with the value in the VERSION column, but it is not an error if not present.

ASDC Controller “Copy Down” Logic

The existing “copy-down” logic for service_recipe records was changed to accommodate updated foreign key column names and data type in that table.

New “copy-down” logic was added for custom vnf_components_recipe records (similar to the logic for service_recipe records).  Meaning, at distribution time, for every vfModule in the distributed service, verify if there are any pre-existing custom recipe record(s) in the vnf_components_recipe table (that apply to the same vfModuleModelInvariantUUID for the vfModule being imported).  If there are, duplicate them and associate them with the newly distributed vfModuleModelUUID.

ASDC Controller Support for new Service Metadata Fields

The ASDC Controller now extracts the serviceType and serviceRole metadata fields and populates their values into service_type and service_role columns in the service table.

Catalog DB Schema Change

The catalog DB required significant change to support TOSCA model consumption.  This change provided an opportunity for refactoring to better align the schema with the SDC model. The work effort included table changes/consolidation along with renaming of columns across tables to gain consistency.  Additionally primary keys were changed to move away from use of internal INT id columns toward the use of the SDC UUIDs themselves.  This eliminated a level of indirection and will be a benefit to future implementation of DB replication cross-site and Active/Active setup (because the UUIDs should be globally unique).  Also, to enforce data/referential integrity, foreign keys were used where possible.  A consistent naming approach for foreign keys and indexes was implemented.

Another goal of the refactoring was to eliminate DB storage of the historical *type fields (network-type, vnf-type, vf-module-type).  SO Code should be utilizing modelCustomizationIds (or other model information params) to perform model lookups.  Note that there is still a network_type column in the DB; however its source is the SDC TOSCA model property and is not synonymous with SO's previous "internal" network_type (e.g. CONTRAIL30_BASIC).  SO’s previous network_type value is now equivalent to the network (aka VL in SDC) modelName values.  To support distribution of networks (VLs) from SDC, a lookup table (temp_network_heat_template_lookup) was introduced.  Its function is to match a network resource model to its heat template since SDC does not distribute network heat templates to SO.  This means the lookup table must be populated prior to SDC distribution of a new network (VL).

The uniqueness constraint on the vnf_components_recipe table was changed to not include vnf_type or service_type, and made version not null.

DB table columns were generally reordered to match our mysql model to facilitate easier auto-generation of SQL in the future.

Because the schema changes were extensive, and because of the way legacy service models were stored (or not) within SO, and because legacy models from SDC lacked modelCustomizationIds, a data migration script was required.  The script generates modelCustomizationIDs for existing catalog data if they are missing.

Supporting Documents:

• MySQL Workbench file: ONAP_SO_Catalog_DB_1710.mwb

• A table/column mapping spreadsheet: ONAP_SO_CatalogDB_Refactoring_column_mapping.xlsx

SO code libraries to interface with other ONAP components

Initial implementation of Java libraries to facilitate call-outs to A&AI, Policy, APP-C, SDN-C and SDN-O from BPMN flows.

Support for WAN Transport (SDN-W)

DoCreateServiceInstance Building Block

This building block flow was enhanced to support the creation of a WAN transport service instance, as follows:

1. Input Parameters

   1. The service decomposition object is passed as an input, replacing individual decomposition parameters.

   2. The new serviceInputParams input is a block of all user parameters extracted from requestParameters.userParams.

2. Create service instance
   
   

   1. Get customer and service subscription in A&AI. Raise exception if service instance already exists - unchanged.

   2. Create service instance id in A&AI. Include the following input parameters:  service-instance-name (optional), service-type, service-role, and orchestration-status = Created.

3. Call SDN-X to create service instance:
   
   

   1. Call SDN controller service-topology-operation with request-action = CreateServiceInstance and svc-action = “assign” using generic-resource API.

   2. Route the service instance creation request to SDN-W if service-type = “TRANSPORT” using the SDN-W end-point route / URL. The building block will pass the service-type value in the msoAction field in the adapter.

   3. Pass the AIC zone in userParams to SDN-W in service-input-paramete

DoDeleteServiceInstance Building Block

This building block flow was enhanced to support the deletion of a WAN transport service instance, as follows:

1. Input Parameters

   1. The new serviceInputParams input is a block of all user parameters extracted from requestParameters.userParams.

2. Get Service:  unchanged.

3. Post Processing:

   1. Check that there are no children and no relationships for the service instance, and return an error if any are found. This will be generic logic that will apply to all service types.

   2. Get service-instance service-type.

4. Decision Steps:
   
   

   1. If the service-type = “TRANSPORT” and orchestration-status = PendingDelete then skip the SDN deactivate step and only do the SDN delete step.

   2. If the service-type = “TRANSPORT” and orchestration-status ≠ PendingDelete then return error. It is expected that this validation will also be performed by SDN-W.

5. Call SDN-X to Delete Service:
   
   

   1. Call SDN-W service-topology-operation with request-action = DeleteServiceInstance and svc-action = “delete” as per SDN-C generic-resource API. Route the service instance deletion request to SDN-W if service-type value = “TRANSPORT” using the SDN-W end-point route / URL. The building block will pass the service-type value in the msoAction field in the adapter.

6. Delete the service instance in A&AI: unchanged.

Decomposition Building Block

This building block flow Building reads TOSCA model data stored in the catalog DB and creates a decomposition object that can drive a workflow.

Homing Building Block

This building block flow uses SNIRO’s new service agnostic API to perform homing on resources stored in the workflow decomposition object.

Rainy Day and Manual Handling Building Blocks

The new Rainy Day Building Block flow calls Policy to determine an action for an error.  If policy is absent, or if the policy specifies manual action, the Manual Handling Building Block is invoked.  The Manual Handling Building Block suspends the flow until a VID user inputs a directive to resume the flow, one of: “skip”, “abort”, “retry”, or “rollback”.

Swagger Output