docs/release-notes.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2
   3 Policy Release Notes
   4 ====================
   5
   6 .. note
   7 ..      * This Release Notes must be updated each time the team decides to Release new artifacts.
   8 ..      * The scope of these Release Notes are for ONAP POLICY. In other words, each ONAP component has its Release Notes.
   9 ..      * This Release Notes is cumulative, the most recently Released artifact is made visible in the top of
  10 ..      * this Release Notes.
  11 ..      * Except the date and the version number, all the other sections are optional but there must be at least
  12 ..      * one section describing the purpose of this new release.
  13 ..      * This note must be removed after content has been added.
  14
  15
  16 Version: 1.1.3
  17 --------------
  18
  19 :Release Date: 2018-01-18 (Amsterdam Maintenance Release)
  20
  21 **Bug Fixes**
  22
  23 The following bugs were deployed with the Amsterdam Maintenance Release:
  24
  25     * `[POLICY-486] <https://jira.onap.org/browse/POLICY-486>`_ - pdp-x api pushPolicy fails to push latest version
  26
  27
  28 Version: 1.1.1
  29 --------------
  30
  31 :Release Date: 2017-11-16 (Amsterdam Release)
  32
  33 **New Features**
  34
  35 The Amsterdam release continued evolving the design driven architecture of and functionality for POLICY.  The following is a list of Epics delivered with the release. For a full list of stories and tasks delivered in the Amsterdam release, refer to `JiraPolicyReleaseNotes`_.
  36
  37     * [POLICY-31] - Stabilization of Seed Code
  38         - POLICY-25  Replace any remaining openecomp reference by onap
  39         - POLICY-32  JUnit test code coverage
  40         - POLICY-66  PDP-D Feature mechanism enhancements
  41         - POLICY-67  Rainy Day Decision Policy
  42         - POLICY-93  Notification API
  43         - POLICY-158  policy/engine: SQL injection Mitigation
  44         - POLICY-269  Policy API Support for Rainy Day Decision Policy and Dictionaries
  45
  46     * [POLICY-33] - This epic covers the body of work involved in deploying the Policy Platform components
  47         - POLICY-40  MSB Integration
  48         - POLICY-124  Integration with oparent
  49         - POLICY-41  OOM Integration
  50         - POLICY-119  PDP-D: noop sinks
  51
  52     * [POLICY-34] - This epic covers the work required to support a Policy developer environment in which Policy Developers can create, update policy templates/rules separate from the policy Platform runtime platform.
  53         - POLICY-57  VF-C Actor code development
  54         - POLICY-43  Amsterdam Use Case Template
  55         - POLICY-173  Deployment of Operational Policies Documentation
  56
  57     * [POLICY-35] - This epic covers the body of work involved in supporting policy that is platform specific.
  58         - POLICY-68  TOSCA Parsing for nested objects for Microservice Policies
  59
  60     * [POLICY-36] - This epic covers the work required to capture policy during VNF on-boarding.
  61
  62     * [POLICY-37] - This epic covers the work required to capture, update, extend Policy(s) during Service Design.
  63         - POLICY-64  CLAMP Configuration and Operation Policies for vFW Use Case
  64         - POLICY-65  CLAMP Configuration and Operation Policies for vDNS Use Case
  65         - POLICY-48  CLAMP Configuration and Operation Policies for vCPE Use Case
  66         - POLICY-63  CLAMP Configuration and Operation Policies for VOLTE Use Case
  67
  68     * [POLICY-38] - This epic covers the work required to support service distribution by SDC.
  69
  70     * [POLICY-39] - This epic covers the work required to support the Policy Platform during runtime.
  71         - POLICY-61  vFW Use Case - Runtime
  72         - POLICY-62  vDNS Use Case - Runtime
  73         - POLICY-59  vCPE Use Case - Runtime
  74         - POLICY-60  VOLTE Use Case - Runtime
  75         - POLICY-51  Runtime Policy Update Support
  76         - POLICY-328  vDNS Use Case - Runtime Testing
  77         - POLICY-324  vFW Use Case - Runtime Testing
  78         - POLICY-320  VOLTE Use Case - Runtime Testing
  79         - POLICY-316  vCPE Use Case - Runtime Testing
  80
  81     * [POLICY-76] - This epic covers the body of work involved in supporting R1 Amsterdam Milestone Release Planning Milestone Tasks.
  82         - POLICY-77  Functional Test case definition for Control Loops
  83         - POLICY-387  Deliver the released policy artifacts
  84
  85
  86
  87 **Bug Fixes**
  88     - This is technically the first release of POLICY, previous release was the seed code contribution. As such, the defects fixed in this release were raised during the course of the release. Anything not closed is captured below under Known Issues. For a list of defects fixed in the Amsterdam release, refer to `JiraPolicyReleaseNotes`_.
  89
  90 .. _JiraPolicyReleaseNotes: https://jira.onap.org/secure/ReleaseNote.jspa?projectId=10106&version=10300
  91
  92 **Known Issues**
  93     - The operational policy template has been tested with the vFW, vCPE, vDNS and VOLTE use cases.  Additional development may/may not be required for other scenarios.
  94
  95     - For vLBS Use Case, the following steps are required to setup the service instance:
  96         -  Create a Service Instance via VID.
  97         -  Create a VNF Instance via VID.
  98         -  Preload SDNC with topology data used for the actual VNF instantiation (both base and DNS scaling modules). NOTE: you may want to set “vlb_name_0” in the base VF module data to something unique. This is the vLB server name that DCAE will pass to Policy during closed loop. If the same name is used multiple times, the Policy name-query to AAI will show multiple entries, one for each occurrence of that vLB VM name in the OpenStack zone. Note that this is not a limitation, typically server names in a domain are supposed to be unique.
  99         -  Instantiate the base VF module (vLB, vPacketGen, and one vDNS) via VID. NOTE: The name of the VF module MUST start with ``Vfmodule_``. The same name MUST appear in the SDNC preload of the base VF module topology. We’ll relax this naming requirement for Beijing Release.
 100         -  Run heatbridge from the Robot VM using ``Vfmodule_`` … as stack name (it is the actual stack name in OpenStack)
 101         -  Populate AAI with a dummy VF module for vDNS scaling.
 102
 103 **Security Issues**
 104     - None at this time
 105
 106 **Other**
 107     - None at this time
 108
 109
 110 .. note
 111 ..      CHANGE  HISTORY
 112 ..      01/15/2018 - Added change for version 1.1.3 to the Amsterdam branch.  Also corrected prior version (1.2.0) to (1.1.1)
 113 ..      11/16/2017 - Initial document for Amsterdam release.
 114
 115
 116 End of Release Notes
 117
 118
 119