Merge "update the SO image details" into casablanca
diff --git a/docs/docs_5G_PNF_Software_Upgrade.rst b/docs/docs_5G_PNF_Software_Upgrade.rst
new file mode 100644
index 0000000..75977d8
--- /dev/null
+++ b/docs/docs_5G_PNF_Software_Upgrade.rst
@@ -0,0 +1,56 @@
+5G PNF Software Upgrade
+----------------------------
+
+Description
+~~~~~~~~~~~
+The 5G PNF Software upgrade use case shows how users/network operators can modify the software running on an existing PNF. This use case is one aspect of Software Management. This could be used to update the PNF software to a newer or older version of software.
+
+The Casablanca 5G PNF Software Upgrade Use Case Wiki Page can be found here: https://wiki.onap.org/display/DW/5G+-+PNF+Software+Update
+
+How to Use
+~~~~~~~~~~
+Upgrading PNF (instance) software requires the user/network operator to trigger the upgrade operation from the UI, e.g. VID or UUI. In Cacablanca, users need use ONAP Controllers GUI to trigger the LCM opeations, like pre-check, post-check and upgrade. After receiving the API requests, the ONAP controllers will communicate to the external controller(EC) through south-bound adaptors, which is Ansible in R3.
+
+Note that, both APPC and SDNC in R3 supported Ansible. Taking SDNC and Prechecking as an example, the steps are as follows:
+
+1) In ansible server container, prepare the ssh connection conditions to the external controller, both ssh key file and ansible inventory configuration;
+
+2) In sdnc controller container, update the dg configuration file: lcm-dg.properties.
+For example:
+::
+lcm.pnf.upgrade-pre-check.playbookname=ansible_huawei_precheck
+lcm.pnf.upgrade-post-check.playbookname=ansible_huawei_postcheck
+lcm.pnf.upgrade-software.playbookname=ansible_huawei_upgrade
+
+3) Login controller UI, access the pre-check LCM operation and send request.
+Post upgrade-pre-check with the following request body:
+::
+{
+ "input": {
+ "common-header": {
+ "timestamp": "2018-10-10T09:40:04.244Z",
+ "api-ver": "2.00",
+ "originator-id": "664be3d2-6c12-4f4b-a3e7-c349acced203",
+ "request-id":"664be3d2-6c12-4f4b-a3e7-c349acced203",
+ "sub-request-id": "1",
+ "flags": {
+ "force" : "TRUE",
+ "ttl" : 60000
+ }
+ },
+ "action": "UpgradePreCheck",
+ "action-identifiers": {
+ "vnf-id":"5gDU0001"
+ },
+ "payload": "{\"pnf-flag\":\"true\", \"pnf-name\": \"5gDU0001\",\"pnfId\": \"5gDU0001\", \"ipaddress-v4-oam\": \"EC_IP_address\",\"oldSwVersion\": \"v1\", \"targetSwVersion\": \"v2\", \"ruleName\": \"r001\", \"Id\": \"10\", \"additionalData\":\"{}\"}"}}
+
+4) The HTTP API response code 200 and LCM retured code 400 (See APPC return code design specification) indicate success, otherwise failed.
+
+Test Status and Plans
+~~~~~~~~~~~~~~~~~~~~~
+To see information on the status of the test see: https://wiki.onap.org/display/DW/5G+-+PNF+Software+Update+Test+Status
+
+Known Issues and Resolutions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+None
+
diff --git a/docs/docs_5g_pnf_pnp.rst b/docs/docs_5g_pnf_pnp.rst
new file mode 100644
index 0000000..1874bae
--- /dev/null
+++ b/docs/docs_5g_pnf_pnp.rst
@@ -0,0 +1,61 @@
+5G - PNF Plug and Play
+----------------------
+
+Source files
+~~~~~~~~~~~~
+
+- Base PnP PNF Simulator heat template file: https://git.onap.org/integration/tree/test/mocks/pnfsimulator/deployment/PnP_PNF_sim_heat_template_Ubuntu_16_04.yml
+
+Description
+~~~~~~~~~~~
+
+The PNF PnP flow is a method, which allows to register within ONAP/AAI a PNF resource instance.
+This PNF resource instance is correlated with an existing service instance.
+PNF Plug and Play is used to register a PNF when it comes on-line.
+This use case is intended to be applicable to a variety of PNFs such as routers and 5G base stations.
+The steps and descriptions have been drafted to be as general as possible and to be applicable
+to a relatively wide variety of PNFs. However, the use case was originally developed with a consideration
+for 5G PNF Distributed Units (DU).
+
+**Useful Links**
+
+- `5G - PNF Plug and Play use case documentation <https://wiki.onap.org/display/DW/5G+-+PNF+Plug+and+Play>`_
+- `5G - PNF Plug and Play - Integration Test Cases <https://wiki.onap.org/display/DW/5G+-+PNF+PnP+-+Integration+Test+Cases>`_
+- `5G - PNF Plug and Play test cases status for Casablanca release <https://wiki.onap.org/display/DW/5G+-+PNF+PnP+-+Test+Status>`_
+- `Instruction how to setup PnP PNF Simulator <https://wiki.onap.org/display/DW/PnP+PNF+Simulator>`_
+
+How to Use
+~~~~~~~~~~
+
+1) `Create and distribute service model which contains PNF <https://wiki.onap.org/display/DW/5G+-+PNF+PnP+-+Integration+Test+Cases#id-5G-PNFPnP-IntegrationTestCases-CreateanddistributeservicewhichcontainsPNF>`_
+2) `Create service for PNF and wait for PNF Ready message in DmaaP topic <https://wiki.onap.org/display/DW/5G+-+PNF+PnP+-+Integration+Test+Cases#id-5G-PNFPnP-IntegrationTestCases-PNFReady>`_
+3) `Send PNF Registartion request from PnP PNF Simualtor and finish registration <https://wiki.onap.org/display/DW/5G+-+PNF+PnP+-+Integration+Test+Cases#id-5G-PNFPnP-IntegrationTestCases-PNFregistrationacceptingwhenAAIentrycreatedinadvance>`_
+
+
+Known Issues and Resolutions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In SO BPMN in mechanism making re-subscription to /events/unauthenticated.PNF_READY topic there is an issue `SO-1253 <https://jira.onap.org/projects/SO/issues/SO-1253>`_.
+By default after ONAP and PRH deploy DMaaP topic /events/unauthenticated.PNF_READY is not present.
+It is created by PRH after first expected PNF registration event arrival to ONAP system.
+If service for PNF will be created before topic /events/unauthenticated.PNF_READY will be present then service will not be able to read from the topic.
+
+
+**Workaround**
+
+- Before starting any PNF service verify if unauthenticated.PNF_READY topic exists using command:
+
+::
+
+ curl --header "Content-type: application/json" --request GET http://<kubernetes slave IP>:30227/topics/listAll
+
+- If it doesn't exists send following curl in order to create topic:
+
+::
+
+ curl --header "Content-type: application/json" --request POST --data '[{"correlationId": "test"}]' http://<kubernetes slave IP>:30227/events/unauthenticated.PNF_READY
+
+- Once again verify if topic exists
+- If the PNF service will be started before unauthenticated.PNF_READY topic creation, then there will be a need to restart SO-BPMN docker container
+
+
diff --git a/docs/docs_scaleout.rst b/docs/docs_scaleout.rst
index 987186d..0d4e387 100644
--- a/docs/docs_scaleout.rst
+++ b/docs/docs_scaleout.rst
@@ -14,7 +14,7 @@
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
index 1d649bc..34ecf77 100644
--- a/docs/docs_usecases.rst
+++ b/docs/docs_usecases.rst
@@ -1,4 +1,6 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. 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.
.. _docs_usecases:
diff --git a/docs/docs_vcpe_tosca.rst b/docs/docs_vcpe_tosca.rst
new file mode 100644
index 0000000..faa4e75
--- /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/integration-s3p.rst b/docs/integration-s3p.rst
new file mode 100644
index 0000000..70d6931
--- /dev/null
+++ b/docs/integration-s3p.rst
@@ -0,0 +1,81 @@
+.. _integration-s3p:
+
+ONAP Casablanca S3P Improvements
+--------------------------------
+
+For the Casablanca release, ONAP continues to improve in multiple
+areas of Scalability, Security, Stability and Performance (S3P)
+metrics.
+
+
+
+Stability
+=========
+Integration Stability Testing verifies that the ONAP platform remains fully functional after running for an extended amounts of time. This is done by repeated running tests against an ONAP instance for a period of 72 hours.
+
+Methodology
+~~~~~~~~~~~
+
+The Stability Test has two main components:
+
+- Running "ete stability72hr" Robot suite periodically. This test suite verifies that ONAP can instantiate vDNS, vFWCL, and VVG.
+- Set up vFW Closed Loop to remain running, then check periodically that the closed loop functionality is still working.
+
+Detailed instructions on how these tests are run can be found at https://wiki.onap.org/display/DW/Casablanca+Stability+Testing+Instructions .
+
+Results: 100% PASS
+~~~~~~~~~~~~~~~~~~
+=============== ======== ========= =========
+Test Case Attempts Successes Pass Rate
+=============== ======== ========= =========
+Stability72hr 65 65 100%
+vFW Closed Loop 71 71 100%
+**Total** 136 136 **100%**
+=============== ======== ========= =========
+
+Detailed results can be found at https://wiki.onap.org/display/DW/Casablanca+Release+Stability+Testing+Status .
+
+.. note::
+ - The Wind River lab OpenStack instance sporadically returns authentication failures or dropped network connections under load. The
+ Stability72hr test runs that failed due to these known infrastructure issues were discarded.
+ - The Packet Generator VNF used in the vFW Closed Loop test becomes unstable after long run-times. The vFWCL test runs that failed
+ due to Packet Generator failures (which are not ONAP platform failures) were discarded.
+
+
+Resilience
+==========
+
+Integration Resilience Testing verifies that ONAP can automatically recover from failures of any of its components. This is done by deleting the ONAP pods that are involved in each particular Use Case flow and then checking that the Use Case flow can again be executed successfully after ONAP recovers.
+
+Methodology
+~~~~~~~~~~~
+For each Use Case, a list of the ONAP components involved is identified. The pods of each of those components are systematically deleted one-by-one; after each pod deletion, we wait for the pods to recover, then execute the Use Case again to verify successful ONAP platform recovery.
+
+
+Results: 96.9% PASS
+~~~~~~~~~~~~~~~~~~~
+=============================== ======== ========= =========
+Use Case Attempts Successes Pass Rate
+=============================== ======== ========= =========
+VNF Onboarding and Distribution 45 44 97.8%
+VNF Instantiation 54 52 96.3%
+vFW Closed Loop 61 59 96.7%
+**Total** 160 155 **96.9%**
+=============================== ======== ========= =========
+
+Detailed results can be found at https://wiki.onap.org/display/DW/Casablanca+Release+Stability+Testing+Status .
+
+
+Deployability
+=============
+
+Smaller ONAP container images footprint reduces resource consumption,
+time to deploy, time to heal, as well as scale out resources.
+
+Minimizing the footprint of ONAP container images reduces resource
+consumption, time to deploy, time and time to heal. It also reduces
+the resources needed to scale out and time to scale in. For those
+reasons footprint minimization postively impacts the scalability of
+the ONAP platform. Smaller ONAP container images footprint reduces
+resource consumption, time to deploy, time to heal, as well as scale
+out resources.
diff --git a/docs/onap-oom-heat.rst b/docs/onap-oom-heat.rst
index cc9ceb7..f6d1e35 100644
--- a/docs/onap-oom-heat.rst
+++ b/docs/onap-oom-heat.rst
@@ -23,6 +23,7 @@
The ONAP OOM HEAT template deploys the entire ONAP platform. It spins
up an HA-enabled Kubernetes cluster, and deploys ONAP using OOM onto
this cluster.
+
- 1 Rancher VM that also serves as a shared NFS server
- 3 etcd VMs for the Kubernetes HA etcd plane
- 2 orch VMs for the Kubernetes HA orchestration plane
diff --git a/docs/release-notes.rst b/docs/release-notes.rst
index 3da3edd..f1b860b 100644
--- a/docs/release-notes.rst
+++ b/docs/release-notes.rst
@@ -6,7 +6,7 @@
.. _doc-release-notes:
Integration Release Notes
-=============
+=========================
Integration Repo
@@ -15,18 +15,30 @@
Version: 3.0.0
--------------
-:Release Date: 2018-11-29
+:Release Date: 2018-11-30
**New Features**
-* Enahanced deployment scripts and HEAT template for automated deployment of OOM onto a HA-enabled Kubernetes cluster
+* CI/CD with daily summary: `functional tests and health checks <http://onapci.org/grafana/d/8cGRqBOmz/daily-summary>`_.
+* Container optimization through Integration sub-projectCIA project release notes
+* Enhanced 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
+* Offline deployment: deploy ONAP without direct internet access for Beijing release
+**Security Notes**
+
+Integration code has been formally scanned during build time using NexusIQ and all Critical vulnerabilities have been addressed, items that remain open have been assessed for risk and actions to be taken in future release.
+The Integration open Critical security vulnerabilities and their risk assessment have been documented as part of the `project <https://wiki.onap.org/pages/viewpage.action?pageId=45298876>`_.
+
+Quick Links:
+ - `Integration project page <https://wiki.onap.org/display/DW/Integration+Project>`_
+
+ - `Project Vulnerability Review Table for Integration <https://wiki.onap.org/pages/viewpage.action?pageId=45298876>`_
O-Parent
@@ -90,7 +102,7 @@
**New Features**
* Fully automated vFW Closed Loop instantiation and testing
-* Instantiaion of 5 new vCPE models
+* Instantiation of 5 new vCPE models
Version: 1.3.1
diff --git a/version-manifest/pom.xml b/version-manifest/pom.xml
index 48dd9c1..ba3f88f 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 ddc6dd8..9ef04d6 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}