Feature Contributions

Change two-phased-design to multi-stage-design

Two-phased-design support for VF module creation needs to be changed to multi-stage-design.

Port Mirror

The BPMN flows for this feature are AT&T proprietary, but infrastructure enhancements were made to support the feature.  Only the infrastructure enhancements are listed here.  If the Port Mirror feature is to be supported in ONAP, then the AT&T proprietary flows will need to be moved into ONAP.

Accept ‘Create Port Mirror Configuration’ a la Carte request for pProbes from VID

The MSO-VID interface (APIH) shall enhance the existing a la carte create ‘Port Mirror Configuration’ request to support pProbe:

1. For creation of the Port Mirror Configuration resource the following information is expected from VID in the createPortMirrorConfiguration API:
                      POST ../serviceInstances/{id}/configurations
   1. Model Info: the ‘Configuration’ model info.
   2. Cloud Configuration: the ‘Cloud Region Id’ (Required by SDN-C)
   3. Request Info:
      1. Configuration instanceName (mandatory) – assumed to be unique
   4. Related Instances:
      1. The pProbe Port Mirror service instance id
      2. The source vnf id
      3. The destination C4500 pProbe pnf name. Note: PNF does not have model information, VID is to add modelType = “pnf”
      4. The instance direction (enum: source, destination)
2. APIH will validate and capture request, and trigger a generic a la carte “aLaCarteOrchestrator” recipe.
3. APIH will return to VID a synchronous 202 success response with request id and configuration id.
4. In case of error the MSO interface will return VID a synchronous 4xx/5xx error message.

Assumptions:

The pProbe Port Mirroring Service Instance already created and exists in A&AI.

New parameters in creation of Contrail Network Instance

Verify that MSO is sending statuses to A&AI after the creation of Contrail Network VM Instance, so that A&AI is aware of the status.

This is currently a BAU Process where MSO sends the status after communicating with AIC through the HEAT for Contrail Network instantiation.

MSO initiates the acknowledgement to A&AI through "Add Network Instance ()" API.

This existing process must remain as BAU after the addition of these new parameters to the HEAT template.

7/25/2017 - This was discussed with MSO, SDNC, A&AI, IPSD, and IPDD SEs.

Tenant Isolation Phase 1

As part of tenant isolation, MSO shall support additional metadata attributes to help identify non-revenue generating tenants from revenue-generating tenants, and write them to A&AI during service instance create.

Scope:

Only required on new service model (Existing services will not be upgraded/migrated)

Affects macro infrastructure flows and a-la-carte service instance create flows.

MSO will accept two new attributes from ASDC in TOSCA for service models.

MSO will send two attributes to A&AI through existing interface.

MSO will pass the two new attributes to heat as metadata params for a OS::Nova::Server (VM) resource.

Details:

There is a need to combine production (i.e. revenue generating) services as well as dev/test (i.e. non-revenue generating) services within the same production AIC zone, and no longer have dedicated test labs. But if this is to be done, there needs to be a way to differentiate the revenue generating from the non-revenue generating services. This will be accomplished with the notion of tenant isolation and three context attributes:

1. Environment Context: Identifies the scope of the service model (Sample Values: General_Revenue-Bearing ->default; Critical_Revenue-Bearing; Critical_Non-Revenue)
2. Workload Context: Identifies the purpose of the isolated area in AIC. (The value will be instance-specific)
3. Tenant Context: Identifier for the tenant; whether it will be used for PROD, TEST, DEV (MSO will not be sent this value as AIC knows it at run-time)

Tenant Isolation Phase 2 – VNF Operational Environments

MSO will support creating non-production ECOMP and VNF operational environments so that non-production ECOMP and VNF operational environments can be utilized for IST and E2E testing.  This solution will isolate production VNFs from VNFs used for testing. Each VNF is managed by an ECOMP environment, which will be manually deployed.

Assumptions:

1. Upstream applications allow only valid context/operational environment combinations, therefore MSO will never receive an invalid combination (i.e. There will not be a "TEST" workload for a "PROD" tenant).
2. This project will be enhancing the existing manual processes for registering the endpoints via the GUI or a script; there are future discussions for automation that haven't fully materialized yet.
3. MSO operational environments will be able to communicate with the Endpoint Registry, SOA Cloud - GRM.

Dependencies:

1. Tenant Isolation - Phase 1
2. New A&AI interface to retrieve the Managing ECOMP Operational Environment parameters based on an ECOMP UUID.
3. New A&AI interface to store the VNF Operational Environment and environment parameters.
4. SOA Cloud - GRM interface to lookup Managing ECOMP Endpoint list in the Endpoint Registry.
5. SOA Cloud - GRM interface to create entries in the Endpoint Registry so that VNF Operational Environment will map to Managing ECOMP Endpoint(s).
6. DMaaP Topic to allow MSO to publish new Managing ECOMP Operational Environment for ASDC to consume.

Flows:

Create Managing ECOMP Operational Environment (executed when the MSO element operationalEnvrionmentType = 'ECOMP')

1. Operations Manager (Human) manually calls MSO to post the Managing ECOMP Operational Environment. MSO responds with a '202' (request successfully received).
2. MSO calls A&AI to store the Managing ECOMP Operational Environment object.
3. MSO publishes ECOMP Operational Environment and context to DMaaP.

Create Non-Production VNF Operational Environment (executed when the MSO element operationalEnvrionmentType = 'VNF')

1. VID calls MSO to post the VNF Operational Environment. MSO responds with a '202' (request successfully received).
2. MSO calls A&AI to retrieve the Managing ECOMP Operational Environment parameters based on an Operational Environment ID.
3. MSO calls SOA Cloud - GRM to lookup Managing ECOMP Endpoint list in the Endpoint Registry.
4. MSO calls SOA Cloud - GRM to create entries in Endpoint Registry so that VNF Operational Environment will map to Managing ECOMP Endpoint(s).
5. MSO calls A&AI to store the VNF Operational Environment and environment parameters.
6. VID retrieves status from MSO. Refer to Story 465816.

Technical Impacts:

1. Create a MSO API with VID to accept receiving a newly created Managing ECOMP Operational Environment or newly created Non-Production VNF Operational Environment.
2. Onboard to a new A&AI interface to retrieve the Managing ECOMP Operational Environment parameters based on an Operational Environment ID.
3. Onboard to an existing SOA Cloud - GRM interface to lookup Managing ECOMP Endpoint list in the Endpoint Registry.
4. Onboard to an existing SOA Cloud - GRM library to create entries in Endpoint Registry so that a VNF Operational Environment will map to Managing ECOMP Endpoint(s).
5. Onboard to a new A&AI interface to store the VNF Operational Environment and environment parameters.
6. Publish Managing ECOMP Operational Environment and context to DMaaP for ASDC consumption.

Tenant Isolation – Watchdog Process

MSO shall create the Deployment Management Workflow (a.k.a Watchdog process), so that it can monitor the Distribution of each Service Model Version IDs on a component basis to Non-Production Environments.

The watchdog process must be active all the time for each Service Model Version UID available on the Operational Environment Activation Request from VID.

Interface Impacts:

MSO -> DMaaP (Publish, Subscribe)

MSO -> A&AI (REST PUT)

Tenant Isolation – Deactivate Non-Prod Operational Environment

MSO must be able to process deactivation of Operational Environment requests from VID. Upon receiving deactivation requests from VID, MSO must be able to deactivate the Operational Environment by sending requests to A&AI.

Request Flow:

VID --> MSO --> A&AI

Interface Impacts:

VID - MSO (REST POST)

MSO - A&AI (REST GET)

MSO - A&AI (REST PUT)

Tenant Isolation – Distributing Contexts to Non Production Environment

MSO must be able to trigger ASDC to distribute Service Model Versions to different eCOMP instances and keep track of the statuses.  VID users must be activating an Operational Environment by using MSO interfaces. MSO must be invoking ASDC to distribute service model Versions based on the request from VID.

Request Flow:

VID --> MSO --> ASDC

Interface Impacts:

VID - MSO (REST POST)

MSO - A&AI (REST GET)

MSO - ASDC (REST POST)

Tenant Isolation – GRM Rest Client

MSO needs a new GRM Client to invoke GRM rest call to find running services and add new service endpoints.  The client will send REST POST call to GRM to retrieve running service given a name and add new endpoints.

Change Management - Agnostic VNF configuration update

MSO must be able to modify a VNF configuration by scheduling execution of a Configuration Change Workflow from VID by specifying key-value pairs, each consisting of a configuration item to be updated and the updated value. Ability to select the instances of VNF to update based on VNF type and/or customer, and all inputs required for scheduling and conflict avoidance (covered in another feature). This is a VNF agnostic workflow and requires an Ansible playbook, Chef cookbook, or Netconf to support the configuration update. Impacts all VNF, VID, MSO, Controllers, vendor provided Ansible/Chef/Netconf.

Upon receiving the vnfConfigUpdate request from VID, MSO orchestrates the updating of the VNF software configuration key-value pairs included in the request.

If other systems return failures in workflow steps, the BAU rainy day handling flow is executed with appropriate available options (from skip, abort, retry, or rollback) and a vTM ticket is opened to allow operations to continue or abort the flow as requested.

Technical Solution:

The in place software update flow is initiated by receipt of the new Service Instantiation API request, vnfConfigUpdateAlso See attached AID changes document for API changes. The request payload includes JSON content that MSO will pass to APP-C (and that APP-C will pass to the VNF chef or ansible server.

MSO will call the APP-C ConfigModify request to make the required configuration changes to the VNF.

The LCM ConfigModify action modifies the configuration of a VNF.

Part of the MSO implementation includes a refactoring of the APP-C client library (REST client).

Change Management - Agnostic VNF In-Place Software Update

MSO shall have the ability to update the software on a VNF while leaving all VNF resources in place by draining the traffic, shutting the VNF down and updating software, then re-starting the VNF and re-establishing the traffic. Execution is scheduled from VID by specifying the previous VNF version to update from, the new VNF version to update to, the ability to select the instances of VNF to update based on VNF type and/or customer, and all inputs required for scheduling and conflict avoidance (covered in another feature). This is a VNF agnostic workflow and requires an Ansible playbook or Chef cookbook or Netconf script to support the configuration update. Impacts all VNF, VID, MSO, Controllers, vendor provided Ansible/Chef/Netconf.

Technical Solution:

1. Call A&AI custom query to check pServer in-maintenance flags for VNF
2. Call A&AI to check and set VF In Maintenance flag
3. Call A&AI to check and set VF is-closed-loop-disabled flag
4. Call App-C VNF lock request
5. Call APP-C UpgradePreCheck (New for 1802)
6. Call APP-C QuiesceTraffic request (New for 1802)
7. Call APP-C SnapShot for each VM in the VNF (Creates a snapshot of a VM in AIC) (New for 1802)
8. Call APP-C UpgradeBackup (Performs a full backup of the VNF data prior to an upgrade) (New for 1802)
9. Call APP-C UpgradeSoftware request (New for 1802)
10. Call APP-C UpgradePostCheck request (New for 1802)
11. Call APP-C ResumeTraffic (New for 1802)
12. Call App-C VNF unlock request
13. Call A&AI to unset VF In Maintenance flag
14. Call A&AI to unset VF is-closed-loop-disabled flag

Change Management - AAI interface updates for Configuration Management flows

AAI interface updates for CM flows to check flags, specifically the Closed Loop flag

Change Management - Add A&AI Query at start of Configuration Management flows

Adds an A&AI query for VNF info at the start of CM flows. For Update and Replace this will retrieve vnfName info that may or may not come on the request otherwise, and for others this will replace the Catalog query.

VNF Pause and Reporting

VNF Pause and Reporting allows for a VNF to be paused during instantiate after VM names and IP addresses are obtained. SDN-C will write the assignments into A&AI inventory with an in-progress status. MSO will create a workflow exception of which the only option is to resume. This allows operations to perform other work such as firewall access requests or adding new SB/C VNF’s to resilient pools and such.

Refactor ReplaceVnfinfra Flow

The Replace VNF Infra flow needs to be refactored and cleaned up with retry logic and AppCClient subflow calls added.

Refactor UpdateVnfinfra Flow

The Update VNF Infra flow needs to be refactored and cleaned up with retry logic and AppCClient subflow calls added.

Add & Remove PNF Relationships to/from Parent Physical Probe (pProbe) Service Instance

MSO shall orchestrate the addition (or removal) of relationships of Physical Probe PNF resource instances to the parent Physical Probe service-instance in A&AI initiated by a VID a-la-carte request.

VID will retrieve a list of Physical Probe (pProbe) PNFs associated with the selected Cloud Region from A&AI and present this to the User. The User selects a set of PNFs and sends a request to add (associate) or remove these pProbe PNFs to the parent pProbe Service Instance in A&AI. For each pProbe PNF, MSO will create a relationship to the parent pProbe Service Instance.

The pProbe service-instance and pProbe resources (Cisco C4500, APCON Packet Broker, and Tektronix G10 PNFs) need to be successfully instantiated in A&AI before the VID user will attempt this action.

Flow:

1. MSO will receive and process a VID request to add or remove relationships of a given list of resources to a service instance, and trigger an a la carte recipe and sub-flow.
2. The MSO generic a-la-carte recipe and sub-flow will:
   1. Query A&AI to get service instance and all topology.
   2. For each PNF instance in the PNF list, add or remove (action type dependent) relationship to the parent service-instance in A&AI.

Assumptions:

1. The pProbe service-instance need to be successfully instantiated in A&AI before the VID user will attempt this action.
2. The pProbe resource instances (Cisco C4500, APCON Packet Broker, and Tektronix G10 PNFs) need to be successfully instantiated in A&AI before the VID user will attempt this action.

Support AllowableTreatments Policy Query

MSO must include support for AllowableTreatments query of Policy dictionary and integrate this query into Rainy Day Handling mechanism.

Update AllowedTreatments.java:

                with correct response payload information from Policy

Update PolicyClientImpl.java:

                to remove generateDictionaryJson method

                to update getAllowedTreatments method with correct setDictionary field

Update PolicyClientImplTest.java:

with correct unit test for getAllowedTreatments

Retain VM names after failed instantiations

MSO must modify the behavior associated with any failure that occurs AFTER a successful SDN-C assignment on an ala carte create request of a vf module (this is regardless to whether the instantiation used automated assignments or a preload worksheet).

After successful SDN-C assignment, MSO shall set vf-module.orchestration-status to “Assigned” (or “PendingActivation” for a multi-stage-design VNF). Subsequent to that, if there is a failure and MSO has already successfully created the stack in AIC, MSO shall still do a rollback in AIC, but instead of also rolling back resources in SDN-C/A&AI as happens today, MSO will ensure the A&AI orchestration-status of the vf-module is “Assigned” (or “PendingActivation” for a multi-stage-design VNF), clear the heat-stack-id value, and end the flow there.

If the VID user sends a subsequent create request (with exact same vfModule name), MSO’s DoCreateVfModule building block will treat this new request similar to the current pause/resume approach in that the building block will query A&AI and if the orchestration-status is “Assigned” (or “PendingActivation” for pause/resume), it will skip the SDN-C assign step and proceed with querying SDN-C for the existing assignments, creating stack in AIC, and activating vfModule in SDN-C.

If the VID user decides to release the current assignments (in EIPAM case), they can send a Delete vfModule request to MSO. MSO’s DoDeleteVfModule building block will check in A&AI if the vf-module’s orchestration-status is set to “Assigned” or “PendingActivation”, and if so, will skip calling vnf adapter to delete the heat stack (since stack will not exist and we don’t support silent success currently), and will execute all other existing steps in the flow (e.g. send a disconnect to SDN-C to “deactivate/unassign” – this uses vnf-api currently so there is no separate deactivate and unassign requests).

Refactor the MsoRequest.java parse method

Refactored the request validation logic in the API Handler and implemented unit tests to improve coverage.

REST Clients will support custom properties configuration

Allows applications to specify custom properties to REST clients.

REST Clients will add HTTP header information to the log

Add logging of request and response headers.

Relocate Java client source code

Move all Java clients from the "MSOCommonBPMN" project to the "common" project.

AAI Client - Add ALLOTTED-RESOURCE to AAIObjectType

URI template = "serviceinstance uri" + "/allotted-resources/allotted-resource/${id}

AAI Client - Allow Delete Relationship

A&AI offers the ability to delete specific relationships by issuing a delete request with a payload.

AAI Client - Add Search-around functionality

MSO frequently needs to look at details about items in the relationship-list from A&AI. The A&AI client library will offer functionality to easily issue HTTP get requests on related-link objects.

AAI Client - Allow generic parsing of related-links into AAIUri objects

Expose functionality to retrieve related links.

Remove related link type from AAIObjectType.

A simple URI can be initialized from an existing URI.

Relationships can generically parse relationship.

AAI Client - Add JavaDoc comments

AAI Client - Add PNF to AAIObjectType

URI template = /network/pnfs/pnf/ {pnf-name}

AAI Client - Support Bulk Process API

A&AI has a bulk process API which allows clients to request modifications to succeed or fail as a group.

AAI Client - Create Bean for Operational-Environment

A bean will be created for the operational-environment object in A&AI.  You can use http://www.jsonschema2pojo.org/ annotation style Jackson 2.x, generate builder methods, use double numbers, include getters and setters, initialize collections.

AAI Client - Add method to AAIObjectType to retrieve lower-hyphen case

AAIObjectType name is converted to lower hyphen case.

Types that are partially filled in starting with "DEFAULT_" will have that prefix removed.

AAI Client - Convert A&AI Clients to Version Enum

Rather than writing "v12", "v10", "9", etc. when selecting versions in A&AI it will be an enum to prevent formatting mistakes.    The enum will contain a LATEST keyword which is always equal to the largest ordinal value in the enum.

AAI Client - Add depth support to Relationship Object gets

Added the ability to control depth on Relationship gets.

AAI Client - Add CLOUD_REGION to AAIObjectType

URI template = /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner-id}/{cloud-region-id}

AAI Client - Add TENANT to AAIObjectType

URI template = CLOUD_REGION.toString() + "/tenants/tenant/{tenant-id}"

AAI Client - AAIObjectType Polymorphism

AAIObjectType seems like the best place to include the name, URI, and basic information about each AAIObject.  The enum will implement multiple interfaces allowing access to:

1. Name, as used in some of the query outputs (lower-hyphen case)
2. Full URI template
3. Partial uri template - the segment of the uri that applies to this specific object e.g. /service-instances/service-instance/ {service-instance-id}

(rather than the full URI containing global-customer-id and service-type)

AAI Client – Add related-to functionality to AAIUri

A&AI has a feature which allows the user to specify a traversal to any object connected via a relationship from within a URI. For example,

.../service-instances/service-instance/my-service-instance-id/related-to/generic-vnfs

result: a list of all generic-vnfs connected to that service instance

You can chain related-to traversals as long as you specify a key:

.../service-instances/service-instance/my-service-instance-id/related-to/generic-vnfs/generic-vnf/my-vnf-id/related-to/vservers

AAI Client - Divide AAIUri into multiple interfaces

There are many different kinds of AAIUris - query, resource, search, etc. Each URI has different uses and query params. They will treated separately.

AAI Client - Improve error message handling

Include the request-id for the request that failed.

Include a statement that the error comes from A&AI

Include the full error message from A&AI

Include all failure messages found during a transaction to A&AI

AAI Client - Add serviceType to AAIObjectType enums

Add Service Type to the list of Enums

AAI Client – Support for service-model

The URI template will be:

/service-design-and-creation/models/model/{model-invariant-id}/model-vers/model-ver/{model-version-id}

APPC Client – Create simple orchestrator for APPC Client

The groovy interaction with our app-c client is not where we would like it to be. There are too many objects and custom steps required to use the app-c client MSO wrote. The orchestrator will serve to simplify and streamline the interaction between the app-c client and groovy.

The first case the orchestrator will handle revolves around vnfIds.

APPC Client – Configuration properties enhancement

Read properties in ApplicationControllerClient.java.

Updated mso.bpmn.urn.properties.

Policy Client – Logging Filter will notify on Transfer-Encoding=chunked

HTTP GET requests which have Transfer-Encoding=chunked do not include a Content-Length. This breaks the way our Logging filter writes out the entity body. Rather than having a broken line, our logging filter will write out a custom message.

Policy Client – Allow implementers to turn off LoggingFilter

Some client implementations may not want to use the LoggingFilter.

Policy Client – Logging Filter will allow a customize-able max entity size

Clients may want to specify a custom max entity size in order to display entire payloads.

Policy Client – Improve logging

REST client outputs the URI it is calling.

REST client outputs the URI it received a payload from.

DMaaP Client – Improve Logging

DMaaP client will log to the MSO audit logger

DMaaP Client – Consumer must poll for X minutes

The way DMaaP works is that when issuing a get the client only waits long enough to receive a message. If you count retries you may not end up waiting a set number of minutes. For example:

Poll 1: wait 5 seconds message received, not related

Poll 2: wait 20 seconds nothing found

Poll 3: wait .5 seconds 20 messages received, message found

Total: 25.5 seconds of polling

Example 2: Maximum Poll = 20

Polls 1-19: receive messages every .1 seconds

Polls 20: Wait 20 seconds nothing found

Stop processing - failure

Total 21.9 seconds of polling

Number of polling attempts is not a valid metric for stopping processing.

DMaaP Client – Consumer will log full response messages

Add logging statement for message received from fetch method.

DMaaP Client – Configurable properties loader

Allow DMaaP Client have a configurable properties loader.  The DMaaP Client loads the properties implementation via SPI.

SDNO Client - Add more descriptive exception message

BMPN only prints out the exception message and not the stack trace. The exception messages must be more descriptive for debugging purposes.

New SDNC Client Library

We want to improve the interface between MSO and the SDNCAdapter. There are too many places where the groovy scripts are creating and manipulating raw XML to send to the Adapter.

REST Clients for Network/Vnf/Requests Adapters

This story is in support of refactored building blocks.  It adds Java client libraries for interfacing with the Network Adapter, VNF Adapter, and Requests DB Adapter.

JsonPathUtil will return complex values as Strings

Return complex JSON objects as strings, i.e. keys that map to other JSON objects will be returned as string representations.

Refactor DoCreateServiceInstance BPMN Flow using new client libraries

A new version of the DoCreateServiceInstance flow shall be written which utilizes the new Java client libraries and Java Delegates in place of groovy scripting.

Decomposition and Homing Enhancements

Updated Homing Building Block to support SNIRO 1712 changes and refactored licensing part of homingSolution.

Added vnf object to solution class, added heatStackId to vf module class.

Added vnfHostname to vnf resource class.

Added in existingSolution to SNIRO API.

Extract and store the rehome status from SNRO homing solution response.

Updates to homing and decomposition objects to fulfill new Building Block requirements.

Add allowableTreatments policy call to Manual Handler Building Block

Includes a default policy decision setting for the Manual Handling building block.

Integrates with the Rainy Day Handling building block.

Default Policy Disposition for the Rainy Day Building Block

Implement Default Policy Disposition for the Rainy Day Handler that can be configured through a properties file instead of going to the Policy server.

Create Ruby ticket via DMaaP

Implement the capability to send a trouble ticket to the Ruby system from the Manual Handling Building Block.

Add new API-H serverRoot and rev API version to v6 for all endpoints

The serverRoot has been changed in v6 to /onap/so/infra (however the old serverRoot should still work for v4/v5).

Additionally all endpoints in the API should be revved to v6.

Remove old v1-v3 "infra portal" API and BPMNs

The old "infra portal" API was for AIC murano/infra portal to send to for infra orchestration, but they never officially sent to it. ECOMP Ops did manually send via soapUI originally. It should not be getting used anymore (we've had it disabled via APIH config for at least a release or two). ECOMP Ops have assured they are not using it anymore. The old code paths can be removed from infra APIH and any BPMNs specific to that pathway.

Reduce JsonUtils Logging

A substantial amount of debug logging was added to the JsonUtils class when it was initially developed to ensure the correct behavior of the utility methods. As the utility has been used more widely across MSO, this has led to excessive content in the debug log during testing. Some of this logging is no longer needed and can be disabled.

Also, a JSONException can occur when an attribute is not found in a JSON document. There is no point to print the entire stack trace when this happens. The logic should be modified to handle this and reduce the debug logging in this case.

Support for interim notifications

Create an SDNCAdapterRestV2 flow which allows interim notifications to be sent.

Add Catalog DB Adapter unit tests

Create unit tests for mso-catalog-db-adapter project. This includes adding a new test subproject as well as adding junit code to test business logic for classes, methods, and properties.

Add API-Handler unit tests

Create Unit test cases for the API handler packages.

Add Network Adapter unit tests

Create unit tests for mso-network-adapter and mso-network-adapter-async-client projects

TOSCA adapter Proof-of-Concept

Merge the TOSCA adapter POC into MSO.

Bug Fixes