Merge "Updated release notes"v1.1.11.0.0-ONAP1.0.0-Amsterdam

2 files changed, 51 insertions, 2 deletions

diff --git a/docs/platform/guardpdp.rst b/docs/platform/guardpdp.rst
index f53357bbd..9bc59f3bd 100644
--- a/docs/platform/guardpdp.rst
+++ b/docs/platform/guardpdp.rst
@@ -33,7 +33,7 @@ Guard Properties
     - For testing this URL before running policy, see Verification below.
 
 **guard.jdbc.url** - URL of the database location to which the operations history will be written.
-    - For example, *mariadb://mariadb:3306/onap_sdk*.
+    - For example, *jdbc:mariadb://mariadb:3306/onap_sdk*.
     - Note that the port is included.
     - Note that at the end, the database name is used.
 
diff --git a/docs/release-notes.rst b/docs/release-notes.rst
index 8b15232c6..bd688683c 100644
--- a/docs/release-notes.rst
+++ b/docs/release-notes.rst
@@ -22,14 +22,53 @@ Version: 1.2.0
 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`_.
 
     * [POLICY-31] - Stabilization of Seed Code
+        - POLICY-25  Replace any remaining openecomp reference by onap
+        - POLICY-32  JUnit test code coverage
+        - POLICY-66  PDP-D Feature mechanism enhancements
+        - POLICY-67  Rainy Day Decision Policy
+        - POLICY-93  Notification API
+        - POLICY-158  policy/engine: SQL injection Mitigation
+        - POLICY-269  Policy API Support for Rainy Day Decision Policy and Dictionaries  
+
     * [POLICY-33] - This epic covers the body of work involved in deploying the Policy Platform components
+        - POLICY-40  MSB Integration  
+        - POLICY-124  Integration with oparent  
+        - POLICY-41  OOM Integration  
+        - POLICY-119  PDP-D: noop sinks  
+
     * [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.
+        - POLICY-57  VF-C Actor code development  
+        - POLICY-43  Amsterdam Use Case Template  
+        - POLICY-173  Deployment of Operational Policies Documentation  
+
     * [POLICY-35] - This epic covers the body of work involved in supporting policy that is platform specific.
+        - POLICY-68  TOSCA Parsing for nested objects for Microservice Policies  
+
     * [POLICY-36] - This epic covers the work required to capture policy during VNF on-boarding.
+
     * [POLICY-37] - This epic covers the work required to capture, update, extend Policy(s) during Service Design.
+        - POLICY-64  CLAMP Configuration and Operation Policies for vFW Use Case  
+        - POLICY-65  CLAMP Configuration and Operation Policies for vDNS Use Case  
+        - POLICY-48  CLAMP Configuration and Operation Policies for vCPE Use Case 
+        - POLICY-63  CLAMP Configuration and Operation Policies for VOLTE Use Case  
+
     * [POLICY-38] - This epic covers the work required to support service distribution by SDC.
+
     * [POLICY-39] - This epic covers the work required to support the Policy Platform during runtime.
+        - POLICY-61  vFW Use Case - Runtime  
+        - POLICY-62  vDNS Use Case - Runtime  
+        - POLICY-59  vCPE Use Case - Runtime  
+        - POLICY-60  VOLTE Use Case - Runtime  
+        - POLICY-51  Runtime Policy Update Support  
+        - POLICY-328  vDNS Use Case - Runtime Testing  
+        - POLICY-324  vFW Use Case - Runtime Testing  
+        - POLICY-320  VOLTE Use Case - Runtime Testing  
+        - POLICY-316  vCPE Use Case - Runtime Testing  
+
     * [POLICY-76] - This epic covers the body of work involved in supporting R1 Amsterdam Milestone Release Planning Milestone Tasks.
+        - POLICY-77  Functional Test case definition for Control Loops  
+        - POLICY-387  Deliver the released policy artifacts  
+
 
 
 **Bug Fixes**
@@ -38,7 +77,15 @@ The Amsterdam release continued evolving the design driven architecture of and f
 .. _JiraPolicyReleaseNotes: https://jira.onap.org/secure/ReleaseNote.jspa?projectId=10106&version=10300
 
 **Known Issues**
-    - None at this time
+    - 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.
+
+    - For vLBS Use Case, the following steps are required to setup the service instance:
+       	-  Create a Service Instance via VID.
+        -  Create a VNF Instance via VID.
+        -  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.
+        -  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.
+        -  Run heatbridge from the Robot VM using Vfmodule_ … as stack name (it is the actual stack name in OpenStack)
+        -  Populate AAI with a dummy VF module for vDNS scaling.
 
 **Security Issues**
     - None at this time
@@ -48,3 +95,5 @@ The Amsterdam release continued evolving the design driven architecture of and f
 
 End of Release Notes
 
+
+