13 files changed, 467 insertions, 3 deletions
diff --git a/docs/docs_5G_Bulk_PM.rst b/docs/docs_5G_Bulk_PM.rst
new file mode 100644
index 000000000..909ba3149
--- /dev/null
+++ b/docs/docs_5G_Bulk_PM.rst
@@ -0,0 +1,26 @@
+5G Bulk PM Use Case
+----------------------------
+
+5G Bulk PM Package
+~~~~~~~~~~~~
+- 5G Bulk PM Package: https://wiki.onap.org/display/DW/5G+-+Bulk+PM+-+Integration+Test+Case
+
+Description
+~~~~~~~~~~~
+The Bulk PM feature consists of an event-driven bulk transfer of monitoring data from an xNF to ONAP/DCAE. A micro-service will listen for 'FileReady' VES events sent from an xNF via the VES collector. Once files become available the collector micro-service will fetch them using protocol such as FTPES (committed) or SFTP. The collected data files are published internally on a DMaaP Data Router (DR) feed. 
+The ONAP 5G Bulk PM Use Case Wiki Page can be found here: 
+https://wiki.onap.org/display/DW/5G+-+Bulk+PM
+
+How to Use
+~~~~~~~~~~
+See the following instructions on how to manually test the feature. https://wiki.onap.org/display/DW/5G+Bulk+PM+Usecase+Testing+@+Ericsson+Lab+-+Casablanca
+The tests can also be executed using the Robot framework, information can be found https://wiki.onap.org/display/DW/5G+-+Bulk+PM+-+Integration+Test+Cases
+
+Test Status and Plans
+~~~~~~~~~~~~~~~~~~~~~
+To see information on the status of the test see https://wiki.onap.org/display/DW/5G+-+Bulk+PM+-+Test+Status
+
+Known Issues and Resolutions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+none.
+
diff --git a/docs/docs_CCVPN.rst b/docs/docs_CCVPN.rst
new file mode 100644
index 000000000..f9fb501c9
--- /dev/null
+++ b/docs/docs_CCVPN.rst
@@ -0,0 +1,127 @@
+CCVPN
+----------------------------
+
+Sevice used for CCVPN 
+~~~~~~~~~~~~
+
+- SOTNVPNInfraService, SDWANVPNInfraService and SIteService: https://wiki.onap.org/display/DW/CCVPN+Service+Design
+- WanConnectionService ( Another way to describe CCVPN in a single service form which based on ONF CIM ): https://wiki.onap.org/display/DW/CCVPN+Wan+Connection+Service+Design
+
+Description
+~~~~~~~~~~~
+Cross-domain, cross-layer VPN (CCVPN) is one of the use cases of the ONAP Casablanca release. This release demonstrates cross-operator ONAP orchestration and interoperability with third party SDN controllers and enables cross-domain, cross-layer and cross-operator service creation and assurance.
+
+The demonstration includes two ONAP instances, one deployed by Vodafone and one by China Mobile, both of which orchestrate the respective operator underlay OTN networks and overlay SD-WAN networks and peer to each other for cross-operator VPN service delivery.
+
+The CCVPN Use Case Wiki Page can be found here: https://wiki.onap.org/display/DW/CCVPN%28Cross+Domain+and+Cross+Layer+VPN%29+USE+CASE.
+
+The projects covered by this use case include: SDC, A&AI, UUI, SO, SDNC, OOF, Policy, DCAE(Holmes), External API, MSB
+
+How to Use
+~~~~~~~~~~
+Design time
+SOTNVPNInfraService, SDWANVPNInfraService and SIteService service Design steps can be found here: https://wiki.onap.org/display/DW/CCVPN+Service+Design
+WanConnectionService ( Another way to describe CCVPN in a single service form which based on ONF CIM ): https://wiki.onap.org/display/DW/CCVPN+Wan+Connection+Service+Design
+
+Run Time:
+All opertion will be triggerd by UUI, inlcuding service creation and termination, link management and topology network display.
+
+
+More details can be fonud here: https://wiki.onap.org/display/DW/CCVPN+Test+Guide
+
+Test Status and Plans
+~~~~~~~~~~~~~~~~~~~~~
+All test case covered by this use case: https://wiki.onap.org/display/DW/CCVPN+Integration+Test+Case
+
+And the test status can be found: https://wiki.onap.org/display/DW/CCVPN++-Test+Status
+
+Known Issues and Resolutions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+1) AAI-1923. Link Management, UUI can't delete the link to external onap otn domain. 
+
+For the manual steps provided by A&AI team, we should follow the steps as follow
+the only way to delete is using the forceDeleteTool shell script in the graphadmin container.
+First we will need to find the vertex id, you should be able to get the id by making the following GET request.
+
+GET /aai/v14/network/ext-aai-networks/ext-aai-network/createAndDelete/esr-system-info/test-esr-system-info-id-val-0?format=raw
+
+::
+
+{
+"results": [
+{
+"id": "20624",
+"node-type": "pserver",
+"url": "/aai/v13/cloud-infrastructure/pservers/pserver/pserverid14503-as988q",
+"properties": {
+}
+}
+]
+}
+
+Same goes for the ext-aai-network:
+
+GET /aai/v14/network/ext-aai-networks/ext-aai-network/createAndDelete?format=raw
+
+Retrieve the id from the above output as that will be the vertex id that you want to remove.
+
+Run the following command multiple times for both the esr-system-info and ext-aai-network:
+
+::
+
+kubectl exec -it $(kubectl get pods -lapp=aai-graphadmin -n onap --template 'range .items.metadata.name"\n"end' | head -1) -n onap gosu aaiadmin /opt/app/aai-graphadmin/scripts/forceDeleteTool.sh -action DELETE_NODE -userId YOUR_ID_ANY_VALUE -vertexId VERTEX_ID
+
+From the above, remove the YOUR_ID_ANY_VALUE and VERTEX_ID with your info.
+
+2) SDC-1955. Site service Distribution
+
+To overcome the Service distribution, the SO catalog has to be populated with the model information of the services and resources.
+a) Refering to the Csar that is generated in the SDC designed as per the detailes mentioned in the below link: https://wiki.onap.org/display/DW/CCVPN+Service+Design
+b) Download the Csar from SDC thus generated.
+c) copy the csar to SO sdc controller pod and bpmn pod
+  kubectl -n onap get pod|grep so
+  kubectl -n onap exec -it dev-so-so-sdc-controller-c949f5fbd-qhfbl  /bin/sh
+
+  mkdir null/ASDC
+  mkdir null/ASDC/1
+  kubectl -n onap cp service-Sdwanvpninfraservice-csar.csar  dev-so-so-bpmn-infra-58796498cf-6pzmz:null/ASDC/1/service-Sdwanvpninfraservice-csar.csar
+  kubectl -n onap cp service-Sdwanvpninfraservice-csar.csar  dev-so-so-bpmn-infra-58796498cf-6pzmz:ASDC/1/service-Sdwanvpninfraservice-csar.csar
+
+d) populate model information to SO db 
+  the db script example can be seen in https://wiki.onap.org/display/DW/Manual+steps+for+CCVPN+Integration+Testing
+
+The same would also be applicable for the integration of the client to create the service and get the details.
+Currently the testing has been performed using the postman calls to the corresponding APIs.
+
+3) SDC-1955 & SDC-1958. Site serivce parsing Error
+
+UUI: stored the csar which created based on beijing release under a fixed directory, If site serive can't parsed by SDC tosca parser, UUI will parse this default csar and get the input parameter
+a) Make an available csar file for CCVPN use case.
+b) Replace uuid of available files with what existing in SDC.
+c) Put available csar files in UUI local path (/home/uui).
+
+4) SO-1248. Csar needs to be manually placed into the bpmn corresponding directory
+
+After SDC distribution success, copy all csar files from so-sdc-controller:
+    connect to so-sdc-controller( eg: kubectl.exe exec -it -n onap dev-so-so-sdc-controller-77df99bbc9-stqdz /bin/sh )
+    find out all csar files ( eg: find / -name '*.csar' )
+    the csar files should be in this path: /app/null/ASDC/ ( eg: /app/null/ASDC/1/service-Sotnvpninfraservice-csar.csar )
+    exit from the so-sdc-controller ( eg: exit )
+    copy all csar files to local derectory ( eg: kubectl.exe cp onap/dev-so-so-sdc-controller-6dfdbff76c-64nf9:/app/null/ASDC/tmp/service-DemoService-csar.csar service-DemoService-csar.csar -c so-sdc-controller )
+    
+Copy csar files, which got from so-sdc-controller, to so-bpmn-infra
+    connect to so-bpmn-infra ( eg: kubectl.exe -n onap exec -it dev-so-so-bpmn-infra-54db5cd955-h7f5s -c so-bpmn-infra /bin/sh )
+    check the /app/ASDC deretory, if doesn't exist, create it ( eg: mkdir /app/ASDC -p )
+    exit from the so-bpmn-infra ( eg: exit )
+    copy all csar files to so-bpmn-infra ( eg: kubectl.exe cp service-Siteservice-csar.csar onap/dev-so-so-bpmn-infra-54db5cd955-h7f5s:/app/ASDC/1/service-Siteservice-csar.csar )
+
+5) Manual steps in closed loop Scenario:
+Following steps were undertaken for the closed loop testing.
+a. Give controller ip, username and password, trust store and key store file in restconf collector collector.properties
+b. Updated DMAAP ip in cambria.hosts in DmaapConfig.json in restconf collector and run restconf collector
+c. Followed the steps provided in this link(https://wiki.onap.org/display/DW/Holmes+User+Guide+-+Casablanca#HolmesUserGuide-Casablanca-Configurations) to push CCVPN rules to holmes
+d. Followed the steps provided in this link(https://wiki.onap.org/display/DW/ONAP+Policy+Framework%3A+Installation+of+Amsterdam+Controller+and+vCPE+Policy) as reference to push CCVPN policies to policy module and updated sdnc.url, username and password in environment(/opt/app/policy/config/controlloop.properties.environment)
+As per wiki (Policy on OOM), push-policied.sh script is used to install policies. but I observed that CCVPN policy is not added in this script. So merged CCVPN policy using POLICY-1356 JIRA ticket. but policy is pushed by using push-policy_casablanca.sh script during integration test.
+It is found that the changes made were overwritten and hence had to patch the DG manually. This will be tracked by the JIRA SDNC-540.
+
+all above manual steps can be found  https://wiki.onap.org/display/DW/Manual+steps+for+CCVPN+Integration+Testing
+\ No newline at end of file
diff --git a/docs/docs_scaleout.rst b/docs/docs_scaleout.rst
index 5d829bdd1..0d4e38777 100644
--- a/docs/docs_scaleout.rst
+++ b/docs/docs_scaleout.rst
@@ -1,3 +1,5 @@
+.. _docs_scaleout:
+
 VF Module Scale Out Use Case
 ----------------------------
 
@@ -12,7 +14,7 @@ Source files
 
 Description
 ~~~~~~~~~~~
-The Scale Out use case shows how users/network operators can add capacity to an existing VNF. ONAP Casablanca release supports scale out with manual trigger from VID and closed-loop enabled automation from Policy. This is demonstrated against the vLB/vDNS VNFs. For Casablanca, both APPC and SDNC controllers are supported. APPC is the official controller used for this use case and it can be used to scale multiple VNF types. SDNC is experimental for now and it can scale only the vDNS VNF developed for ONAP.
+The Scale Out use case shows how users/network operators can add Virtual Network Function Components (VNFCs) as part of a VF Module that has been instantiated in the Service model to an existing VNF, in order to increase capacity of the network. ONAP Casablanca release supports scale out with manual trigger from VID and closed-loop enabled automation from Policy. This is demonstrated against the vLB/vDNS VNFs developed for ONAP. For Casablanca, both APPC and SDNC controllers are used to demonstrate accepting request from SO to execute the Scale Out operation. APPC is the main controller used for this use case and it can be used to scale different VNF types. SDNC is experimental for now and it can scale only the vDNS VNF developed for ONAP.
 
 The Casablanca Scaling Use Case Wiki Page can be found here: https://wiki.onap.org/display/DW/Scaling+Use+Case+Extension
 
diff --git a/docs/docs_usecases.rst b/docs/docs_usecases.rst
new file mode 100644
index 000000000..1d649bc86
--- /dev/null
+++ b/docs/docs_usecases.rst
@@ -0,0 +1,24 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _docs_usecases:
+
+Use Cases Verified at Casablanca Release
+----------------------------------------
+
+Description
+~~~~~~~~~~~
+This session includes use cases have been tested in Casablanca release by Integration team:
+    1. How to run them
+    2. Known issues and workaround
+
+Use Cases
+~~~~~~~~~
+:ref:`vFirewall Use Case <docs_vfw>`
+
+:ref:`vLoadBalancer Use Case <docs_vlb>`
+
+:ref:`vCPE with Tosca VNF Use Case <docs_vcpe_tosca>`
+
+:ref:`vFW with HPA Use Case <docs_vfw_hpa>`
+
+:ref:`VF Module Scale Out Use Case <docs_scaleout>`
+\ No newline at end of file
diff --git a/docs/docs_vCPE with Tosca VNF.rst b/docs/docs_vCPE with Tosca VNF.rst
index a30ba8084..75aefdad2 100644
--- a/docs/docs_vCPE with Tosca VNF.rst
+++ b/docs/docs_vCPE with Tosca VNF.rst
@@ -1,3 +1,5 @@
+.. _docs_vcpe_tosca:
+
 vCPE with Tosca VNF
 ----------------------------
 
diff --git a/docs/docs_vCPE.rst b/docs/docs_vCPE.rst
new file mode 100644
index 000000000..b7e67173c
--- /dev/null
+++ b/docs/docs_vCPE.rst
@@ -0,0 +1,36 @@
+vCPE Use Case
+----------------------------
+
+Description
+~~~~~~~~~~~
+vCPE use case is based on Network Enhanced Residential Gateway architecture specified in Technical Report 317 (TR-317), which defines how service providers deploy residential broadband services like High Speed Internet Access. The use case implementation has infrastructure services and customer service. The common infrastructure services are deployed first and shared by all customers. The use case demonstrates ONAP capabilities to design, deploy, configure and control sophisticated services.      
+
+More details on the vCPE Use Case can be found on wiki page https://wiki.onap.org/pages/viewpage.action?pageId=3246168
+
+Source Code
+~~~~~~~~~~~
+vcpe test scripts: https://gerrit.onap.org/r/gitweb?p=integration.git;a=tree;f=test/vcpe;h=76572f4912e7b375e1e4d0177a0e50a61691dc4a;hb=refs/heads/casablanca
+
+How to Use
+~~~~~~~~~~
+Most part of the use case has been automated by vcpe scripts. For the details on how to run the scripts, please refer to the use case tutorial on https://wiki.onap.org/display/DW/vCPE+Use+Case+Tutorial%3A+Design+and+Deploy+based+on+ONAP.
+
+Test Status
+~~~~~~~~~~~~~~~~~~~~~
+The use case has been tested for Casablanca release, the test report can be found on https://wiki.onap.org/display/DW/vCPE+-+Test+Status
+
+Known Issues and Workaround
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+1) Firewalls are installed on BRG and vBNG. In order to allow SDNC to send BRG configuration message through vBNG, SDNC host VM IP address is preloaded on BRG and vBNG, and provisioned into the firewalls. If SDNC changes its host VM, SDNC host VM IP changes and we need to manually update the IP in /opt/config/sdnc_ip.txt. Then run:
+
+::
+
+  root>vppctl tap delete tap-0
+  root>vppctl tap delete tap-1
+  root>/opt/nat_service.sh
+  root>vppctl restart
+
+2) APPC has a bug which prevents DG from reading AAI info. We needs an DG update. See the JIRA on https://jira.onap.org/browse/APPC-1249
+
+3) In closed loop, APPC fails to send response back to Policy via an DMAAP message. Policy will keep sending reboot action request until timed out or ABATED message is received. User may see 3 or 4 vGMUX reboots before service returns normal. See the JIRA on https://jira.onap.org/browse/APPC-1247
+
diff --git a/docs/docs_vcpe_tosca.rst b/docs/docs_vcpe_tosca.rst
new file mode 100644
index 000000000..faa4e7590
--- /dev/null
+++ b/docs/docs_vcpe_tosca.rst
@@ -0,0 +1,136 @@
+vCPE of Tosca Use Case
+----------------------
+
+Source files
+~~~~~~~~~~~
+
+vCPE tosca file url: https://git.onap.org/demo/tree/tosca/vCPE
+
+5 VNFs are here for the ONAP vCPE use case. This VNFD is transformed manually from vCPE heat template.
+Please run "./generate_csar.sh" to create the CSAR package files for these 5 VNFS. CSAR package file is just a zip formatted file. If you want to use SRIOV SRIOV-NIC", please run "./generate_csar.sh sriov" to create the CSAR package files for SRIOV.
+
+
+Description
+~~~~~~~~~~
+
+The use case is composed of five virtual functions (VFs): Infrastructure including vDNS, vDHCP, vAAA(Authorization, Authentication, Accounting) and
+vWEB, vBNG(Virtual Broadband Network Gateway), vGMUX(Virtual Gateway Multiplexer), vBRGEMU(Bridged Residential Gateway) and vGW(Virtual Gateway).
+Infrastructure VF run in one VM. the other VFs run in separate four VMs. We will send much data from vBRGEMU to vGW. we need to accelarate it using SRIOV-NIC.
+
+
+Test Plan:
+~~~~~~~~~~~~~~~~~~
+
+The test plan 3 in https://wiki.onap.org/pages/viewpage.action?pageId=41421112.
+Test Plan 3: VF-C HPA testing
+This test plan covers the tests related to testing
+Support for the vCPE use case in VF-C
+
+Use vCPE (Infra, vGW, vBNG, vBRGEMU and vGMUX)
+
+Infra part of  policy asking for:
+::
+
+  2 vcpus
+  >= 2Gbytes of memory
+  > 40Gbytes of disk
+
+vGW part of policy asking for:
+::
+
+  2 vcpus
+  >=4Gbytes of memory
+  >= 40Gbytes of disk
+  Numa page size: 2Mbytes and pages 1024
+  with one SRIOV-NIC
+
+vBNG part of policy asking for:
+::
+
+  2 vcpus
+  >= 2Gbytes of memory
+  > 40Gbytes of disk
+  Numa page size: 2Mbytes and pages 1024
+  with one SRIOV-NIC
+
+vBGREMU part of policy asking for:
+::
+
+  2 vcpus
+  >= 2Gbytes of memory
+  >= 40Gbytes of disk
+  Numa page size: 2Mbytes and pages 1024
+  with one SRIOV-NIC
+
+vGMUX part of policy asking for:
+::
+
+  2 vcpus
+  >= 2Gbytes of memory
+  > 40Gbytes of disk
+  Numa page size: 2Mbytes and pages 1024
+  with one SRIOV-NIC
+
+Instantiate the VNF
+Check for results:
+It would have selected flavor13 for vGW, vBNG, vBRGEMU and vGMUX VMs. It would have selected flavor13 and flavor12 for Infrastructure.
+
+Test Steps:
+~~~~~~~~~~
+
+VIM Configuration:
+^^^^^^^^^^^^^^^^^^
+
+If you want to use SRIOV-NIC, you need first config SRIOV NIC to refer to [1].
+[1] https://docs.openstack.org/ocata/networking-guide/config-sriov.html
+
+ONAP managing 1 cloud-region which have three flavors.
+Flavor 11:
+2 vcpus, 1 Gbytes of memory, 20Gb disk
+Numa page size: 2Mbytes and number pages 512
+::
+
+  openstack flavor create onap.hpa.flavor11 -id auto --ram 1024 --disk 20 --vcpus 2
+
+Flavor 12:
+2 vcpus, 2 Gbytes of memory, 20Gb disk
+Numa page size: 2Mbytes and number pages 1024
+::
+
+  openstack flavor create onap.hpa.flavor12 -id auto --ram 2048 --disk 20 --vcpus 2
+
+Flavor 13:
+2 vcpus, 4 Gbytes of memory, 20Gb disk
+Huge page size: 2Mbytes and number pages 2048
+1 SRIOV-NIC VF
+::
+
+  openstack flavor create onap.hpa.flavor13 -id auto --ram 4096 --disk 20 -vcpus 2
+  openstack flavor set onap.hpa.flavor11 --property aggregate_instance_extra_specs:sriov_nic=sriov-nic-intel-1234-5678-physnet1:1
+  openstack aggregate create --property sriov_nic=sriov-nic-intel-1234-5678-physnet1:1 hpa_aggr11
+
+comments: you must change 1234 and 5678 to real vendor id and product id. you also need change physnet1 to the provider network.
+
+Policy Configuration:
+^^^^^^^^^^^^^^^^^^^^^
+
+After the patch https://gerrit.onap.org/r/#/c/73502/ is merged. With the generated policy and do some manually update as follows, the service could be distributed successfully and the Policy/VFC/OOF could work as excepted.
+
+- Need manually modify policy item because the “vendor id” and “PCI device id” and “architecture” must be changed in different VIMs since we have different PCI devices in different VIMs
+- The value of mandatory in CSAR is “true”, OOF is case intensive, it needs to use “True”. Have to update it. suggest OOF to use ignoreCase in R4.
+- The attribute key in CSAR is pciNumDevices, but the responding one in OOF/Mutlicloud is pciCount.  Suggest keeping alignment in R4.
+- The policy scope has to add a value “us” into it which is a configuration issue in OOF side. Policy side also need do improvement to deal with policy scope automatically append instead of replacement so such policy could be used by several services at the same time.
+
+
+Running the Use Case
+~~~~~~~~~~~~~~~~~~~
+
+We design vCPE in SDC and distribute it to VFC and Policy and UUI. We can click onboarding VNF and onboarding NS. we can instance it.
+
+Known issues and resolution
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- Some SDC NS data model is not aligned to VFC NS data model, VFC NS also according to ETSI SOL0001. we also can refer to https://jira.onap.org/browse/SDC-1897. we have a workaround for this issue, we put the service as artifact file and distribute to VFC.
+- NFV Tosca parser bug https://jira.opnfv.org/browse/PARSER-187. we also filed a bug in VFC https://jira.onap.org/browse/VFC-1196.
+- 'artifacts' definition is missing in the exported csar's VDU node, we also can refer to https://jira.onap.org/browse/SDC-1900. It’s a very hacky workaround in VFC’s GVFNM. Because currently the only use case will use GVFNM is vCPE, which only uses the ubuntu16.04 image, so GVFNM just makes the ubuntu16.04 image as the default if the "sw_image" artifact is missing in the SDC’s exported CSAR.
+- OOF patch https://gerrit.onap.org/r/#/c/73332/ is not accepted by 1.2.4 image.It will be accepted by 1.2.5 image. but 1.2.5 image is not release. If you want to use it, you can use 1.2.5-SNAPSHOT-latest. If you use 1.2.4 image, you also need to modify code according to the patch.
diff --git a/docs/docs_vfw.rst b/docs/docs_vfw.rst
index af47c464b..a722c67d5 100644
--- a/docs/docs_vfw.rst
+++ b/docs/docs_vfw.rst
@@ -1,3 +1,5 @@
+.. _docs_vfw:
+
 vFirewall Use Case
 ------------------
 
diff --git a/docs/docs_vfwHPA.rst b/docs/docs_vfwHPA.rst
index 072b25294..87661c12b 100644
--- a/docs/docs_vfwHPA.rst
+++ b/docs/docs_vfwHPA.rst
@@ -2,6 +2,8 @@
 .. http://creativecommons.org/licenses/by/4.0
 .. Copyright 2018 ONAP
 
+.. _docs_vfw_hpa:
+
 vFW with HPA Tutorial: Setting Up and Configuration
 ----------------------------------------------------
 
diff --git a/docs/docs_vlb.rst b/docs/docs_vlb.rst
index 07671cd75..ded308f05 100644
--- a/docs/docs_vlb.rst
+++ b/docs/docs_vlb.rst
@@ -1,3 +1,5 @@
+.. _docs_vlb:
+
 vLoadBalancer Use Case
 ----------------------
 
diff --git a/docs/release-notes.rst b/docs/release-notes.rst
new file mode 100644
index 000000000..3da3edda3
--- /dev/null
+++ b/docs/release-notes.rst
@@ -0,0 +1,105 @@
+
+.. This work is licensed under a Creative Commons Attribution 4.0
+   International License. http://creativecommons.org/licenses/by/4.0
+   Copyright 2018 Huawei Technologies Co., Ltd.  All rights reserved.
+
+.. _doc-release-notes:
+
+Integration Release Notes
+=============
+
+
+Integration Repo
+================
+
+Version: 3.0.0
+--------------
+
+:Release Date: 2018-11-29
+
+**New Features**
+
+* Enahanced deployment scripts and HEAT template for automated deployment of OOM onto a HA-enabled Kubernetes cluster
+* Updated scripts for OOM daily automated deployment tests
+* Added various helper scripts and configuration files for assisting the ONAP community's work on the various OpenLab test environments
+* Updated docker and java artifact versions for ONAP Casablanca release
+* Additional enhancements to automation test scripts for vCPE use case
+* Moved CSIT content to a separate integration/csit repo
+* Updates and enhancements to the CSIT test plans across projects to support the ONAP Casablanca use cases
+
+
+
+O-Parent
+========
+
+Version: 1.2.2
+--------------
+
+:Release Date: 2018-11-11
+
+**Bug Fixes**
+
+* Updated Spring dependency version to fix CLM issues
+* Remove hard-coding of ONAP nexus repos
+
+
+Version: 1.2.1
+--------------
+
+:Release Date: 2018-09-14
+
+**New Features**
+
+* Refactor oparent pom to support running builds against local nexus
+  repos without having to modify oparent source code
+* Standardize 3rd party library versions
+
+Version: 1.2.0
+--------------
+
+:Release Date: 2018-08-24
+
+**New Features**
+
+* Add depedencyManagement sub-module to declare dependecies
+
+
+Demo Artifacts (HEAT Templates)
+==============
+
+Version: 1.3.0
+--------------
+
+:Release Date: 2018-11-15
+
+**New Features**
+
+The main changes for this release are the additional templates and
+other changes to support Use Cases such as HPA, vCPE, Scale-out,
+and TOSCA templates.
+
+
+Robot Test Suite
+===========
+
+Version: 1.3.2
+--------------
+
+:Release Date: 2018-11-20
+
+**New Features**
+
+* Fully automated vFW Closed Loop instantiation and testing
+* Instantiaion of 5 new vCPE models
+
+
+Version: 1.3.1
+--------------
+
+:Release Date: 2018-11-14
+
+**New Features**
+
+* Additional health checks for new ONAP components in Casablanca
+* New ETE test suite to test Portal functionality
+* Various enhancements to improve stability of Robot tests
diff --git a/version-manifest/pom.xml b/version-manifest/pom.xml
index 48dd9c12a..ba3f88fed 100644
--- a/version-manifest/pom.xml
+++ b/version-manifest/pom.xml
@@ -8,7 +8,7 @@
   </parent>
   <groupId>org.onap.integration</groupId>
   <artifactId>version-manifest</artifactId>
-  <version>3.0.0-SNAPSHOT</version>
+  <version>3.0.1-SNAPSHOT</version>
   <packaging>maven-plugin</packaging>
   <name>ONAP Version Manifest and Maven Plugin</name>
   <url>https://www.onap.org</url>
diff --git a/version.properties b/version.properties
index ddc6dd849..9ef04d692 100644
--- a/version.properties
+++ b/version.properties
@@ -5,7 +5,7 @@
 
 major_version=3
 minor_version=0
-patch_version=0
+patch_version=1
 
 base_version=${major_version}.${minor_version}.${patch_version}