docs/release/index.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0
   2    International License. http://creativecommons.org/licenses/by/4.0
   3
   4
   5 .. _onap-release-notes:
   6
   7 Honolulu Release Notes
   8 ^^^^^^^^^^^^^^^^^^^^^^
   9
  10 This page provides the release notes for the ONAP Honolulu release. This
  11 includes details of software versions, known limitations, and outstanding
  12 trouble reports.
  13
  14 Release notes are cumulative for the release, meaning this release note will
  15 have an entry for each Major, Minor, and Maintenance release, if applicable.
  16
  17 Each component within the ONAP solution maintains their own component level
  18 release notes and links to those release notes are provided below.
  19 Details on the specific items delivered in each release by each component is
  20 maintained in the component specific release notes.
  21
  22 Honolulu Releases
  23 =================
  24
  25 The following releases are available for Honolulu:
  26   - `Honolulu Major Release 8.0.0`_
  27
  28 Honolulu Major Release 8.0.0
  29 ============================
  30
  31 +--------------------------------------+--------------------------------------+
  32 | **Project**                          | Open Network Automation Platform     |
  33 |                                      | (ONAP)                               |
  34 +--------------------------------------+--------------------------------------+
  35 | **Release name**                     | Honolulu                             |
  36 |                                      |                                      |
  37 +--------------------------------------+--------------------------------------+
  38 | **Release version**                  | 8.0.0                                |
  39 |                                      |                                      |
  40 +--------------------------------------+--------------------------------------+
  41 | **Release date**                     | May 11th  2021                       |
  42 |                                      |                                      |
  43 +--------------------------------------+--------------------------------------+
  44
  45 Honolulu Features
  46 =================
  47 ONAP Honolulu focusses on:
  48
  49 * Cloud Native Function (CNF) support with  with seamless configuration of Helm
  50   based CNFs and K8s resources
  51 * End-to-end 5G network slicing with three network slicing components for RAN,
  52   core, and transport
  53 * Introducing a new component: Configuration Persistence Service (CPS) to store
  54   persistent configuation data
  55 * Modularity to pick and choose the components needed for specific use case
  56 * Improving integration with many SDOs
  57
  58 Functional Requirements
  59 -----------------------
  60
  61 Increased Cloud Native Functionality
  62 ....................................
  63 The Honolulu release has important updates to support cloud native network
  64 functions (CNF). The functionality includes configuration of Helm based CNFs
  65 and seamless day 1, 2 operations. The Configuration API allows a user to
  66 create, modify and delete Kubernetes (K8s) resource templates and their base
  67 parameters and the Profile API allows for sophisticated day 0 configuration.
  68 The Query API gathers filtered status of the CNF and the HealthCheck API
  69 executes dedicated health check jobs to verify the status of a CNF. This new
  70 functionality is implemented in the Controller Design Studio (CDS) component
  71 using dedicated templates called Controller Blueprint Archives (CBA).
  72 In addition, there is Swagger documentation for the API of the K8s plugin
  73 component in the MutliCloud project.
  74
  75 Deeper 5G Support
  76 .................
  77 There is a significant set of new functionality around end-to-end 5G network
  78 slicing in the Honolulu release. This release includes three internal Network
  79 Slice Subnet Management Function (NSSMF) components for RAN, core, and
  80 transport domains. External NSSMFs continue to be supported for RAN and core.
  81 Next, slice optimization continues to be an area of ongoing effort with closed
  82 loop automation and intelligent slicing testing. There are also enhancements in
  83 NST, NSI, and NSSI selection in the OOF project and A&AI includes schema
  84 changes to accommodate network and transport slicing.
  85
  86 In addition, the ExtAPI project now included Enhanced Service Ordering for
  87 additional service types and the UUI graphical user interface has improved
  88 slicing support. The VID graphical user has support for PNF plug-and-play
  89 allowing operators to interact with PNFs via VID. In addition, there is better
  90 compliance to standards such as 3GPP TS28.540/541 5G NRM driven xNF models in
  91 ONAP. Finally the OOF SON functionality supports offline trained ML-models
  92 providing additional inputs for Physical Cell Identity (PCI) optimization.
  93 DCAE includes a new KPI microservice.
  94
  95 Configuration Persistence Service
  96 .................................
  97 Another key 5G related initiative is the new Configuration Persistence Service
  98 (CPS) module that allows ONAP projects to store persistent state defined by
  99 YANG models, deploy YANG models at runtime, and share access to configuration
 100 management data.
 101
 102 Further O-RAN Integration
 103 .........................
 104 A key enhancement in the Honolulu release was increased support for the O-RAN
 105 A1 standard that is implemented in the CCSDK and SDN-C projects. The O-RAN A1
 106 interface provides a flexible way for RAN operators to manage wide area RAN
 107 network optimization reducing capex investment needs. Both the enhanced A1
 108 interface controller and A1 policy capabilities are now usable in ONAP with a
 109 Near-Real-Time Radio Intelligent Controller (nRTRIC). This functionality is
 110 also used downstream in O-RAN-Source Community (OSC) Non-RealTime RIC
 111 (NONRTRIC) project, strengthening alignment between ONAP & OSC. In addition,
 112 the DCAE project includes VES 7.2 integration that improves integration with
 113 both O-RAN and 3GPP. Finally, there is a new CPS interface to query RAN
 114 configuration data.
 115
 116 Expanded Modularity
 117 ...................
 118 Modularity has been an important topic in ONAP to allow users to pick and
 119 choose the components they need for their specific use case and Honolulu
 120 continues to advance modularity. DCAE now simplifies microservice deployment
 121 via Helm charts.
 122
 123 Service Design
 124 ..............
 125
 126 - Includes increased support for ETSI standards such as SOL001, SOL004, and
 127   SOL007 and allows users to choose unlicensed or externally licensed xNFs.
 128 - Vendor License Model is now optional
 129 - SDC distribution status report enhanced
 130
 131 Inventory
 132 .........
 133
 134 - A&AI includes support for multi tenancy.
 135 - Model updates for CCVPN Transport Slicing and Network Slicing
 136 - GraphGraph POC enhanced for schema visualization and visual model generation
 137 - Sparky UI updates including Browse, Specialized Search, BYOQ, and BYOQ
 138   Builder Views
 139
 140 ONAP Operations Manager
 141 .......................
 142
 143 - Portal-Cassandra image updated to Bitnami, supporting IPv4/IPv6 Dual Stack
 144 - CMPv2 external issuer implemented which extends Cert-Manager with ability to
 145   enroll X.509 certificates from CMPv2 servers
 146 - New version for MariaDB Galera using Bitnami image, supporting IPv4/IPv6 Dual
 147   Stack
 148 - Support of Helm v3.4 and Helm v3.5
 149
 150 Non-Functional Requirements
 151 ---------------------------
 152 The following 'non-functional' requirements are followed in the
 153 Honolulu Release:
 154
 155 Best Practice
 156 .............
 157
 158 - ONAP shall use STDOUT for logs collection
 159 - IPv4/IPv6 dual stack support in ONAP
 160 - Containers must crash properly when a failure occurs
 161 - Containers must have no more than one main process
 162 - Application config should be fully prepared before starting the
 163   application container
 164 - No root (superuser) access to database from application container
 165
 166 Code Quality
 167 ............
 168
 169 - Each ONAP project shall improve its CII Badging score by improving input
 170   validation and documenting it in their CII Badging site
 171 - Each ONAP project shall define code coverage improvements and achieve at
 172   least 55% code coverage
 173
 174 Security
 175 ........
 176
 177 - Python language 3.8
 178 - Java language v11
 179 - All containers must run as non-root user
 180 - Continue hardcoded passwords removal
 181 - Flow management must be activated for ONAP.
 182 - Each project will update the vulnerable direct dependencies in their code
 183   base
 184
 185 Tests
 186 .....
 187
 188 - New E2E tests
 189 - New IPv4/Ipv6 daily CI chain
 190
 191 .. important::
 192    Some non-functional requirements are not fully finalized. Please, check details
 193    on the :ref:`Integration<onap-integration:release_non_functional_requirements>`
 194
 195
 196 Project Specific Release Notes
 197 ==============================
 198 ONAP releases are specified by a list of project artifact versions in the
 199 project repositories and docker container image versions listed in the OOM
 200 Helm charts.
 201
 202 Each project provides detailed :ref:`release notes<doc-releaserepos>`
 203 and prepends to these if/when any updated versions the project team believes
 204 are compatible with a major release are made available.
 205
 206 Documentation
 207 =============
 208 ONAP Honolulu Release provides a set selection of documents,
 209 see :ref:`ONAP Documentation<master_index>`.
 210
 211 The `developer wiki <http://wiki.onap.org>`_ remains a good source of
 212 information on meeting plans and notes from committees, project teams and
 213 community events.
 214
 215 Security Notes
 216 ==============
 217 Details about discovered and mitigated vulnerabilities are in
 218 :ref:`ONAP Security <onap-osa:onap-security>`
 219
 220 ONAP has adopted the `CII Best Practice Badge Program <https://bestpractices.coreinfrastructure.org/en>`_.
 221
 222 - `Badging Requirements <https://github.com/coreinfrastructure/best-practices-badge>`_
 223 - `Badging Status for all ONAP projects <https://bestpractices.coreinfrastructure.org/en/projects?q=onap>`_
 224
 225 In the Honolulu release,
 226
 227 - 100% projects passed 90% of the CII badge
 228 - 85% projects passed the CII badge
 229 - 11% projects passed the CII Silver badge
 230
 231 Project specific details are in the :ref:`release notes<doc-releaserepos>` for
 232 each project.
 233
 234 .. index:: maturity
 235
 236 ONAP Maturity Testing Notes
 237 ===========================
 238 For the Honolulu release, ONAP continues to improve in multiple areas of
 239 Scalability, Security, Stability and Performance (S3P) metrics.
 240
 241 In Honolulu the Integration team focussed in
 242
 243 - Automating ONAP Testing to improve the overall quality
 244 - Adding security and E2E tests
 245
 246 More details in :ref:`ONAP Integration Project<onap-integration:master_index>`
 247
 248 Known Issues and Limitations
 249 ============================
 250 Known Issues and limitations are documented in each
 251 :ref:`project Release Notes <doc-releaserepos>`.
 252
 253
 254 .. Include files referenced by link in the toctree as hidden