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

2. 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

3. 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

4. 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)!

5. 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

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

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

8. 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

9. 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

10. 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)

11. 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

12. 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 at first (other like centos later)
Flexible installation
HA mode or not
All components or selection of components
Facilitate upgrade

13. 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

14. Global Structure

15. Neworking

16. VID Example

17. 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

18. MERCI ;-)