Optimization Framework: Change Management Schedule Optimization

OOF-CMSO is an optimizing service that allows for the scheduling of VNF change management work flows to be executed at a time in the future. It enables a 3rd party client to provide SO work flow requests for multiple VNFs to be executed within a provided change window. The schedule optimizer is designed to determine a “conflict free” time within that change window that is suitable for submitting the changes to SO.

The Dublin release provides a an schedule optimizer framework that provides an interface to a model driven schedule optimizer developed using MiniZinc technolgy to provide a best effort at a conflict free schedule. Inputs to the schedule optimizer require network topology and and scheduled change information on relevant network elements in order to do conflict avoidance. To this end, a Change Management Topology and Ticket Management interfaces were designed to abstract the vendor specific topology and availability data required for schedule optimization. Dublin provides skeletal implementations of these services.

  • Dublin does not include an interface to SO for initiating the work flows and checking status. Rather, it has been suggested that a SO dispatcher service be provided to manage the runtime SO workload. While CMSO may take into account work scheduled for SO when creating a schedule. it is outside the domain of CMSO to manage the runtime actual workload on a target service such as SO.

  • Dublin Topology and Ticket Management simulator services are skeletal interfaces. These services will be expanded in El Alto to provide data to support additional conflict avoidance test cases. Currently, only sunny day test cases are implemented in the CSIT test suite.

CMSO also models interfacing an external ticket/change management system to create, update, close/cancel tickets at relevant points in the CMSO flow.

Architecture

Introduction

OOF-CMSO is an optimizing service that allows for the scheduling of VNF change management work flows to be executed at a time in the future. It enables a 3rd party client to provide SO work flow requests for multiple VNFs to be executed within a provided change window. The schedule optimizer is designed to determine a “conflict free” time within that change window that is suitable for submitting the changes to SO.

The Dublin release provides a an schedule optimizer framework that provides an interface to a model driven schedule optimizer developed using MiniZinc technolgy to provide a best effort at a conflict free schedule. Inputs to the schedule optimizer require network topology and and scheduled change information on relevant network elements in order to do conflict avoidance. To this end, a Change Management Topology and Ticket Management interfaces were designed to abstract the vendor specific topology and availability data required for schedule optimization. Dublin provides skeletal implementations of these services.

  • Dublin does not include an interface to SO for initiating the work flows and checking status. Rather, it has been suggested that a SO dispatcher service be provided to manage the runtime SO workload. While CMSO may take into account work scheduled for SO when creating a schedule. it is outside the domain of CMSO to manage the runtime actual workload on a target service such as SO.

  • Dublin Topology and Ticket Management simulator services are skeletal interfaces. These services will be expanded in El Alto to provide data to support additional conflict avoidance test cases. Currently, only sunny day test cases are implemented in the CSIT test suite.

CMSO also models interfacing an external ticket/change management system to create, update, close/cancel tickets at relevant points in the CMSO flow.

CMSO in Change Management Flow

CMSO is designed to be agnostic of the type of change management work flow that is to be scheduled in SO. A 3rd party client application will be responsible for preparing the change management request messages to be forwarded to SO. This data, along with the list of targeted VNFs and the scheduling requirements are used by CMSO to create and ultimately execute the schedule to dispathc the work to SO.

The information provided to CMSO to accomplish the scheduling of the changes:

  • Work flow information

    • Name of the work flow

    • Message(s) to be forwarded to SO to initiate the work flow

  • Schedule information

    • The list of targeted VNFs

    • The desired change window

      • Earliest start date/time

      • Latest end date/time

    • Expected duration of the work flow execution

    • Number of concurrent work flows to be scheduled

The design of CMSO is to ensure that the scheduling of the work flows will not conflict with other scheduled work.

  1. Ensure that asset(s) required to execute the work flow are available so that the work flow will be able to complete successfully

  2. Ensure that the execution of the work flow does not cause a network outage.

Architectural Flow Diagram

_images/ONAP_CMSO_FLOW.png

Scheduling Optimization and Confict Avoidance

The Dublin implementation of CMSO implements an Optimization service that provides conflict avoidance. The optimized schedule provides a start time for each VNF in the schedule.

Conflict avoidance to achieve the goals of CMSO, successful completion of change requests without incurring network outages, requires a system to track the availability (or rather unavailability) of assets required to determine an optimal time for exectution. No such change management system exists at this time within ONAP, however, Dublin CMSO defines an interface that abstracts the Change Management Ticket information necessary for the schedule optimizer engine to determine element availability.

SO Change Request Dispatching

CMSO does not serve as a throttling dispatcher to SO. Rather, the dispatching of work to SO is based solely on the start time assigned to each VNF. CMSO will dispatch a VNF change to SO regardless of how many outstanding change management requests there are to SO within CMSO.

It has been proposed that a dispatcher service be defined to enable applications such as SO to manage the runtime workload of the service. The dispatcher would respond to system busy indicators to determine the disatch disposition of a request. For example, time sensitive may be rejected if they cannot be serviced in a particular time window while others may be held based upon priority.

Offered APIs

This document describes the CMSO APIs provided by the Change Management Schedule Optimizer (CMSO)

To view API documentation in the interactive swagger UI download the following and paste into the swagger tool here: https://editor.swagger.io

CMSO Service API

oof-cmso-api.json

CMSO Administration

GET /{apiVersion}/admin/{id}

  • Description: Returns encrypted value of id.

  • Produces: [‘text/plain’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1|v2

string

id

path

Identifier

array

Responses

200 - OK

400 - Request failed

GET /{apiVersion}/health

  • Description: Returns health status of server.

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

checkInterfaces

query

Check Interfaces

array

Responses

200 - OK

400 - Not healthy

CMSO Optimized Schedule API

POST /{apiVersion}/schedules/optimized/{scheduleId}

  • Description: Creates a request for an optimized schedule

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

scheduleId

path

Schedule id to uniquely identify the schedule request being created.

string

body

body

Data for creating a schedule request for the given schedule id

Responses

202 - Schedule request accepted for optimization.

409 - Schedule request already exists for this schedule id.

500 - Unexpected Runtime error

CMSO Schedule API

GET /{apiVersion}/schedules

  • Description: Returns a list of Scheduler Requests based upon the filter criteria.

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

includeDetails

query

Include details

boolean

scheduleId

query

Schedule identifier

array

scheduleName

query

Schedule name

array

userId

query

SCheduler creator User id of

array

status

query

Schedule status

array

createDateTime

query

Creation date and time (<low date>[,<hi date>])

array

optimizerStatus

query

Optimizer status

array

WorkflowName

query

Workflow

array

Responses

200 - OK

404 - No records found

500 - Unexpected Runtime error

GET /{apiVersion}/schedules/scheduleDetails

  • Description: Returns a list of Schedule request details based upon the filter criteria.

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

request.scheduleId

query

Schedule identifier

array

request.scheduleName

query

Schedule name

array

request.userId

query

Scheduler creator User id of

array

request.status

query

Schedule status

array

request.createDateTime

query

Creation date and time (<low date>[,<hi date>])

array

request.optimizerStatus

query

Optimizer status

array

request.approvalUserId

query

Request Approval user id

array

request.approvalStatus

query

Request Approval status

array

request.approvalType

query

Request Approval type

array

WorkflowName

query

Workflow

array

vnfName

query

VNF Name

array

vnfId

query

VNF Id

array

vnfStatus

query

VNF Status

array

startTime

query

Start time <low>,<high>

array

finishTime

query

Finish time <low>,<high>

array

lastInstanceTime

query

Last instance start time <low>,<high>

array

tmChangeId

query

TM Change Ticket Change Id

array

maxSchedules

query

Maximum number of schedules to return

integer

lastScheduleId

query

Return schedules > lastScheduleId

string

request.concurrencyLimit

query

Return concurrencyLimit

integer

Responses

200 - OK

404 - No records found

500 - Unexpected Runtime error

GET /{apiVersion}/schedules/{scheduleId}

  • Description: Retrieve the schedule request for scheduleId

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

scheduleId

path

Schedule id to uniquely identify the schedule info being retrieved.

string

Responses

200 - OK

404 - No record found

500 - Unexpected Runtime error

POST /{apiVersion}/schedules/{scheduleId}

  • Description: Creates a schedule request for scheduleId

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

scheduleId

path

Schedule id to uniquely identify the schedule request being created.

string

body

body

Data for creating a schedule request for the given schedule id

Responses

202 - Schedule request accepted for optimization.

409 - Schedule request already exists for this schedule id.

500 - Unexpected Runtime error

DELETE /{apiVersion}/schedules/{scheduleId}

  • Description: Cancels the schedule request for scheduleId

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

scheduleId

path

Schedule id to uniquely identify the schedule request being deleted.

string

Responses

204 - Delete successful

404 - No record found

500 - Unexpected Runtime error

POST /{apiVersion}/schedules/{scheduleId}/approvals

  • Description: Adds an accept/reject approval status to the schedule request identified by scheduleId

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

scheduleId

path

Schedule id to uniquely identify the schedule request being accepted or rejected.

string

body

body

Accept or reject approval message

Responses

200 - OK

404 - No record found

500 - Unexpected Runtime error

{
}
{
}

CMSO Optimizer API

oof-cmso-api.json

Administration

GET /{apiVersion}/admin/{id}

  • Description: Returns encrypted value of id.

  • Produces: [‘text/plain’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1|v2

string

id

path

Identifier

string

Responses

200 - OK

400 - Request failed

GET /{apiVersion}/health

  • Description: Returns health status of server.

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

checkInterfaces

query

Check Interfaces

boolean

Responses

200 - OK

400 - Not healthy

Optimizer Interface

POST /{apiVersion}/optimize/schedule

  • Description: API to request schedule optimization for the passed elements.

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

body

body

Optimization data.

Responses

202 - Accepted

400 - Bad request

500 - Unexpected Runtime error

GET /{apiVersion}/optimize/schedule/{id}

  • Description: API to poll for optimized schedule.

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

id

path

Request id

string

Responses

200 - OK

404 - Not found.

500 - Unexpected Runtime error

DELETE /{apiVersion}/optimize/schedule/{id}

  • Description: API to acknowledge and delete optimized schedule request. Acknowledgesthat optimization has results have been retrieved an are safe to delete

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

id

path

Request id

string

Responses

204 - Deleted

404 - Not found.

500 - Unexpected Runtime error

GET /{apiVersion}/policies

  • Description: API to retrieve supported change management policies.

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

Responses

200 - OK

400 - Bad request

500 - Unexpected Runtime error

{
}
{
}

CMSO Ticket Management API

oof-cmso-api.json

Administration

GET /{apiVersion}/admin/{id}

  • Description: Returns encrypted value of id.

  • Produces: [‘text/plain’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1|v2

string

id

path

Identifier

string

Responses

200 - OK

400 - Request failed

GET /{apiVersion}/health

  • Description: Returns health status of server.

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

checkInterfaces

query

Check Interfaces

boolean

Responses

200 - OK

400 - Not healthy

Availability Interface

POST /{apiVersion}/activetickets

Request Active Tickets

  • Description: API to support conflict avoidance. Retrieves the active ticket data for the passed criteria to detemine availability of passed elements within the passed time window. If the request results in asynchronous processging, IN_PROGRESS status will be returned and the optimizer will begin to poll the request until COMPLETED.

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

body

body

Active ticket criteria (elements and change windows).

Responses

200 - OK

400 - Bad request

500 - Unexpected Runtime error

GET /{apiVersion}/activetickets/{id}

Poll Active Tickets Request

  • Description: Poll for the status of the request id. Optimizser will poll until status is COMPLETED and issue acknowledge (DELETE) API to acknowledge the receipt of the response.

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

id

path

Active tickets request id.

string

Responses

200 - OK

404 - Not found.

500 - Unexpected Runtime error

DELETE /{apiVersion}/activetickets/{id}

Acknowledge Active Tickets Response

  • Description: API call used to acknowledge the receipt of a COMPLETED asynchronous request to enable the Ticket Management service to remove it from their cache. The service may remove from the cache on the poll request. The optimizer will treat Not found reponse on as normal.

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

id

path

Active tickets request id.

string

Responses

200 - successful operation

204 - OK

404 - Not found

500 - Unexpected Runtime error

Ticket Management

POST /{apiVersion}/ticket

Create Ticket

  • Description: Creates a ticket for the passed data

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

body

body

Data for creating a ticket

Responses

200 - Ticket Created. Ticket Id returned.

400 - Bad request.

500 - Unexpected Runtime error

PUT /{apiVersion}/ticket

Update Ticket

  • Description: Updates a ticket to the passed data

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

body

body

Data for updating a ticket

Responses

204 - Ticket Updated.

400 - Bad request.

500 - Unexpected Runtime error

GET /{apiVersion}/ticket/{id}

Fetch Ticket

  • Description: Returns ticket information for the provided ticket id.

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

id

path

Unique ticket identifier

string

Responses

200 - OK

404 - No record found

500 - Unexpected Runtime error

DELETE /{apiVersion}/ticket/{id}

Cancel the ticket

  • Description: Cancels the ticket.

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

id

path

Ticket id to uniquely identify the ticket being deleted.

string

Responses

204 - Delete successful

400 - Bad request

404 - No record found

500 - Unexpected Runtime error

GET /{apiVersion}/tickets

Search Tickets

  • Description: Returns a list of based upon the filter criteria.

  • Produces: [‘application/json’]

Parameters

Name

Position

Description

Type

apiVersion

path

v1

string

id

query

Ticket identifier

array

elementId

query

Element Id

array

startTime

query

Start time <low>,<high>

array

finishTime

query

Finish time <low>,<high>

array

maxTickets

query

Maximum number of tickets to return

integer

lastId

query

Return tickets > last id

string

Responses

200 - OK

400 - Bad request

500 - Unexpected Runtime error

{
}
{
}

CMSO Topology API

oof-cmso-api.json

Error

Unable to process URL: ./swaggerdoc/oof-cmso-topology-api.json. Please check that the URL is a valid Swagger api-docs URL and it is accesible

{
}
{
}

Consumed APIs

The following are the dependencies for CMSO project.

SO (TBD)

CMSO is designed to invoke SO API to

  • Submit change management work flow requests

  • Poll for status of submitted requests

While the CMSO schedule optimizer considers concurrency when creating a scheduler, the actual SO workload at runtime remains outside the capabilities of CMSO. It has been proposed that CMSO interfaces to a dispatcher service which would manage the actual workload to SO at runtime.

Schedule Optimizer with Conflict Avoidance

CMSO in Dublin includes schedule optmizer that implements conflict avoidance. Services were added to CMSO in Dublin to support providing data to the scheduler optimizer which requires:

  • Network Topology

    • Vertical topology assets relevant the availability of the VNF(s) under consideration. These assets must be available in order to accomplish the change.

    • Horizontal topology assets. Horizontal topology represents assets that must be available in order to avoid a network outage during the change. As an example, the assets supporting the backup instance(s) of the VNF under change.

    • Dublin provides a CMSO Topology Service which implements an API desinged to provide CMSO optimizer the network topology information that is required for conflict avoidance. This service currently only returns the VNF itself, however, El Alto will simulate vertical topology for the VNFs to expand the scope of the CMSO CSIT test cases.

  • Availability of the VNFs and related network elements identified by the Toplogy service.

    • Determining the availability of related assests generally requires a change management

    tracking/ticketing system system that identifies scheduled changes (unavailaibility) to all assets that contribute to the functioning of the network.

    • Dublin provides a CMSO Ticket Management service to simulate a change management ticketing system within ONAP. This service currently returns empty results, however, El Alto will simulate change tickets for the network elements to expand the scope of the CMSO CSIT test cases.

CMSO Topology Service

CMSO Ticket Management Service

OOF CMSO Delivery

OOF CMSO is made up of 6 docker containers depoloyed via OOM

  1. CMSO Service - Java server (Jersey)

  2. CMSO Database Initialization - Java wrapper invoking Liquibase schema management scripts

  3. MariaDB - OOM Common mariadb-galera server

  4. CMSO Optimizer - Java server (Jersey)

  5. CMSO Ticket Management - Java server (Jersey)

  6. CMSO Topology - Java server (Jersey)

The OOM Helm Charts are located here:

https://gerrit.onap.org/r/gitweb?p=oom.git;a=tree;f=kubernetes/oof/charts/oof-cmso;h=2cbb8cd2178077575cd03a4dfb359b2c941ba2db;hb=HEAD

OOF CMSO Delivery Diagram

_images/DeliveryOOM.png

Logging

CMSO uses the EELF logging package and produces the following logs

  • error

  • audit

  • metric

  • application.

The log statements follow the following format (values default to preset values when missing):

Installation

Installing from the Source Code

Get CMSO seed code from the Linux Foundation Projects page

$ git clone https://gerrit.onap.org/r/a/optf/cmso

There are 5 folders in the project that represent the CMSO services

  • cmso-service - Java Maven project (cmso-service/pom.xml)

  • cmso-database - Java Maven project (cmso-database/pom.xml) for managing database schema and migrations

  • cmso-optimizer - Java Maven project (cmso-optimizer/pom.xml)

  • cmso-topology - Java Maven project (cmso-topology/pom.xml)

  • cmso-ticketmgt - Java Maven project (cmso-ticketmgt/pom.xml)

There are 2 support folders

  • cmso-robot - Robot framework project for used for unit and functional testing. See the project README for setup instructions. This produces a docker container as well.

  • cmso-sonar - This project executed the full robot test suites to generate the code coverage data for Sonar.

Note that CMSO was developed using Robot framework as the primary unit testing vehicle so the cmso-sonar project was developed to generate the jacoco files for the 4 CMSO services to augment the limited Junit test cases. This same test suites are those executed in the CMSO CSIT job. Docker compose is used to create all of the required containers, including a Maria DB instance and the cmso-robot docker container.

Configuration

Executing CMSO in a standalone environment requires

  • MariaDB instance

  • Maven

  • Java JDK 1.8

Executing the Robot testsuite requires

  • Python 3.7

  • Robot Framework

Running the example

TBD

Running the Robot Framework ETE testsuite

TBD

Committing the Code

$ git commit -am “Initial proj struct”

$ git review -s

$ git commit -as –amend

# scroll down 2 lines (above your Change-ID) insert “Issue-ID: {issue_id}”

$ git review

Administration

Administration - TBD

Human Interfaces

OOF CMSO does not expose a human interface

Glossary

Term

Description

SO

Service Orchestrator

Contact

Jerry Flood jflood@att.com

Example CMSO Schedule Creation Templates

Example 1 (TBD)

{
 "scheduleId" : "<uuid>"
}

Contact

Jerry Flood jflood@att.com

Release Notes

Abstract

This document provides the release notes for the Honolulu release.

Summary

Release Data

New features

Bug Fixes

  • OPTFRA-905 Fix security vulnerabilities

  • OPTFRA-927 Fix weak cryptography issues

Known Limitations, Issues and Workarounds

System Limitations

Known Vulnerabilities

Workarounds

Security Notes

References

For more information on the ONAP Honolulu release, please see:

  1. ONAP Home Page

  2. ONAP Documentation

  3. ONAP Release Downloads

  4. ONAP Wiki Page

Quick Links:

Abstract

This document provides the release notes for the Guilin release.

Summary

Release Data

OOF Project

Docker images

  • optf-cmso-ticketmgt 2.3.0

  • optf-cmso-topology 2.3.0

  • optf-cmso-optimizer 2.3.0

  • optf-cmso-service 2.3.0

Release designation

7.0.0 guilin

Release date

2020-11-19 (TBD)

New features

Known Limitations, Issues and Workarounds

System Limitations

Known Vulnerabilities

Workarounds

Security Notes

Fixed Security issues

  • OPTFRA-752 Upgrade Vulnerable Direct Dependencies

  • OPTFRA-838 OOF has root pods

  • OPTFRA-841 Remove checker-framework from CMSO logger

References

For more information on the ONAP Guilin release, please see:

  1. ONAP Home Page

  2. ONAP Documentation

  3. ONAP Release Downloads

  4. ONAP Wiki Page

Quick Links:

Abstract

This document provides the release notes for the Frankfurt release.

Summary

Release Data

OOF Project

Docker images

  • optf-cmso-ticketmgt 2.2.0

  • optf-cmso-topology 2.2.0

  • optf-cmso-optimizer 2.2.0

  • optf-cmso-service 2.2.0

Release designation

6.0.0 frankfurt

Release date

2020-05-07 (TBD)

New features

Known Limitations, Issues and Workarounds

System Limitations

Known Vulnerabilities

Workarounds

Security Notes

References

For more information on the ONAP Frankfurt release, please see:

  1. ONAP Home Page

  2. ONAP Documentation

  3. ONAP Release Downloads

  4. ONAP Wiki Page

Quick Links:

Version: 5.0.1

Release Date

2019-09-30 (El Alto Release)

Artifacts released:

optf-cmso:2.1.1

New Features

While no new features were added in the release, the following Stories were delivered as enhancements.

  • [OPTFRA-427] CMSO - Schedule a workflow in SO and track status to completion

  • Platform Maturity Level 1
    • ~56.4+ unit test coverage

Bug Fixes

The El Alto release for CMSO fixed the following Bugs.

  • [OPTFRA-577] Need for “ReadWriteMany” access on storage when deploying on Kubernetes?

  • [OPTFRA-517] Clean up optf/cmso in integration/csit for Dublin

  • [OPTFRA-403] OOF CMSO Service kubernetes resources allocation is not done

  • [OPTFRA-526] OOF pods not running

  • [OPTFRA-593] OOF-CSMO healthcheck is failing in Master

Known Issues

  • [OPTFRA-596] CMSO - Sonar and CSIT jobs failing

Security Notes

Fixed Security Issues

  • [OPTFRA-455] CMSO - Mitigate License Threat tomcat-embed-core

Known Security Issues

  • [OPTFRA-481] Fix Vulnerability with spring-data-jpa package

  • [OPTFRA-431] Fix Vulnerability with spring-security-web package

Known Vulnerabilities in Used Modules

Upgrade Notes

Deprecation Notes

Other

Version: 2.0.0

Release Date

2019-06-06 (Dublin Release)

New Features

  • Implement encryption for CMSO internal and external communication

  • CMSO to support change management schedule optimization

  • Design, Implement Ticket Management API

  • Design, Implement Topology API

  • Implement AAF Authentication

  • Platform Maturity Level 1
    • ~56.4+ unit test coverage

The Dublin release for OOF delivered the following Epics.

  • [OPTFRA-426] Track the changes to CMSO to support change management schedule optimization

  • [OPTFRA-424] Extend OOF to support traffic distribution optimization

  • [OPTFRA-422] Move OOF projects’ CSIT to run on OOM

  • [OPTFRA-276] Implementing a POC for 5G SON Optimization

  • [OPTFRA-270] This epic captures stories related to maintaining current S3P levels of the project as new functional requirements are supported

Bug Fixes
  • [OPTFRA-500] CMSO - Update version to 2.0.0

  • [OPTFRA-484] OOF-CMSO fails health check

  • [OPTFRA-480] Fix tomcat-embed-core vulnerability

  • [OPTFRA-479] Fix Vulnerability with commons-codec package

  • [OPTFRA-478] Fix Vulnerability with spring-security-core package

  • [OPTFRA-474] Update CMSO build to support Sonar Code Coverage

  • [OPTFRA-466] CMSO Audit and update all source code for ONAP compliance

  • [OPTFRA-462] CMSO - Upgrade robot from Python 2 to Python 3

  • [OPTFRA-458] CMSO - Implement the CMSO Create Optimized Schedule API

  • [OPTFRA-457] CMSO - Define CMSO Create Optimized Scheduler API

  • [OPTFRA-453] CMSO - Mitigate sonatype-2017-0507 security vulnerability

  • [OPTFRA-451] Create OOM based CSIT for CMSO

  • [OPTFRA-437] CMSO - Define the API to be used to invoke the optimizer

  • [OPTFRA-436] CMSO -Implement model driven optimizer to provide conflict-free schedules

  • [OPTFRA-433] CMSO - Implement Ticket Management Simulator to support Ticket Management API for testing purposes

  • [OPTFRA-432] CMSO - Define Ticket Management API

  • [OPTFRA-431] Fix Vulnerability with spring-security-web package

  • [OPTFRA-430] CMSO - Define API for requesting topology for an element

  • [OPTFRA-425] Multiple Sonar Fixes

  • [OPTFRA-414] AuthProvider.java - sonar fixes

  • [OPTFRA-413] Junit for AuthProvider

  • [OPTFRA-403] OOF CMSO Service kubernetes resources allocation is not done

  • [OPTFRA-397] CMSO Update to Spring Boot 2.1.3-RELEASE

Known Issues

  • [OPTFRA-517] Clean up optf/cmso in integration/csit for Dublin

Security Issues

  • [OPTFRA-481] Fix Vulnerability with spring-data-jpa package

Upgrade Notes None. Initial release R3 Casablanca. No previous versions

Deprecation Notes None. Initial release R3 Casablanca. No previous versions

Other None

Quick Links:

Version: 1.0.1

Release Date

2018-11-30 (Casablanca)

New Project

Known Issues

  • [OPTFRA-386] - Integrate with SO

  • [OPTFRA-387] - Add conflict avoidance optimizaation to schedule creation

Security Issues

  • [OPTFRA-397] - Upgrade Spring Boot release

  • [OPTFRA-390] - Support AAF authentication/authorization

  • [OPTFRA-391] - Implement HTTPS on incoming requests

Upgrade Notes None. Initial release R3 Casablanca. No previous versions

Deprecation Notes None. Initial release R3 Casablanca. No previous versions

Other None