aboutsummaryrefslogtreecommitdiffstats
path: root/docs/release/release-notes/Auto-release-notes.rst
diff options
context:
space:
mode:
Diffstat (limited to 'docs/release/release-notes/Auto-release-notes.rst')
-rw-r--r--docs/release/release-notes/Auto-release-notes.rst490
1 files changed, 490 insertions, 0 deletions
diff --git a/docs/release/release-notes/Auto-release-notes.rst b/docs/release/release-notes/Auto-release-notes.rst
new file mode 100644
index 0000000..ed6524d
--- /dev/null
+++ b/docs/release/release-notes/Auto-release-notes.rst
@@ -0,0 +1,490 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. SPDX-License-Identifier CC-BY-4.0
+.. (c) Open Platform for NFV Project, Inc. and its contributors
+
+
+Auto Release Notes
+==================
+
+This document provides the release notes for the Gambia 7.0 release of Auto.
+
+
+Important notes for this release
+================================
+
+The initial release for Auto was in Fraser 6.0 (project inception: July 2017).
+
+
+Summary
+=======
+
+Overview
+^^^^^^^^
+
+OPNFV is an SDNFV system integration project for open-source components, which so far have been mostly limited to
+the NFVI+VIM as generally described by `ETSI <https://www.etsi.org/technologies-clusters/technologies/nfv>`_.
+
+In particular, OPNFV has yet to integrate higher-level automation features for VNFs and end-to-end Services.
+
+As an OPNFV project, Auto (*ONAP-Automated OPNFV*) will focus on ONAP component integration and verification with
+OPNFV reference platforms/scenarios, through primarily a post-install process, in order to avoid impact to OPNFV
+installer projects (Fuel/MCP, Compass4NFV, Apex/TripleO, Daisy4NFV). As much as possible, this will use a generic
+installation/integration process (not specific to any OPNFV installer's technology).
+
+* `ONAP <https://www.onap.org/>`_ (a Linux Foundation Project) is an open source software platform that delivers
+ robust capabilities for the design, creation, orchestration, monitoring, and life cycle management of
+ Software-Defined Networks (SDNs). The current release of ONAP is B (Beijing).
+
+Auto aims at validating the business value of ONAP in general, but especially within an OPNFV infrastructure
+(integration of ONAP and OPNFV). Business value is measured in terms of improved service quality (performance,
+reliability, ...) and OPEX reduction (VNF management simplification, power consumption reduction, ...), as
+demonstrated by use cases.
+
+Auto also validates multi-architecture software (binary images and containers) availability of ONAP and OPNFV:
+CPUs (x86, ARM) and Clouds (MultiVIM)
+
+In other words, Auto is a turnkey approach to automatically deploy an integrated open-source virtual network
+based on OPNFV (as infrastructure) and ONAP (as end-to-end service manager), that demonstrates business value
+to end-users (IT/Telco service providers, enterprises).
+
+
+While all of ONAP is in scope, as it proceeds, the Auto project will focus on specific aspects of this integration
+and verification in each release. Some example topics and work items include:
+
+* How ONAP meets VNFM standards, and interacts with VNFs from different vendors
+* How ONAP SDN-C uses OPNFV existing features, e.g. NetReady, in a two-layer controller architecture in which the
+ upper layer (global controller) is replaceable, and the lower layer can use different vendor’s local controller to
+ interact with SDN-C. For interaction with multiple cloud infrastructures, the MultiVIM ONAP component will be used.
+* How ONAP leverages OPNFV installers (Fuel/MCP, Compass4NFV, Apex/TripleO, Daisy4NFV) to provide a cloud
+ instance (starting with OpenStack) on which to install the tool ONAP
+* What data collection interface VNF and controllers provide to ONAP DCAE, and (through DCAE), to closed-loop control
+ functions such as Policy Tests which verify interoperability of ONAP automation/lifecycle features with specific NFVI
+ and VIM features, as prioritized by the project with OPNFV technical community and
+ EUAG (`End User Advisory Group <https://www.opnfv.org/end-users/end-user-advisory-group>`_) input.
+
+ Examples:
+
+ * Abstraction of networking tech/features e.g. through NetReady/Gluon
+ * Blueprint-based VNF deployment (HOT, TOSCA, YANG)
+ * Application level configuration and lifecycle through YANG (for any aspects depending upon OPNFV NFVI+VIM components)
+ * Policy (through DCAE)
+ * Telemetry (through VES/DCAE)
+
+Initial areas of focus for Auto (in orange dotted lines; this scope can be expanded for future releases).
+It is understood that:
+
+* ONAP scope extends beyond the lines drawn below
+* ONAP architecture does not necessarily align with the ETSI NFV inspired diagrams this is based upon
+
+.. image:: auto-proj-rn01.png
+
+
+The current ONAP architecture overview can be found `here <https://onap.readthedocs.io/en/latest/guides/onap-developer/architecture/onap-architecture.html>`_.
+
+For reference, the ONAP-Beijing architecture diagram is replicated here:
+
+.. image:: ONAP-toplevel-beijing.png
+
+
+Within OPNFV, Auto leverages tools and collaborates with other projects:
+
+* use clouds/VIMs as installed in OPNFV infrastructure (e.g. OpenStack as installed by Fuel/MCP, Compass4NFV, etc.)
+* include VNFs developed by OPNFV data plane groups (e.g., accelerated by VPP (Vector Packet Processing) with DPDK support, ...)
+* validate ONAP+VNFs+VIMs on two major CPU architectures: x86 (CISC), Arm (RISC); collaborate with OPNFV/Armband
+* work with other related groups in OPNFV:
+
+ * FuncTest for software verification (CI/CD, Pass/Fail)
+ * Yardstick for metric management (quantitative measurements)
+ * VES (VNF Event Stream) and Barometer for VNF monitoring (feed to ONAP/DCAE)
+ * Edge Cloud as use case
+
+* leverage OPNFV tools and infrastructure:
+
+ * Pharos as LaaS: transient pods (3-week bookings) and permanent Arm pod (6 servers)
+ * `WorksOnArm <http://worksonarm.com/cluster>`_ (`GitHub link <http://github.com/worksonarm/cluster>`_)
+ * possibly other labs from the community (Huawei pod-12, 6 servers, x86)
+ * JJB/Jenkins for CI/CD (and follow OPNFV scenario convention)
+ * Gerrit/Git for code and documents reviewing and archiving (similar to ONAP: Linux Foundation umbrella)
+ * follow OPNFV releases (Releng group)
+
+
+Testability
+^^^^^^^^^^^
+
+* Tests (test cases) will be developed for use cases within the project scope.
+* In future releases, tests will be added to Functest runs for supporting scenarios.
+
+Auto’s goals include the standup and tests for integrated ONAP-Cloud platforms (“Cloud” here being OPNFV “scenarios”
+or other cloud environments). Thus, the artifacts would be tools to deploy ONAP (leveraging OOM whenever possible,
+starting with Beijing release of ONAP, and a preference for the containerized version of ONAP), to integrate it with
+clouds, to onboard and deploy test VNFs, to configure policies and closed-loop controls, and to run use-case defined
+tests against that integrated environment. OPNFV scenarios would be a possible component in the above.
+
+Installing Auto components and running a battery of tests will be automated, with some or all of the tests being
+integrated in OPNFV CI/CD (depending on the execution length and resource consumption).
+
+Combining all potential parameters, a full set of Auto test case executions can result in thousands of individual results.
+The analysis of these results can be performed by humans, or even by ML/AI (Machine Learning, Artificial Intelligence).
+Test results will be used to fine-tune policies and closed-loop controls configured in ONAP, for increased ONAP business
+value (i.e., find/determine policies and controls which yield optimized ONAP business value metrics such as OPEX).
+
+More precisely, the following list shows parameters that could be applied to an Auto full run of test cases:
+
+* Auto test cases for given use cases
+* OPNFV installer {Fuel/MCP, Compass4NFV, Apex/TripleO, Daisy4NFV}
+* OPNFV availability scenario {HA, noHA}
+* environment where ONAP runs {bare metal servers, VMs from clouds (OpenStack, AWS, GCP, Azure, ...), containers}
+* ONAP installation type {bare metal, VM, or container, ...} and options {MultiVIM single|distributed, ...}
+* VNF types {vFW, vCPE, vAAA, vDHCP, vDNS, vHSS, ...} and VNF-based services {vIMS, vEPC, ...}
+* cloud where VNFs run {OpenStack, AWS, GCP, Azure, ...}
+* VNF host type {VM, container}
+* CPU architectures {x86/AMD64, ARM/aarch64} for ONAP software and for VNF software; not really important for Auto software;
+* pod size and technology (RAM, storage, CPU cores/threads, NICs)
+* traffic types and amounts/volumes; traffic generators (although that should not really matter);
+* ONAP configuration {especially policies and closed-loop controls; monitoring types for DCAE: VES, ...}
+* versions of every component {Linux OS (Ubuntu, CentOS), OPNFV release, clouds, ONAP, VNFs, ...}
+
+The diagram below shows Auto parameters:
+
+.. image:: auto-proj-parameters.png
+
+
+The next figure is an illustration of the Auto analysis loop (design, configuration, execution, result analysis)
+based on test cases covering as many parameters as possible :
+
+.. image:: auto-proj-tests.png
+
+
+Auto currently defines three use cases: Edge Cloud (UC1), Resiliency Improvements (UC2), and Enterprise vCPE (UC3). These use cases aim to show:
+
+* increased autonomy of Edge Cloud management (automation, catalog-based deployment). This use case relates to the
+ `OPNFV Edge Cloud <https://wiki.opnfv.org/display/PROJ/Edge+cloud>`_ initiative.
+* increased resilience (i.e. fast VNF recovery in case of failure or problem, thanks to closed-loop control),
+ including end-to-end composite services of which a Cloud Manager may not be aware (VMs or containers could be
+ recovered by a Cloud Manager, but not necessarily an end-to-end service built on top of VMs or containers).
+* enterprise-grade performance of vCPEs (certification during onboarding, then real-time performance assurance with
+ SLAs and HA, as well as scaling).
+
+The use cases define test cases, which initially will be independent, but which might eventually be integrated to `FuncTest <https://wiki.opnfv.org/display/functest/Opnfv+Functional+Testing>`_.
+
+Additional use cases can be added in the future, such as vIMS (example: project `Clearwater <http://www.projectclearwater.org/>`_)
+or residential vHGW (virtual Home Gateways). The interest for vHGW is to reduce overall power consumption: even in idle mode,
+physical HGWs in residential premises consume a lot of energy. Virtualizing that service to the Service Provider edge data center
+would allow to minimize that consumption.
+
+
+Lab environment
+^^^^^^^^^^^^^^^
+
+Target architectures for all Auto use cases and test cases include x86 and Arm. Power consumption analysis will be
+performed, leveraging Functest tools (based on RedFish/IPMI/ILO).
+
+Initially, an ONAP-Amsterdam instance (without DCAE) had been installed over Kubernetes on bare metal on a single-server
+x86 pod at UNH IOL.
+
+A transition is in progress, to leverage OPNFV LaaS (Lab-as-a-Service) pods (`Pharos <https://labs.opnfv.org/>`_).
+These pods can be booked for 3 weeks only (with an extension for a maximum of 2 weeks), so they are not a permanent resource.
+
+For ONAP-Beijing, a repeatable automated installation procedure is being developed, using 3 Pharos servers (x86 for now).
+Also, a more permanent ONAP installation is in progress at a Huawei lab (pod-12, consisting of 6 x86 servers,
+1 as jump server, the other 5 with this example allocation: 3 for ONAP components, and 2 for an OPNFV infratructure:
+Openstack installed by Compass4NFV).
+
+ONAP-based onboarding and deployment of VNFs is in progress (ONAP-Amsterdam pre-loading of VNFs must still done outside
+of ONAP: for VM-based VNFs, users need to prepare OpenStack stacks (using Heat templates), then make an instance snapshot
+which serves as the binary image of the VNF).
+
+A script to prepare an OpenStack instance for ONAP (creation of a public and a private network, with a router,
+pre-loading of images and flavors, creation of a security group and an ONAP user) has been developed. It leverages
+OpenStack SDK. It has a delete option, so it can be invoked to delete these objects for example in a tear-down procedure.
+
+Integration with Arm servers has started (exploring binary compatibility):
+
+* The Auto project has a specific 6-server pod of Arm servers, which is currently loaned to ONAP integration team,
+ to build ONAP images
+* A set of 14 additional Arm servers was deployed at UNH, for increased capacity
+* ONAP Docker registry: ONAP-specific images for ARM are being built, with the purpose of populating ONAP nexus2
+ (Maven2 artifacts) and nexus3 (Docker containers) repositories at Linux Foundation. Docker images are
+ multi-architecture, and the manifest of an image may contain 1 or more layers (for example 2 layers: x86/AMD64
+ and ARM/aarch64). One of ONAP-Casablanca architectural requirements is to be CPU-architecture independent.
+ There are almost 150 Docker containers in a complete ONAP instance. Currently, more disk space is being added
+ to the ARM nodes (configuration of Nova, and/or additional actual physical storage space).
+
+
+Test case design and implementation for the three use cases has started.
+
+OPNFV CI/CD integration with JJD (Jenkins Job Description) has started: see the Auto plan description
+`here <https://wiki.opnfv.org/display/AUTO/CI+for+Auto>`_. The permanent resource for that is the 6-server Arm
+pod, hosted at UNH. The CI directory from the Auto repository is `here <https://git.opnfv.org/auto/tree/ci>`_
+
+
+Finally, the following figure illustrates Auto in terms of project activities:
+
+.. image:: auto-project-activities.png
+
+
+Note: a demo was delivered at the OpenStack Summit in Vancouver on May 21st 2018, to illustrate the deployment of
+a WordPress application (WordPress is a platform for websites and blogs) deployed on a multi-architecture cloud (mix
+of x86 and Arm servers).
+This shows how service providers and enterprises can diversify their data centers with servers of different architectures,
+and select architectures best suited to each use case (mapping application components to architectures: DBs,
+interactive servers, number-crunching modules, ...).
+This prefigures how other examples such as ONAP, VIMs, and VNFs could also be deployed on heterogeneous multi-architecture
+environments (open infrastructure), orchestrated by Kubernetes. The Auto installation scripts covering all the parameters
+described above could expand on that approach.
+
+.. image:: auto-proj-openstacksummit1805.png
+
+
+
+
+Release Data
+============
+
++--------------------------------------+--------------------------------------+
+| **Project** | Auto |
+| | |
++--------------------------------------+--------------------------------------+
+| **Repo/commit-ID** | auto/opnfv-7.0.0 |
+| | |
++--------------------------------------+--------------------------------------+
+| **Release designation** | Gambia 7.0 |
+| | |
++--------------------------------------+--------------------------------------+
+| **Release date** | 2018-11-02 |
+| | |
++--------------------------------------+--------------------------------------+
+| **Purpose of the delivery** | Official OPNFV release |
+| | |
++--------------------------------------+--------------------------------------+
+
+Version change
+^^^^^^^^^^^^^^
+
+Module version changes
+~~~~~~~~~~~~~~~~~~~~~~
+- There have been no version changes.
+
+
+Document version changes
+~~~~~~~~~~~~~~~~~~~~~~~~
+- There have been no version changes.
+
+
+Reason for version
+^^^^^^^^^^^^^^^^^^
+
+Feature additions
+~~~~~~~~~~~~~~~~~
+
+Initial release 6.0:
+
+* Fraser release plan
+* use case descriptions
+* test case descriptions
+* in-progress test case development
+* lab: OPNFV and ONAP (Amsterdam) installations
+
+Point release 6.1:
+
+* added Gambia release plan
+* started integration with CI/CD (JJB) on permanent Arm pod
+* Arm demo at OpenStack Summit
+* initial script for configuring OpenStack instance for ONAP, using OpenStack SDK 0.13
+* initial attempts to install ONAP Beijing
+* alignment with OPNFV Edge Cloud
+* initial contacts with Functest
+
+Point release 6.2:
+
+* initial scripts for OPNFV CI/CD, registration of Jenkins slave on `Arm pod <https://build.opnfv.org/ci/view/auto/>`_
+* updated script for configuring OpenStack instance for ONAP, using OpenStack SDK 0.14
+
+Point release 7.0:
+
+* progress on Docker registry of ONAP's Arm images
+* progress on ONAP installation script for 3-server cluster of UNH servers
+* CI scripts for OPNFV installers: Fuel/MCP (x86), Compass, Apex/TripleO (must run twice)
+* initial CI script for Daisy4NFV (work in progress)
+* JOID script, but supported only until R6.2, not Gambia 7.0
+* completed script for configuring OpenStack instance for ONAP, using OpenStack SDK 0.17
+* use of an additional lab resource for Auto development: 6-server x86 pod (huawei-pod12)
+
+
+
+
+
+**JIRA TICKETS for this release:**
+
+
+`JIRA Auto Gambia 7.0.0 Done <https://jira.opnfv.org/issues/?filter=12403>`_
+
+Manual selection of significant JIRA tickets for this version's highlights:
+
++--------------------------------------+--------------------------------------+
+| **JIRA REFERENCE** | **SLOGAN** |
+| | |
++--------------------------------------+--------------------------------------+
+| AUTO-37 | Get DCAE running onto Pharos |
+| | deployment |
++--------------------------------------+--------------------------------------+
+| AUTO-42 | Use Compass4NFV to create an |
+| | OpenStack instance on a UNH pod |
++--------------------------------------+--------------------------------------+
+| AUTO-43 | String together scripts for Fuel, |
+| | Tool installation, ONAP preparation |
++--------------------------------------+--------------------------------------+
+| AUTO-44 | Build ONAP components for arm64 |
+| | platform |
++--------------------------------------+--------------------------------------+
+| AUTO-45 | CI: Jenkins definition of verify and |
+| | merge jobs |
++--------------------------------------+--------------------------------------+
+| AUTO-46 | Use Apex to create an OpenStack |
+| | instance on a UNH pod |
++--------------------------------------+--------------------------------------+
+| AUTO-47 | Install ONAP with Kubernetes on LaaS |
+| | |
++--------------------------------------+--------------------------------------+
+| AUTO-48 | Create documentation for ONAP |
+| | deployment with Kubernetes on LaaS |
++--------------------------------------+--------------------------------------+
+| AUTO-49 | Automate ONAP deployment with |
+| | Kubernetes on LaaS |
++--------------------------------------+--------------------------------------+
+| AUTO-51 | huawei-pod12: Prepare IDF and PDF |
+| | files |
++--------------------------------------+--------------------------------------+
+| AUTO-52 | Deploy a running ONAP instance on |
+| | huawei-pod12 |
++--------------------------------------+--------------------------------------+
+| AUTO-54 | Use Daisy4nfv to create an OpenStack |
+| | instance on a UNH pod |
++--------------------------------------+--------------------------------------+
+| | |
+| | |
++--------------------------------------+--------------------------------------+
+
+
+
+Bug corrections
+~~~~~~~~~~~~~~~
+
+**JIRA TICKETS:**
+
++--------------------------------------+--------------------------------------+
+| **JIRA REFERENCE** | **SLOGAN** |
+| | |
++--------------------------------------+--------------------------------------+
+| | |
+| | |
++--------------------------------------+--------------------------------------+
+| | |
+| | |
++--------------------------------------+--------------------------------------+
+
+
+Deliverables
+============
+
+Software deliverables
+^^^^^^^^^^^^^^^^^^^^^
+
+7.0 release: in-progress Docker ARM images, install scripts, CI scripts, and test case implementations.
+
+
+Documentation deliverables
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Updated versions of:
+
+* Release Notes (this document)
+* User Guide
+* Configuration Guide
+
+(see links in References section)
+
+
+
+Known Limitations, Issues and Workarounds
+=========================================
+
+System Limitations
+^^^^^^^^^^^^^^^^^^
+
+
+
+Known issues
+^^^^^^^^^^^^
+
+None at this point.
+
+
+**JIRA TICKETS:**
+
++--------------------------------------+--------------------------------------+
+| **JIRA REFERENCE** | **SLOGAN** |
+| | |
++--------------------------------------+--------------------------------------+
+| | |
+| | |
++--------------------------------------+--------------------------------------+
+| | |
+| | |
++--------------------------------------+--------------------------------------+
+
+Workarounds
+^^^^^^^^^^^
+
+None at this point.
+
+
+
+Test Result
+===========
+
+None at this point.
+
+
+
++--------------------------------------+--------------------------------------+
+| **TEST-SUITE** | **Results:** |
+| | |
++--------------------------------------+--------------------------------------+
+| | |
+| | |
++--------------------------------------+--------------------------------------+
+| | |
+| | |
++--------------------------------------+--------------------------------------+
+
+References
+==========
+
+For more information on the OPNFV Gambia release, please see:
+http://opnfv.org/gambia
+
+
+Auto Wiki pages:
+
+* `Auto wiki main page <https://wiki.opnfv.org/pages/viewpage.action?pageId=12389095>`_
+
+
+OPNFV documentation on Auto:
+
+* `Auto release notes <auto-releasenotes>`
+* `Auto use case user guides <auto-userguide>`
+* `Auto configuration guide <auto-configguide>`
+
+
+Git&Gerrit Auto repositories:
+
+* `Auto Git repository <https://git.opnfv.org/auto/tree/>`_
+* `Gerrit for Auto project <https://gerrit.opnfv.org/gerrit/#/admin/projects/auto>`_
+
+
+Demo at OpenStack summit May 2018 (Vancouver, BC, Canada):
+
+* YouTube video (10min 52s): `Integration testing on an OpenStack public cloud <https://youtu.be/BJ05YuusNYw>`_
+