diff options
| author |   Jerry Flood <jflood@att.com> | 2019-05-30 10:36:24 -0400 |
|---|---|---|
| committer | Jerry Flood <jflood@att.com> | 2019-05-30 10:36:39 -0400 |
| commit | 6df50b96c77bd6402ea4bd7f1a84de6233549cdf (patch) | |
| tree | d28862e0ae20bbf74fb8dcee9da56d6991c8fc04 /docs/index.rst | |
| parent | cc67f224925c03f50ce47068cbde66799c65e3a0 (diff) | |
Initial docs update for Dublin
Issue-ID: OPTFRA-510
Change-Id: Ic2027fbd66de0f45f826282701c9979fc1599cb0
Signed-off-by: Jerry Flood <jflood@att.com>
Diffstat (limited to 'docs/index.rst')
| -rw-r--r-- | docs/index.rst | 7 |
1 files changed, 3 insertions, 4 deletions
diff --git a/docs/index.rst b/docs/index.rst index 6448c1b..e185288 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -9,11 +9,10 @@ SO work flow requests for multiple VNFs to be executed within a provided change optimizer is designed to determine a "conflict free" time within that change window that is suitable for submitting the changes to SO. -The initial release provides a skeletal implementation that runs in "standalone" mode, that is, the -intended interfaces are stubbed out (i,e, "loop-back mode"). +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. - * SO interface for dispatching the work flow and checking status - * Optimizer Interface for determining the "conflict free" change window (loop-back mode selects the start of change window provided the client) + * 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. |