AETHER-2011 (part6) - Add release notes and process
Change-Id: If93cff8aeeed2f84fd33b47071e8df580e7e70e8
diff --git a/conf.py b/conf.py
index da3c8f3..aaaa104 100644
--- a/conf.py
+++ b/conf.py
@@ -243,7 +243,8 @@
# -- Options for linkcheck ---------------------------------------------------
# The link checker strips off .md from links and then complains
linkcheck_ignore = [
- r'https://jenkins\.opencord\.org/job/aether-member-only-jobs/.*'
+ r'https://jenkins\.opencord\.org/job/aether-member-only-jobs/.*',
+ r'https://jenkins.aetherproject.org/.*'
]
linkcheck_timeout = 3
diff --git a/dict.txt b/dict.txt
index 70abad7..cf92579 100644
--- a/dict.txt
+++ b/dict.txt
@@ -1,6 +1,7 @@
AiaB
Alertmanager
Ansible
+Anthos
Atomix
BMC
BMv
@@ -9,7 +10,9 @@
CLI
Cloudlab
DNS
+Deutsche
Dex
+Dockerfile
Downlink
Epyc
GbE
@@ -47,6 +50,7 @@
TOST
Teardown
Telegraf
+Telekom
Terraform
TestVectors
Tofino
@@ -56,29 +60,38 @@
YAML
aether
allocatable
+amf
analytics
ansible
+api
arp
+atomix
+ausf
auth
bootable
bootloader
bootstrap
+cassandra
chainloadable
chipset
config
configs
controlplane
cpu
+dataplane
+degister
+deregister
deregistration
dev
differentiator
+disaggregated
dl
downlink
dropdown
-enb
eNB
eNBID
eNBs
+enb
etcd
ethernet
func
@@ -86,11 +99,14 @@
gRPC
gerrit
gnbsim
+gui
gw
hoc
hostname
+hss
iPXE
iface
+incrementing
ip
jitter
jjb
@@ -110,6 +126,8 @@
menlo
mgmt
microservice
+mme
+mongodb
nVME
nameserver
nameservers
@@ -119,13 +137,18 @@
ng
ng40
nginx
+nrf
+nssf
omec
onos
opencord
orchestrator
patchset
+patchsets
pcap
pcaps
+pcf
+pcrf
pfcp
pre
preconfigured
@@ -138,6 +161,7 @@
qsfp
rackmount
rackmounted
+rc
reStructuredText
readme
reenable
@@ -146,14 +170,18 @@
repo
repos
repository
+roc
routable
rscript
runtime
scalability
scalable
+sdcore
simapp
+smf
smgmt
spgw
+spgwc
splitter
subcomponent
subnet
@@ -162,10 +190,14 @@
tcp
telegraf
tfvars
+topo
topologies
tost
+udm
udp
+udr
ul
+unsuffixed
untagged
upf
uplink
@@ -175,6 +207,7 @@
webhooks
webpage
webserver
+webui
workspace
workspaces
yaml
diff --git a/release/1.5.rst b/release/1.5.rst
index 14c4dae..653e31f 100644
--- a/release/1.5.rst
+++ b/release/1.5.rst
@@ -4,46 +4,217 @@
Highlights
----------
-The focus of this release is support for...
+The focus of this release is an update of Aether to support the 5G SD-Core.
+This included a redesign of Aether modeling and workflows, integration of the
+5G SD-Core into Aether, and an update of the 4G SD-Core to be compliant with
+the 5G Aether API. 4G Small Cells are readily available and deployed at
+multiple Aether installations. The 5G Core is part of a Deutsche Telekom SD-RAN
+trial and is being used with 5G-SA disaggregated RAN components (CU/DU/RU).
+
+Deployment of Aether has been demonstrated on Anthos and on Elastic Kubernetes
+Service. Persistent test deployments are now maintained by ONF to further
+evaluate Aether functionality on those platforms.
+
New Features and Improvements
-----------------------------
+4G and 5G Connectivity Service
+""""""""""""""""""""""""""""""
-Development and Deployment Changes
-----------------------------------
+Aether supports mobile/cellular connectivity using both the 4G and the 5G
+SD-Core. The Aether ROC may be used with both cores simultaneously. The 4G
+modeling used by Aether-1.0 has been replaced with newer modeling that unifies
+the 4G and 5G cores in a single modeling abstraction.
-Support for ...
+Device Grouping and Network Slicing
+"""""""""""""""""""""""""""""""""""
+
+Aether supports a Network Slicing abstraction where similar connected devices
+can be aggregated together into a Device-Group, and different Device Groups can
+be allocated to different network slices (Virtual Connectivity Service - VCS).
+
+Grouping connected devices affords ease of management - devices in the same
+group are configured together and afforded the same treatment in the network.
+Separating device-groups into different slices affords isolation between
+groups. The data plane connectivity for different slices are realized through
+different User Plane Functions (UPFs).
+
+Furthermore, Aether supports Access Control - devices not part of any
+Device-Group are rejected by the network.
+
+Aether Portal
+"""""""""""""
+
+The Aether Portal is a modern secure Single Page Application implemented in
+Angular. The portal integrates both control of the Aether Network and metrics
+reported by Aether components in a single pane of glass with multi-tenancy
+separation. The portal allows complex control operations to be batched together
+as one transaction into a convenient “basket” and then atomically committed to
+the configuration. All of the functions of the Portal are also available on a
+secure REST API, with an OpenAPI 3 schema.
+
+Role-Based Access Control
+"""""""""""""""""""""""""
+
+The Aether control API supports role-based access control, together with
+external authentication using OpenID Connect. These access controls are used in
+the Aether Portal to limit which enterprises a portal user is allowed to view
+or modify. The Aether Portal supports multiple enterprises simultaneously.
+
+Flexible Kubernetes Deployment Options
+""""""""""""""""""""""""""""""""""""""
+
+Fully managed Aether deployment using Rancher is officially supported. Together
+with Rancher, Aether allows configuration, management, and monitoring of
+Kubernetes clusters. These clusters can be used to host the Aether Connectivity
+Service as well as customer edge applications. Support for other managed
+Kubernetes services such as Google Anthos or Amazon Elastic Kubernetes Service
+should be considered beta and not officially supported.
+
+Testing
+-------
+
+Aether uses automated testing based on Jenkins and Robot Framework. The tests
+performed are described below.
+
+SD-Core Tests
+"""""""""""""
+
+* 4G
+
+ * Functional Coverage: Attach,detach, dataplane traffic, handover, TAU,
+ paging, error scenarios, few failure/restart of network functions
+
+ * Scale and Performance tests utilizing BESS
+
+* 5G
+
+ * Functional Coverage: register, deregister, dataplane traffic scenarios,
+ handover, TAU, DDN, few error scenarios, few failure/restart of network
+ functions
+
+ * Scale tests (BESS)
+
+Jenkins jobs for functional and scale tests can be found on `Aether Jenkins -
+SD-Core System Tests
+<https://jenkins.aetherproject.org/view/SD%20Core%20System%20Tests/>`_
+
+ROC
+"""
+
+ * Functional API and GUI test coverage
+
+Jenkins jobs: `Aether Jenkins - ROC System Tests
+<https://jenkins.aetherproject.org/view/ROC%20System%20Tests/>`_
-Testing Improvements
---------------------
+System Tests
+""""""""""""
+* 4G and 5G Sanity Test coverage:
-Certification Program
----------------------
+ * Configure ROC with related models for 4G and 5G
+ * Validate for attach/register UE, pings, detach/degister UE
+
+Jenkins Jobs: `Aether Jenkins - Aether System Tests
+<https://jenkins.aetherproject.org/view/Aether%20System%20Tests/>`_
+
+Documentation
+-------------
+
+Aether documentation is available at `docs.aetherproject.org
+<https://docs.aetherproject.org>`_
Known Issues and Limitations
----------------------------
+* A given UE may participate in a 4G core or a 5G core, but not both.
+* 4G UEs may each participate in a single DeviceGroup, and 4G DeviceGroups may
+ each participate in a single VCS. This restriction does not apply to 5G UEs.
+
+* Application filtering is modeled in the API and the GUI, but application
+ filtering is not active in the data plane.
+
+* Disabling/deleting a device group from a VCS does not restrict UE from
+ getting attached to the network [SDCORE-467]
Component Versions in the 1.5 Release
-------------------------------------
-
Aether ROC
-""""""""""
+* aether-roc-api
-ONOS
-""""
+* aether-roc-gui
+* atomix
-SD-Core
-"""""""
+* onos-config
+* onos-topo
+
+* sdcore-adapter
+
+4G Core
+
+* cassandra
+
+* config4g
+
+* hss
+
+* mme
+
+* pcrf
+
+* simapp
+
+* spgwc
+
+* upf
+
+5G Core
+
+* amf
+
+* ausf
+
+* mongodb
+
+* nrf
+
+* nssf
+
+* pcf
+
+* simapp
+
+* smf
+
+* udm
+
+* udr
+
+* upf
+
+* webui
Helm Chart Versions
--------------------
+
+* aether-roc-umbrella:
+
+* config-models/aether-3.x:
+
+* sdcore-helm-chart: 0.6.2
+
+* omec-control-plane: 0.6.25
+
+* omec-sub-provision: 0.0.6
+
+* 5g-control-plane: 0.2.21
+
+* omec-user-plane: 0.3.36
+
diff --git a/release/process.rst b/release/process.rst
index db3f9e4..1fedd27 100644
--- a/release/process.rst
+++ b/release/process.rst
@@ -1,4 +1,118 @@
Release Process
===============
+Prerequisites
+-------------
+
+Aether makes the following assumptions about the components are included in a
+release:
+
+Git tags
+""""""""
+
+Code receives Git tags as a part of the CI process
+
+* Tag content comes from a **VERSION** file within the repo, and tags are
+ created only the version is a SemVer released version (example: ``1.2.3``, no
+ ``-dev`` or ``-rc`` extensions)
+
+* Tagging is *only done by the CI system* (Jenkins), which pushes tags to git
+ repos after a submit/merge of code which changes the **VERSION** file.
+
+* CI system enforces tag uniqueness - no two commits have the same released
+ version tags.
+
+ * You can't re-release or "fix" a version that has problem - make a new
+ version with fixes in it.
+
+Docker container images
+"""""""""""""""""""""""
+
+All docker images are tagged based on their git tags.
+
+* For released versions, the CI system should prevent a Dockerfile from
+ referencing a parent containers that are a moving target, such as ``latest``
+ or ``master``.
+
+ * This allows a container to be rebuilt given an arbitrary git commit with
+ fair confidence that it will result in the same code in the container.
+
+* Official images are only pushed to registries by the CI system
+
+ * Increases repeatability of the process, and prevents human accidents.
+
+Helm charts
+"""""""""""
+
+* Each chart may only contain references to released, SemVer tagged container images
+
+ * Chart CI process must check that a chart version is unique - a chart can't
+ be created with the same version twice. This should be done against the
+ chart repo.
+
+Release Steps
+-------------
+
+All Helm charts are checked that the containers they use have a SemVer version
+tag
+
+A branch is created on the Helm charts repo, with the abbreviated name of the
+release - for example **aether-1.5**.
+
+To allow for future patches to go into the repo in a way that does not conflict
+with the version branch, each component repo's **VERSION** file should have it's
+minor version increased. (ex: 1.2.n to 1.3.0-dev, so future 1.3.n+1 component
+release can easily be created).
+
+The same should be done on Helm charts in the chart repos post release, but the
+versions there shouldn't include a ``-dev`` suffix because chart publishing
+requires that every new chart version be unique and unsuffixed SemVer is a
+more consistent release numbering pattern.
+
+Finally, the ``aether-helm-charts`` repo overall **VERSION** should also be incremented
+to the next minor version (1.6.0-dev) on the **master** branch, so all 1.5.x
+releases of the overall charts repo will happen on the **aether-1.5** branch.
+
+Creating releases on the 1.5.x branch
+"""""""""""""""""""""""""""""""""""""
+
+If a fix is needed only to the helm charts:
+
+1. Make the fix on the master branch of aether-helm-charts (assuming that it is
+ required in both places).
+
+2. After the master tests pass, manually cherry-pick the fix to the **aether-1.5**
+ branch (the Chart version would be different, requiring the manual step).
+
+3. Cherry-picked patchsets on that branch will be checked by the **aether-1.5**
+ branch of tests.
+
+4. When it passes, submitting the change will make a new 1.5.x release
+
+5. Update the documentation to reflect the chart changes, a description of the
+ changes m, and increment the tag on the docs from 1.5.n to 1.5.n+1, to
+ reflect the patch change.
+
+6. If all the charts are updated and working correctly, create a new charts
+ point release by increasing the 1.5.n **VERSION** file in the
+ aether-helm-charts repo. This should be the same as the version in the
+ documentation. Immediately make another patch that returns the
+ ``aether-helm-charts`` **VERSION** to 1.5.n+1-dev, so that development
+ patches can continue on that branch.
+
+If a fix is needed to the components/containers that are included by the helm charts:
+
+1. Develop a fix to the issue on the master branch, get it approved after
+ passing master tests.
+
+2. If it doesn't exist, create an **aether-1.5** branch on the component repo,
+ starting at the commit where the **VERSION** of the component used in 1.5 was
+ created - this is known as "lazy branching".
+
+
+3. Manually cherry-pick to the **aether-1.5** branch of the component, incrementing
+ the patch version, and test with the **aether-1.5** version of
+ aether-system-tests and helm charts.
+
+4. Update helm charts and go through the helm chart update process above