Beijing S3P test strategy Eric Debeau, Sylvain Desbureaux, Morgan Richomme December 12, 2017

Amsterdam strategy Code test coverage limited to 30% Code merge not validated using Unitary Tests Documentation not fully aligned with code Validation in one lab Use-case integration as gating for Release

Amsterdam deployment solutions Heat deployment is not reliable when cloud-init is heavily used Don’t know simply what happened (and at least if it’s ongoing, OK or error) Lots of stuff just because the VM doesn’t know simply the other VMs Difficult for people who installs to know if that went well or not. Huge footprint required for the “normal” installation No flexibility: All components deployed, no flexibility to “customize” installation K8S deployment is a lot less error prone It may be complicated to use K8S in “Big Telco” today Fast installation Footprint limited Flexibility to launch some components No easy means to know when installation is finished

Amsterdam images building Except the DNS VM, all the other VM are “simply” container ships but their installation is always a bit different: Some are Ubuntu 14, others are Ubuntu 16. Some (re)build the dockers, others are pulling from the repo Some containers are huge, which significantly slows down the installation process Example : dgbuilder is 980MB whereas node-red “official” docker is 269M (latest), 92M (slim) or 23M (alpine)!

Amsterdam E2E tests / monitoring solutions Robot tests are good for end 2 end but not good to know the states of each component “live” OOM is using consul and it is very efficient

OPNFV best practices Validate in various platforms Using Pharos community platforms FuncTest (functional) + Yardstick (performance) tests to validate scenarios

Towards Beijing Towards CI in Validation in various labs Image optimisation Monitoring New deployment solution based on Ansible

Beijing: CI in various labs Automation in 1 reference lab is not enough to be trustable Specific configuration on some labs Real CI/CD & DevOPS principles must be implemented (src OPNFV XCI) Fail fast, fix fast Always have working software Small and frequent commits Work against the trunk, shortening development time Fast and tailored feedback Everything is visible to everyone all the time

Beijing : improving Gating In parallel of a reliable process for installation, we need to strengthen gating Automated tests (with sufficient footprint), build and deploy docker components (so the interest of small ones) Automated installation every night at integration lab + robot tests if installation is OK

Beijing: Images “slimification” “Slimification” of all containers to speed up the installation process Use Alpine based Docker at first (+ Ubuntu based later on, and CentOS if someone wants)

Beijing for VM monitoring: Consul Use of Consul to: Distribute components address (consul is also DNS). We may have to keep the DNS to know consul address Supervise components with one consul agent per component (so one per VM) Have the configuration for each components in order to simplify boot process and horizontal scaling

Beijing Deployment tool Reliable installation Use Ansible to deploy ONAP In VM mode (on top of OpenStack first, deployment on other cloud types later) In K8S mode (roughly wrap all the work of OOM) Same installation for all VM, except the flavor, again thanks to Ansible Proposal to use Ubuntu 16.04 at first (other like centos later) Flexible installation HA mode or not All components or selection of components Facilitate upgrade

Ansible based deployment tool Infrastructure creation (projet, network, security, VM …) DNS VM configuration VM preparation (Docker installation + images polling …) VM configuration one by one Heat template for remaining VMs https://github.com/sdesbure/onap-ansible

Global Structure https://github.com/sdesbure/onap-ansible/blob/master/playbooks/onap.yml

Neworking https://github.com/sdesbure/onap-ansible/blob/master/playbooks/roles/create-vms/tasks/network.yaml

VID Example https://github.com/sdesbure/onap-ansible/blob/master/playbooks/roles/vid/tasks/main.yaml

Next steps Ansible Deployment Images slimification Finalize all VM ONAP hosting project Target : Amsterdam V2 ? Beijing ? Images slimification ONAP hosting project ? Labs to perform ONAP E2E tests More CI/CD jobs

MERCI ;-)