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.
ITRACK | TYPE | DESCRIPTION |
MSO-288 | Story | Add support for multiStageDesign field in ServiceDecomposition |
MSO-290 | Story | Change two-phased-design 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.
ITRACK | TYPE | DESCRIPTION |
MSO-12 | Story | Update A&AI Library to Support Creation/Deletion of PortConfiguration Objects |
MSO-24 | Story | Update SDNO Library |
MSO-11 | Story | Create a new BPMN Flow to Create Port Mirror Configuration |
MSO-172 | Story | Update Requests DB for Port Mirroring Configuration requests |
MSO-100 | Story | create Resource type object for Configuration |
MSO-13 | Story | Update SDNC Adapter to Support New Port Configuration Requests |
MSO-23 | Story | Modify DoCreateService Instance BPMN Flow |
MSO-203 | Story | Create interface for BPMN to issue custom health check |
MSO-204 | Story | Create interface for BPMN to issue custom l port health check |
MSO-247 | Story | Enhance ‘Create Service Instance’ a la Carte Recipe for Port Mirroring to Enable SDN-C Access |
MSO-10 | Story | Update API Handler to Accept the New Port Configuration Request |
MSO-115 | Story | Update API Handler to Accept the New Port Configuration Enable/Disable Request |
MSO-116 | Story | Update API Handler to Accept the New Activate/Deactivate Port Configuration Request |
MSO-283 | Story | Update DoDeleteServiceInstance flow for Port Mirror |
MSO-202 | Story | Create health-diagnostic-custom bean for SDNO |
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:
- For creation of the Port Mirror Configuration resource the following information is expected from VID in the createPortMirrorConfiguration API:
POST ../serviceInstances/{id}/configurations- Model Info: the ‘Configuration’ model info.
- Cloud Configuration: the ‘Cloud Region Id’ (Required by SDN-C)
- Request Info:
- Configuration instanceName (mandatory) – assumed to be unique
- Related Instances:
- The pProbe Port Mirror service instance id
- The source vnf id
- The destination C4500 pProbe pnf name. Note: PNF does not have model information, VID is to add modelType = “pnf”
- The instance direction (enum: source, destination)
- APIH will validate and capture request, and trigger a generic a la carte “aLaCarteOrchestrator” recipe.
- APIH will return to VID a synchronous 202 success response with request id and configuration id.
- 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.
ITRACK | TYPE | DESCRIPTION |
MSO-423 | Story | Accept ‘Create Port Mirror Configuration’ a la Carte Request for pProbes from VID |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-86 | Epic | New parameters in creation of Contrail Network Instance |
MSO-88 | Story | |
MSO-89 | Story |
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:
- Environment Context: Identifies the scope of the service model (Sample Values: General_Revenue-Bearing ->default; Critical_Revenue-Bearing; Critical_Non-Revenue)
- Workload Context: Identifies the purpose of the isolated area in AIC. (The value will be instance-specific)
- 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)
ITRACK | TYPE | DESCRIPTION |
MSO-34 | Epic | Tenant Isolation Phase 1 |
MSO-36 | Story | Modify BPMN to pass new metadata params to VNF adapter |
MSO-37 | Story | Modify DoCreateService Instance BPMN Flow |
MSO-38 | Story | Modify ASDC Controller |
MSO-39 | Story | Create new CatalogDB API |
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:
- 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).
- 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.
- MSO operational environments will be able to communicate with the Endpoint Registry, SOA Cloud - GRM.
Dependencies:
- Tenant Isolation - Phase 1
- New A&AI interface to retrieve the Managing ECOMP Operational Environment parameters based on an ECOMP UUID.
- New A&AI interface to store the VNF Operational Environment and environment parameters.
- SOA Cloud - GRM interface to lookup Managing ECOMP Endpoint list in the Endpoint Registry.
- SOA Cloud - GRM interface to create entries in the Endpoint Registry so that VNF Operational Environment will map to Managing ECOMP Endpoint(s).
- 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')
- Operations Manager (Human) manually calls MSO to post the Managing ECOMP Operational Environment. MSO responds with a '202' (request successfully received).
- MSO calls A&AI to store the Managing ECOMP Operational Environment object.
- MSO publishes ECOMP Operational Environment and context to DMaaP.
Create Non-Production VNF Operational Environment (executed when the MSO element operationalEnvrionmentType = 'VNF')
- VID calls MSO to post the VNF Operational Environment. MSO responds with a '202' (request successfully received).
- MSO calls A&AI to retrieve the Managing ECOMP Operational Environment parameters based on an Operational Environment ID.
- MSO calls SOA Cloud - GRM to lookup Managing ECOMP Endpoint list in the Endpoint Registry.
- MSO calls SOA Cloud - GRM to create entries in Endpoint Registry so that VNF Operational Environment will map to Managing ECOMP Endpoint(s).
- MSO calls A&AI to store the VNF Operational Environment and environment parameters.
- VID retrieves status from MSO. Refer to Story 465816.
Technical Impacts:
- Create a MSO API with VID to accept receiving a newly created Managing ECOMP Operational Environment or newly created Non-Production VNF Operational Environment.
- Onboard to a new A&AI interface to retrieve the Managing ECOMP Operational Environment parameters based on an Operational Environment ID.
- Onboard to an existing SOA Cloud - GRM interface to lookup Managing ECOMP Endpoint list in the Endpoint Registry.
- 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).
- Onboard to a new A&AI interface to store the VNF Operational Environment and environment parameters.
- Publish Managing ECOMP Operational Environment and context to DMaaP for ASDC consumption.
ITRACK | TYPE | DESCRIPTION |
MSO-371 | Epic | Tenant Isolation Phase 2 - VNF Operational Environments |
MSO-543 | Story | MSO Creating New DMaaP Topic for an Operational Environment Event |
MSO-390 | Story | Receiving New ECOMP and VNF Operational Environment from VID |
MSO-388 | Story | Retrieving the ECOMP Environment from A&AI |
MSO-391 | Story | Storing Operational Environments in A&AI |
MSO-401 | Story | Publishing Managing ECOMP Operational Environment to DMaaP |
MSO-424 | Story | Retrieving ECOMP Endpoint List from the Endpoint Registry |
MSO-468 | Story | Mapping VNF Context to ECOMP Endpoint in Endpoint Registry |
MSO-428 | Story | Error Handling |
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)
ITRACK | TYPE | DESCRIPTION |
MSO-463 | Epic | MSO Watchdog Process |
MSO-542 | Story | Publish a new Event on DMaaP upon Overall Deployment Completion by all eCOMP Components |
MSO-467 | Story | New tables to track the Distribution Status |
MSO-479 | Story | Trigger the Deployment Management Workflow process |
MSO-466 | Story | Send the Overall Service Version Distribution Status to A&AI |
MSO-465 | Story | Use the Cookbook for eCOMP components |
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)
ITRACK | TYPE | DESCRIPTION |
MSO-462 | Epic | Deactivate Non-Prod ECOMP Operational Environment |
MSO-478 | Story | Handle Deactivate Requests from VID |
MSO-480 | Story | MSO and A&AI interaction to deactivate the Operational Environment |
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)
ITRACK | TYPE | DESCRIPTION |
MSO-464 | Epic | Distributing Contexts to Non Production Environment |
MSO-482 | Story | VID Activates the Operational Environment with the Operational Env ID |
MSO-483 | Story | MSO receives VNF Operational Environment Details from A&AI |
MSO-662 | Story | VID invokes MSO for request Status |
MSO-544 | Story | MSO updates the prod database based on Overall Distribution status |
MSO-665 | Story | Different Filter Criteria from VID to MSO |
MSO-661 | Story | MSO invokes ASDC for Service Model Version Distribution |
MSO-663 | Story | MSO uses Recovery Action with Rainy Day Handling building block |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-1072 | Story | Create GRM Rest Client for Tenant Isolation Project |
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).
ITRACK | TYPE | DESCRIPTION |
MSO-448 | Epic | Agnostic VNF configuration update |
MSO-691 | Story | Refactor existing APPC Client Code |
MSO-551 | Story | API handler changes |
MSO-724 | Story | Call APP-C ConfigModify with MODE=EXCLUSIVE |
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:
- Call A&AI custom query to check pServer in-maintenance flags for VNF
- Call A&AI to check and set VF In Maintenance flag
- Call A&AI to check and set VF is-closed-loop-disabled flag
- Call App-C VNF lock request
- Call APP-C UpgradePreCheck (New for 1802)
- Call APP-C QuiesceTraffic request (New for 1802)
- Call APP-C SnapShot for each VM in the VNF (Creates a snapshot of a VM in AIC) (New for 1802)
- Call APP-C UpgradeBackup (Performs a full backup of the VNF data prior to an upgrade) (New for 1802)
- Call APP-C UpgradeSoftware request (New for 1802)
- Call APP-C UpgradePostCheck request (New for 1802)
- Call APP-C ResumeTraffic (New for 1802)
- Call App-C VNF unlock request
- Call A&AI to unset VF In Maintenance flag
- Call A&AI to unset VF is-closed-loop-disabled flag
ITRACK | TYPE | DESCRIPTION |
MSO-376 | Epic | Agnostic VNF In-Place SW Update |
MSO-550 | Story | API handler changes for vnfInPlaceUpdate |
MSO-450 | Story | VNF agnostic configuration update |
MSO-609 | Task | Prototype the flow with existing A&AI/APP-C calls |
MSO-610 | Task | Integrate with APP-C client subflow |
MSO-611 | Task | Implement Rainy Day Handling |
MSO-612 | Task | Implement Rollback |
MSO-469 | Story | Call APP-C ResumeTraffic |
MSO-555 | Story | Create subflow for APPCControllerClient |
MSO-470 | Story | Call APP-C SnapShot for each VM in the VNF (Creates a snapshot of a VM in AIC) |
MSO-471 | Story | Agnostic vNF In-Place SW Update |
MSO-472 | Story | Call APP-C UpgradePostCheck request |
MSO-473 | Story | Call APP-C UpgradeSoftware request |
MSO-474 | Story | Call APP-C UpgradeBackup (Performs a full backup of the VNF data prior to an upgrade) |
MSO-481 | Story | Call APP-C QuiesceTraffic request |
MSO-675 | Story | Call APP-C UpgradePreCheck |
MSO-670 | Story | increase ACTION column length in *_RECIPE tables |
MSO-817 | Story | Insert new vnf_recipe records for "inPlaceSoftwareUpdate" and "applyUpdatedConfig" actions |
Change Management - AAI interface updates for Configuration Management flows
AAI interface updates for CM flows to check flags, specifically the Closed Loop flag
ITRACK | TYPE | DESCRIPTION |
MSO-895 | Story | AAI interface updates for CM flows |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-1093 | Story | Add new A&AI Query at start of CM flows |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-19 | Epic | VNF Pause and Reporting |
MSO-22 | Story | Modify Catalog Database |
MSO-20 | Story | Modify Do Create VF Module BPMN Flow |
Refactor ReplaceVnfinfra Flow
The Replace VNF Infra flow needs to be refactored and cleaned up with retry logic and AppCClient subflow calls added.
ITRACK | TYPE | DESCRIPTION |
MSO-668 | Story | Refactor ReplaceVnfinfra Flow |
Refactor UpdateVnfinfra Flow
The Update VNF Infra flow needs to be refactored and cleaned up with retry logic and AppCClient subflow calls added.
ITRACK | TYPE | DESCRIPTION |
MSO-667 | Story | Refactor UpdateVnfinfra Flow |
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:
- 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.
- The MSO generic a-la-carte recipe and sub-flow will:
- Query A&AI to get service instance and all topology.
- For each PNF instance in the PNF list, add or remove (action type dependent) relationship to the parent service-instance in A&AI.
Assumptions:
- The pProbe service-instance need to be successfully instantiated in A&AI before the VID user will attempt this action.
- 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.
ITRACK | TYPE | DESCRIPTION |
MSO-377 | Epic | Add & Remove PNF Relationships to/from Parent Physical Probe (pProbe) Service Instance |
MSO-393 | Story | Accept ‘Add Relationships to Service Instance’ a la Carte Request from VID to Add PNFs |
MSO-399 | Story | Accept ‘Remove Relationships from Service Instance’ a la Carte Request from VID to Remove PNFs |
MSO-437 | Story | Add ‘Do Add Relationships to Service Instance’ Building Block to Add PNF Relationships |
MSO-384 | Story | Add ‘Do Remove Relationships from Service Instance’ BB to Remove PNF Relationships |
MSO-417 | Story | Enhance Existing ‘A La Carte Orchestrator’ a la Carte Recipe to Remove PNF Relationships |
MSO-420 | Story | Enhance Existing ‘A La Carte Orchestrator’ Recipe to Add PNF Relationships |
MSO-558 | Story | incorporate Rainy Day BB |
MSO-562 | Story | Enhance ‘Do Create Service Instance’ BB for pProbe Service Instance Creation to Call SDN-C |
MSO-563 | Story | Enhance ‘Do Delete Service Instance’ BB for pProbe Service Instance Deletion to Call SDN-C |
MSO-573 | Story | Execute ‘Do Create Port Mirror Configuration’ for pProbes BB |
MSO-617 | Story | include debug for DecompositionService |
MSO-671 | Story | extract resourceType from VID request |
MSO-692 | Story | Synchronize groovy scripts with latest openecomp AAI library |
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
ITRACK | TYPE | DESCRIPTION |
MSO-1056 | Story | Support AllowableTreatments Policy Query |
MSO-1057 | Task | Update PolicyClientImpl.java |
MSO-1058 | Task | Update AllowedTreatments.java |
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).
ITRACK | TYPE | DESCRIPTION |
MSO-1157 | Story | Retain VM names after failed instantiations |
Refactor the MsoRequest.java parse method
Refactored the request validation logic in the API Handler and implemented unit tests to improve coverage.
ITRACK | TYPE | DESCRIPTION |
MSO-66 | Story | Refactor MsoRequest.java parse method |
MSO-919 | Task | Write JUnit test cases for Existing Parse Code |
REST Clients will support custom properties configuration
Allows applications to specify custom properties to REST clients.
ITRACK | TYPE | DESCRIPTION |
MSO-741 | Story | Allow users to specify the properties file |
REST Clients will add HTTP header information to the log
Add logging of request and response headers.
ITRACK | TYPE | DESCRIPTION |
MSO-1078 | Story | RESTClient will add header information to log |
Relocate Java client source code
Move all Java clients from the "MSOCommonBPMN" project to the "common" project.
ITRACK | TYPE | DESCRIPTION |
MSO-1035 | Story | Move all Java clients to common project rather than CommonBPMN |
AAI Client - Add ALLOTTED-RESOURCE to AAIObjectType
URI template = "serviceinstance uri" + "/allotted-resources/allotted-resource/${id}
ITRACK | TYPE | DESCRIPTION |
MSO-310 | Story | Add Allotted-Resource Uri to aai client |
AAI Client - Allow Delete Relationship
A&AI offers the ability to delete specific relationships by issuing a delete request with a payload.
ITRACK | TYPE | DESCRIPTION |
MSO-354 | Story | Allow Delete Relationship |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-324 | Story | Add Search-around functionality to A&AI client |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-451 | Task | Allow generic parsing of related-links into AAIUri objects |
AAI Client - Add JavaDoc comments
ITRACK | TYPE | DESCRIPTION |
MSO-567 | Story | Add JavaDoc comments |
AAI Client - Add PNF to AAIObjectType
URI template = /network/pnfs/pnf/ {pnf-name}
ITRACK | TYPE | DESCRIPTION |
MSO-568 | Story | Add PNF object type to AAIObjectTypes |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-580 | Epic | Support Bulk Process API |
MSO-554 | Story | Process bulk response message for status |
MSO-553 | Story | Add transactional client for A&AI with the same methods as the resources client |
MSO-579 | Story | Add method for connecting multiple objects |
MSO-552 | Story | Create Pojos for bulk process |
MSO-580 | Story | Add method for disconnecting multiple objects |
MSO-570 | Story | CreateEmpty with bulkprocess api must generate empty JSON Object |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-585 | Story | Create Bean For Operational-Environment |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-597 | Story | Add method to AAIObjectType to retrieve lower-hyphen case |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-582 | Story | Convert A&AI Clients to Version Enum |
MSO-583 | Task | Modify A&AI Client constructors |
MSO-584 | Task | Make sure openecomp and os-based still compile |
MSO-592 | Task | Replace existing string references to versions |
AAI Client - Add depth support to Relationship Object gets
Added the ability to control depth on Relationship gets.
ITRACK | TYPE | DESCRIPTION |
MSO-622 | Story | Add depth support to Relationship Object gets |
AAI Client - Add CLOUD_REGION to AAIObjectType
URI template = /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner-id}/{cloud-region-id}
ITRACK | TYPE | DESCRIPTION |
MSO-619 | Story | Add CLOUD_REGION to AAIObjectType |
AAI Client - Add TENANT to AAIObjectType
URI template = CLOUD_REGION.toString() + "/tenants/tenant/{tenant-id}"
ITRACK | TYPE | DESCRIPTION |
MSO-620 | Story | Add TENANT to AAIObjectType |
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:
- Name, as used in some of the query outputs (lower-hyphen case)
- Full URI template
- 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)
ITRACK | TYPE | DESCRIPTION |
MSO-628 | Epic | AAIObjectType will use polymorphism to accomplish multiple use cases |
MSO-636 | Story | Update AAIObjectPlurals to use AAIObjectUriTemplate |
MSO-632 | Story | AAIObjectUriPartial |
MSO-630 | Story | AAIObjectName interface |
MSO-631 | Story | AAIObjectUriTemplate interface |
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
ITRACK | TYPE | DESCRIPTION |
MSO-629 | Story | Add related-to functionality to AAIUri |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-641 | Story | Divide AAIUri into multiple interfaces |
MSO-642 | Task | Create AAIResources Interface |
MSO-643 | Task | Modify AAIUriFactory to produce AAIResourceUri |
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
ITRACK | TYPE | DESCRIPTION |
MSO-1156 | Story | Improve error message handling in A&AI client |
AAI Client - Add serviceType to AAIObjectType enums
Add Service Type to the list of Enums
ITRACK | TYPE | DESCRIPTION |
MSO-1193 | Story | Add ServiceType to AAIObjectType 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}
ITRACK | TYPE | DESCRIPTION |
MSO-832 | Story | Enable A&AI Client to interact with Service-Model |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-613 | Story | Create simple orchestrator for app-c client |
APPC Client – Configuration properties enhancement
Read properties in ApplicationControllerClient.java.
Updated mso.bpmn.urn.properties.
ITRACK | TYPE | DESCRIPTION |
MSO-1160 | Story | Update properties for D2D testing with App-C |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-413 | Story | Logging Filter will notify on Transfer-Encoding=chunked |
Policy Client – Allow implementers to turn off LoggingFilter
Some client implementations may not want to use the LoggingFilter.
ITRACK | TYPE | DESCRIPTION |
MSO-413 | Story | Allow implementers to turn off 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.
ITRACK | TYPE | DESCRIPTION |
MSO-414 | Story | Logging Filter will allow a customize-able max entity size |
Policy Client – Improve logging
REST client outputs the URI it is calling.
REST client outputs the URI it received a payload from.
ITRACK | TYPE | DESCRIPTION |
MSO-926 | Story | Improve logging for Rest Client |
DMaaP Client – Improve Logging
DMaaP client will log to the MSO audit logger
ITRACK | TYPE | DESCRIPTION |
MSO-370 | Story | Improve Logging for DMaaP Client |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-457 | Story | DMaaP consumer must poll for X minutes |
DMaaP Client – Consumer will log full response messages
Add logging statement for message received from fetch method.
ITRACK | TYPE | DESCRIPTION |
MSO-460 | Story | DMaaP Consumer will log full response messages |
DMaaP Client – Configurable properties loader
Allow DMaaP Client have a configurable properties loader. The DMaaP Client loads the properties implementation via SPI.
ITRACK | TYPE | DESCRIPTION |
MSO-909 | Story | Allow DMaaP Client have a configurable properties loader |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-445 | Story | Add more descriptive exception message for SDN-O |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-416 | Epic | Create a Java Library for SDN-C Requests and Responses |
MSO-441 | Story | Map SDN-C reponse to Service Decomp Object |
MSO-492 | Story | Find out what is and isnt passed through servicedecomp |
MSO-493 | Story | Find common Svc Actions in sdnc.adapter.properties |
MSO-494 | Story | Find common Svc operations in sdnc.adapter.properties |
MSO-498 | Story | Trace non service decomp variables back to parent flow |
MSO-440 | Story | Map Service Decomp Object to SDN-C request |
MSO-439 | Story | Allow alacarte variables to be passed through service decomposition |
MSO-616 | Story | Create Sync SDNC Client |
MSO-624 | Story | Rollback for sdnc client in docreateserviceinstancev2 |
MSO-736 | Story | Generate SDN-C pojos with Swagger2.0 json |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-548 | Story | Add clients for Network/Vnf/Requests Adapters |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-625 | Story | JsonPathUtil will return complex values as a String |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-751 | Story | Refactor DoCreateServiceInstance BPMN Flow using new client libraries |
MSO-182 | Task | Create DoCreateServiceInstanceV2 Flow |
MSO-658 | Task | Create DoCreateServiceInstanceV3 Flow without using groovy |
MSO-918 | Task | Define json schema for input and output of the building block |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-1117 | Story | Add allowableTreatments policy call to Manual Handling |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-769 | Story | Implement Default Policy Disposition |
Create Ruby ticket via DMaaP
Implement the capability to send a trouble ticket to the Ruby system from the Manual Handling Building Block.
ITRACK | TYPE | DESCRIPTION |
MSO-223 | Epic | Create Ruby ticket via DMaaP |
MSO-224 | Story | Ruby Create Ticket Request |
MSO-225 | Story | Add Ruby DMaaP properties to bpmn.urn.properties |
MSO-291 | Story | Modify Manual Handling building block flow |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-830 | Story | Infra API-H - add new serverRoot and rev API version to v6 for all endpoints |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-1092 | Story | Remove old v1-v3 "infra portal" API and BPMNs |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-1176 | Story | Reduce JsonUtils Logging |
Support for interim notifications
Create an SDNCAdapterRestV2 flow which allows interim notifications to be sent.
ITRACK | TYPE | DESCRIPTION |
MSO-745 | Story | Support for “interim” notifications |
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.
ITRACK | TYPE | DESCRIPTION |
MSO-259 | Task | Create unit tests for mso-catalog-db-adapter project |
Add API-Handler unit tests
Create Unit test cases for the API handler packages.
ITRACK | TYPE | DESCRIPTION |
MSO-271 | Task | Create Unit Test cases for the API-Handlers |
Add Network Adapter unit tests
Create unit tests for mso-network-adapter and mso-network-adapter-async-client projects
ITRACK | TYPE | DESCRIPTION |
MSO-559 | Task | 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.
ITRACK | TYPE | DESCRIPTION |
MSO-303 | Story | TOSCA adapter POC |
Bug Fixes
ITRACK | DESCRIPTION |
<none> | Removed trim() statements that were causing a NullPointer exception when no value was provided – in ASDC Controller ToscaResourceInstaller.java |
<none> | Need to get the model uuid for vnf resources so made the change in catalog utils. Also Added logic to get model instance name for vnf in catalog utils. |
MSO-250 | VNF Update of vfModule with volume attached missing required volume id. For a VNF Update request, a vfmodule with volume attached failed due to missing volume-id. The volume id in this case should not be expected from VID request. Instead, the code itself should be querying for the information. |
MSO-266 | VNF Update Hitting internal error toward the end after software update |
MSO-276 | Correct passing variables in ReplaceVnfInfra. Variables need to be added to subprocess calls for DoDeleteVnfAndModules and DoCreateVnfAndModules. |
MSO-282 | Add @Ignore for live appc call in Junit |
MSO-284 | VNF Replace Failed with no Camunda link and DB stuck with IN_PROGRESS |
MSO-301 | Fix call to APP-C client shutdown on errors in Update/Replace VNF |
MSO-311 | Fix JSONArray reference in queryCatalogDB (DoCreateVfModule) |
MSO-314 | SDN-O Health Check should not filter on response node. Change json path to have a wildcard. |
MSO-313 | Logging Filter on Rest Client Drops Information |
MSO-325 | owningEntityName relationship not showing up in service-instance AAI data. |
MSO-328 | SDN-O DMaaP Consumer must poll for 5 minutes. The SDN-O health check takes a long time to complete in test. |
MSO-323 | APPC Client should throw exception when appc service is unavailable |
<none> | Added logging statements for ASDCNotificationLogging and removed trim statements in ToscaResourceInstaller |
MSO-356 | AAI Client does not write related-link correctly. |
MSO-355 | Need to pass vnfName to RainyDayHandler and ManualHandling BBs |
MSO-358 | Fix exception handling in DoCreateServiceInstance.groovy |
MSO-361 | AAI Client does not use the correct object mapper. |
MSO-362 | AAI Client ServiceInstanceUri calls the wrong constructor. |
MSO-359 | ReplaceVnfInfra Flow Error on DoCreateVnfAndModules. Caused by incorrect debug variable in the subflow. |
MSO-365 | AAI Client Can’t create empty object in AAI. |
MSO-368 | AAI Client Does Not Use Optional Correctly. The code is not using the get method for wrapped object. |
MSO-458 | Logging Filter logging transfer-encoding chunked for other clients. Logging filter was printing "Complete response body unavailable because of Transfer-Encoding=chunked" for policy client response. |
MSO-484 | Fix an incorrect variable name in AAICreateResources |
MSO-489 | Reduce timeout for appc read and write. Client hangs for a long time. Should now end after 60 seconds and should return a status code of 501 and with error message so that check in groovy will record it as an error. |
MSO-576 | Fix logging variable for DoCreateVnfAndModules. |
MSO-587 | VNF Replace Failed at the point when it tried to delete vfModule, SDNC - no preload data. DB: Received error from SDN-C: No preload data found to match vnf-name |
MSO-596 | AAI Client - Key is misspelled in Relationships class. “realationship” should be “relationship”. |
<none> | Fixed wrong import reference in Homing Building Block and also updated junits to get them running and passing |
<none> | Updated ASDCController to add sendCsarDeployNotification which will send a DEPLOY_OK for the csar file. Also removed all the trim statements in the csarlogging step. |
MSO-635 | Extracting error message from SDN-O failure message not working. Status message is located in a field called error-message. Updated response-id within payload to be accurate. Updated failure case for SDN-O DMaaP Consumer. Updated test bpmn.urn.properties to include sdno props. |
MSO-638 | DoCreateVnf errorCode:404, errorMessage:Service Instance Not Found |
<none> | ASDC Controller - Added logging statements for serviceRole, serviceType, workloadContext, environmentContext and multi-stage-design |
<none> | Changed the timeout on SNIRO homing request to be a variable versus being hardcoded. |
MSO-650 | Implement retry logic for the OptimisticLockingException. Retry logic for the OptimisticLockingException thrown by Camunda during DB update. |
<none> | Removed Basic Auth from homing call to SNIRO |
MSO-687 | VNF Update/Replace Attempt showe no Camunda Link and DB stuck IN_PROGRESS. The failure is in the initialization of the APP-C client before the Rainy Day Handling gets set up. The initialization requirements for the APP-C client have changed, so we will need to make a change for that, and move workstep setting to earlier in the method. |
MSO-768 | Fix Request ID propagation in ReplaceVnfInfra. |
MSO-805 | Flow Update and Parameter Fix for ReplaceVnfInfra. Fix default sequence and add serviceInstanceId parameter in the call to DoCreateVnfAndModules |
MSO-806 | Error loading cloud config on BPMN server. There are some beans and exceptions that are located in mso-adapter-utils that are used by mso-adapters-rest-interface. These should be moved into mso-adapters-rest-interface. There are also some openstack dependencies that should be moved into the mso-adapters-rest-interface pom. Move dependency of common from mso-adapter-utils to mso-adapters-rest-interface. We can then make adapter utils depend on mso-adapters-rest-interface. |
<none> | ONAP commit changed orch-status initialization from "Active" to empty string. |
MSO-925 | Move cloudify module above packages module in pom file. |
MSO-936 | API Handler Infra duplicates Properties file key. Added a new "MSO_PROP_APIHANDLER_INFRA" constant declaration and replaced all "MSO_PROP_APIHANDLER_INFRA" strings with the new constant. |
MSO-752 | All groovy files access the wrong Object type from Camunda. Camunda exposes a global object to all Script Tasks called execution it has the type DelegateExecution. MSO defined an interface which uses the wrong object type - Execution. Groovy corrects this error for us during run time, but the problem still visually persists in everyone's editors and prevents us from using Static Type Checking if we desired to do so. |
<none> | HR tags need to be explicitly closed in unit test XML files. |
<none> | Corrected JSON formatting, removed comments from unit test files. |
<none> | table-filter element must be after type-mapping element in hibernate.reveng.xml |
<none> | Fix namespace version definition in normalize-namespaces.xsl |
<none> | Workaround to get eclipse to recognize arquillian-unit-tests/pom.xml as error free. |
MSO-1047 | Moved GenerateVfModuleNameTest.java from AT&T code base to openecomp. |
MSO-987 | Infra APIH not writing raw client request to requests DB. In mso_requests.infra_active_requests.request_body, infra APIH is logging the parsed/processed (defaults applied) json body rather than the RAW input from the client. |
MSO-1048 | Force aLaCarte flag to true on Create VF Module. |
MSO-1029 | Rollback is broken on create service instance. AAI GET fails, but flow completes and DB shows that request succeeded. |
MSO-1036 | Keep original vnfId on VNF Replace. Recycle vnfId on VNF Replace request to keep consistent data. |
MSO-1062 | Fix debug statement in DoCreateVnfAndModules - isDebugEnabled is invalid. |
MSO-1067 | Remove MSOCommonBPMN dependency from APIHInfra pom. |
MSO-1071 | The multiStageDesign Flag needs to be a Boolean. The multiStageDesign flag has to be a Boolean, not Y/N, as originally specified (catalog DB and DoCreateVfModule). |
MSO-1081 | AAI Rest Client - delete service instance needs all 3 parameters. Delete service instance to AAI should work with just a serviceInstanceId but fails without having a serviceType and customerId in the URI. |
MSO-1091 | AAI Rest Client - ServiceInstanceUri does not clone properly. |
MSO-991 | Infra APIH is defaulting requestParameter params incorrectly. Infra APIH is defaulting both "alaCarte" and "aLaCarte" on requests. "alaCarte" should never exist, and "aLaCarte" should only be defaulted when requestScope = service. Similarly, other requestParameter params (that have a default value) are being defaulted for all requestScopes + actions, rather than only for the ones that they are applicable to, per the VID/POLO 1802 AID. All should be revised to avoid confusion. |
MSO-916 | Null Values Handling in DoCreateVnfInfra. In CreateVnfInfra/DoCreateVnf, there seems to be an issue with how the groovy code is handling null values for some of the parameters that we send on the put to A&AI. A&AI expects us to send them empty if there is no value, but in this case, we sent the actual string "null". |
MSO-822 | When an attempt to Update VNF Fails, DB status stays "IN_PROGRESS" Fix the CompletionHandler and FalloutHandler calls from CM flows. |
MSO-1110 | Volumes are not being deleted during a rollback. The rollbackVolumeGroupRequest XML being sent to VNFAdapter is not correctly. VNF Adapter is unable to parse the volumeGroup data. CreateVolume flow was not formatting the saved volume group rollback request XML. This fix will create the correct XML and also send the required heatStackId which was not previously being sent. |
MSO-1145 | Removed jaxb jettison provider in mso-adapters-rest-interface pom. |
MSO-1159 | AAI REST Client - addRelationship fails adding multiple PNFs due to invalid path |
<none> | Added another condition in SDNCServiceRequestConnector code - Not a 2XX and not a 0 response, return SDNCServiceError. |
MSO-1171 | DoCreateServiceInstance causes null pointer exception when variables not found. Many spots in the groovy file perform checks such as: if((variableA.equals(""))||(variableA == null)) |
<none> | Fixed Instantiation error between the homingsolution and resource objects. |
MSO-1173 | ExceptionUtil does not produce valid XML. ExceptionUtil takes string values and directly plugs them into a String that looks like XML. This can lead to encoding errors when the values contain reserved characters in the XML specification. |
MSO-1181 | AAI REST Client - RESTEASY003765: Response is closed - error on bulk AAI update |
<none> | Removed deprecated getVnfHostname in homingSolution to fix null pointer error. |
MSO-1186 | NullPointerException on VNF Replace in API Handler when "usePreload" is not included. |
MSO-1192 | Correct variable name for validResponses in RainyDayHandling building block. |
MSO-1199 | APPC REST Client - Fix Error Message null value. |
3 Comments
Rob Daugherty
I've included the AT&T ITRACK issue numbers so I can locate the original commits in case there are questions about them.
I'm making another scan of the source material. If I find additional items, I'll add them.
Michael O'Brien
Rob, Hi we should not be tracking internal company JIRAs here that the rest of the community cannot see - my worry is that valuable content on design/intent/config/testing is being recorded outside of ONAP. Ideally you would setup an Itrack shadow JIRA for internal AT&T processes - but the work and documentation would be put in the public corresponding JIRA in ONAP.
for example
MSO-288
is not
SO-288 - Getting issue details... STATUS
And valuable bugs like the NPE in MSO-1186 during preload should be available to ONAP directly or raised there first.
I understand that we are still bringing in seed code - but IPDD is not a design document the ONAP community may be aware of - perhaps we can move part of the IPDD process up into the public space.
thank you
/michael
Min Sang Yoon
Hello,
When I add a relationship between service and PNF from VID, there is an issue from SO side. API handler could not forward the call to approprite BPMN model because 'mso.apihandler.infra.properties' file did not have of 'mso.infra.default.alacarte.orchestrationUri'. I could solve API handler issue by changing this file to indicate Orchestration_URI but I am not sure which BPMN model will be appropriate for this. I cannot find 'UpdateVnfinfra'. Anyone has a solution for this situation?
Thank you,
Min Yoon