What's needed to deploy ONAP
ONAP is a set of different applications. Since Casablanca release, the preferred way to deploy ONAP is OOM (ONAP Operations Manager).
OOM is a set of helm charts + an helm plugin (deploy).
Each helm chart will deploy on a Kubernetes cluster a component of ONAP (AAI, SO, VFC, ...).
helm deploy plugin will simplify the deployment of the whole solution (faster deployment, use of standard helm metadata storage).
So in order to deploy ONAP, you'll need a working kubernetes (Ingress, Storage class, CNI, ...) environment + helm installed (see software requirements for the correct version to use according to the ONAP version).
On top of this Kubernetes installation, you may also need third party components for specific use cases:
- Cert Manager if you want to use CMPv2 certificates in DCAE and SDNC
- Prometheus (preferrably installed with this helm chart) if you want to scrape some metrics
- Strimzi (PoC in Jakarta, default in Kohn) for Kafka deployment
Strategy to deploy the stack
OOM and Integration team has decided to take a modular approach in order to fulfill all the operations for deploying and validating an ONAP instance:
- Create the virtual machines
Deploy Kubernetes
- Deploy Platform Services on Kubernetes
- Deploy ONAP
- Test ONAP
Important choices have been made:
- All the deployments are using Gitlab CI
- All deployments are using ansible playbooks
- An "orchestrator" of Gitlab CI deployment is used
Chained CI: the Gitlab CI deployment "orchestrator"
Chained CI is a dynamic gitlab ci pipeline manage which will call an underneath pipeline at each stage, wait for completion, retrieve artifacts and move into the next stage if sucessful
Via a declarative (yaml) file, we can:
- chain any pipeline
- use outputs of previous stages as input of a stage
Chained CI configuration is mainly splitted in 4 types of files:
- an unique file describing the underneath projects with their pipelines: https://gitlab.com/Orange-OpenSource/lfn/ci_cd/chained-ci/-/blob/master/pod_inventory/group_vars/all.yml
- a per chain file describing the steps to perform:
- deployment of Kubernetes for a master deployment: https://gitlab.com/Orange-OpenSource/lfn/ci_cd/chained-ci/-/blob/master/pod_inventory/host_vars/onap_daily_pod4_k8s_master.yml
- deployment and test of master version: https://gitlab.com/Orange-OpenSource/lfn/ci_cd/chained-ci/-/blob/master/pod_inventory/host_vars/onap_daily_pod4_master.yml
- an IDF (Installed Description File) / PDF (Platform Description File) giving the specific configuration for a particular deployment
- PDF file will describe the servers to create. Example for a gating deployment: https://gitlab.com/Orange-OpenSource/lfn/ci_cd/chained-ci/-/blob/master/pod_config/config/az7-gating3.yaml
- IDF file will give all the values needed by the different steps. Example for a gating deployment: https://gitlab.com/Orange-OpenSource/lfn/ci_cd/chained-ci/-/blob/master/pod_config/config/idf-az7-gating3.yaml
More Information :
Creating virtual machines
input
- the description of the wanted infrastructure (networks, servers, volume, floating IPs, ...)
- credentials to use IaaS API
output
- an inventory file with the created machines and their purpose
Implementations:
OS Infra Manager for OpenStack deployments
AZ Infra Manager for Azure VM deployments
Creating Kubernetes cluster
input
- an inventory file with server with specific groups:
- kube-master for servers hosting API part of K8S
- etcd for servers hosting etcd
- kube-worker for servers hosting "compute" part of K8S
- k8s-cluster with kube-node and kube-worker servers
- k8s-full-cluster with all the servers (master, etcd, worker, jumphost)
output
- a deployed kubernetes cluster
- the admin kube config
implementations
Kubespray Automatic installation (used in dailies / weeklies)
RKE Automatic installation (not used anymore)
RKE2 Automatic installation (used internally)
AKS Automatic installation (used for gating)
Adding Services to the Kubernetes cluster
input
- a valid kube config
- an accessible kubernetes API
output
- installed platform components (helm, prometheus, others)
implementations
This installation is done in the "postconfiguration" part of the Kubernetes cluster project.
There are 2 types of implementations :
- legacy one where a subset is installed (prometheus) and the rest is done via "freeform" (see https://gitlab.com/Orange-OpenSource/lfn/ci_cd/chained-ci/-/blob/master/pod_config/config/idf-az7-gating3.yaml#L62-98)
- "new" one where all must be created before (no more freeform): better control and thus better durability. Not used on OOM today
Deploying ONAP
input
- a valid kube config
- helm
- possibly an override file to choose which components to use / specific configuration for ONAP or some components
output
- a (working hopefully) ONAP deployment
implementation
ONAP OOM Automatic installation
ONAP OOM Automatic installation refresh (not used today on community deployments unfortunately)
Testing ONAP
input
- a valid kueb config
- the name of the namespace where ONAP is installed (onap by default)
- a docker service
output
- a report on the performed tests
implementation
Specificities of ONAP Dailies / Weeklies on Orange premices
Openstack API is not present on Internet and thus all calls must be made via a jumphost (rebond.opnfv.fr)
Specificities of ONAP gating on Azure
TBD