1. Bootstrap/Get-started Project Team, Frank Brockners February 23, 2015
Project Bootstrap/Get-Started Overview
Bootstrap/Get-started Project Team, Frank Brockners
February 23, 2015

2. Project Bootstrap/Get-Started (BGS) Objectives and Scope
Create a starting point for OPNFV: Assemble and test a base set of infrastructure components for OPNFV to run a few example VNFs
Defined Hardware Deployment Environment
Automatic install of an initial set of components that BGS integrates
Automatic functional system test of this initial set of components
Automatic
Starting point includes very few variables to stand-up an initial OPNFV setup quickly. Variables introduces as the project gains experience.
Feed into and hand off to CI (“Octopus”), Functional Testing (“FuncTest”), Lab- and Performance Tests (“Pharos”)

3. BGS As A Nucleus For Several OPNFV Projects
BGS defined hardware runtime / deployment environment
Lab- and Performance Tests (“Pharos”)
BGS automated deployment to the hardware environment
Continuous Integration (“Octopus”)
BGS automated testing of the deployment
Functional Testing (“FuncTest”)

4. Bootstrap/Get-Started Components: Overview
Automatic setup/install
Automatic System Test
Tempest (Scenario tests), Rally, Robot
Open Stack HA
Open Stack HA
Open Stack
ODL
Future: ODL clustering
Control Node #1
(Centos 7)
Control Node #2
(Centos 7)
Control Node #3
(Centos 7)
Open Stack
OVS
vRouter (OpenWRT)
vIDS (Snort)
VNFs
Virtual Forwarder …
vLoop
Open Stack
OVS
vRouter (OpenWRT)
vIDS (Snort)
VNFs
Virtual Forwarder …
vLoop
Linux
Linux
Compute Node #1 (Centos 7)
Compute Node #1 (Centos 7)
OPNFV Confidential

5. Hardware Environment Merge And Test
3 “PODs”
6 servers per POD (3 x control node, 2 x compute node, 1 x jumphost)
1 x Integrate/Merge POD (ordered), 1 x Test POD (ordered), 1 x Develop POD (planning)
Hardware
Blade servers with 80G connectivity each
Per server:
2 x 1.2 TB 6G SAS 10K RPM SFF disks
Intel Xeon E5-2637V3 / 3.5 GHz processor
32G Memory

6. Bootstrap/Get-Started Key Components
OpenStack Juno Release
Nova, Glance, Ceilometer Neutron, Keystone, Horizon, Heat
MySQL, RabbitMQ, Pacemaker cluster stack, Corosync
Tempest, Rally (for testing)
OpenDaylight Helium Release
MDSAL, Clustering, Restconf, OVSDB, OpenFlow, SFC, GBP, ML2- plugin, Netconf
Hypervisor
KVM
Forwarder
OVS
OS distro
Linux/Centos 7
Base Installers
Foreman/Quickstack
Fuel
OpenSteak
Example VNFs
vLoop (simple loopback device)
vRouter based on OpenWRT
vIDS based on SNORT
Automation and Test-Frameworks
Jenkins (to trigger deployment as well as Tempest/Robot)
Robot
Tempest, Rally

7. Bootstrap/Get-Started: Components from OpenDaylight
Name
Version
Repository
Description
odl-dlux-all
0.1.1-Helium-SR1.1
odl-dlux Helium-SR1.1
odl-config-persister-all
0.2.6-Helium-SR1.1
odl-config-persister Helium-SR1.1
OpenDaylight :: Config Persister:: All
odl-aaa-all
odl-aaa Helium-SR1.1
OpenDaylight :: AAA :: Authentication :: All Featu
odl-ovsdb-all
1.0.1-Helium-SR1.1
ovsdb Helium-SR1.1
OpenDaylight :: OVSDB :: all
odl-ttp-all
0.0.2-Helium-SR1.1
odl-ttp Helium-SR1.1
OpenDaylight :: ttp :: All
odl-openflowplugin-all
0.0.4-Helium-SR1.1
openflowplugin Helium-SR1.1
OpenDaylight :: Openflow Plugin :: All
odl-adsal-compatibility-all
1.4.3-Helium-SR1.1
odl-adsal-compatibility Helium-SR1.1
OpenDaylight :: controller :: All
odl-tcpmd5-all
odl-tcpmd Helium-SR1.1
odl-adsal-all
0.8.2-Helium-SR1.1
adsal Helium-SR1.1
OpenDaylight AD-SAL All Features
odl-config-all
odl-config Helium-SR1.1
OpenDaylight :: Config :: All
odl-netconf-all
odl-netconf Helium-SR1.1
OpenDaylight :: Netconf :: All
odl-base-all
odl-base Helium-SR1.1
OpenDaylight Controller
odl-mdsal-all
1.1.1-Helium-SR1.1
odl-mdsal Helium-SR1.1
OpenDaylight :: MDSAL :: All
odl-yangtools-all
0.6.3-Helium-SR1.1
odl-yangtools Helium-SR1.1
OpenDaylight Yangtools All
odl-restconf-all
odl-controller Helium-SR1.1
OpenDaylight :: Restconf :: All
odl-integration-compatible-with-all
0.2.1-Helium-SR1.1
odl-integration Helium-SR1.1
odl-netconf-connector-all
OpenDaylight :: Netconf Connector :: All
odl-akka-all
odl-controller Helium-SR1.1
OpenDaylight :: Akka :: All

8. Bootstrap/Get-Started: Installation Approach Objectives
Modular architecture
Maximize re-use of existing components while allowing for OPNFV specifics and customization
Support different OpenStack installers (“Base Installer”)
Customers often have an already established preference for an installer
Decouple installation and maintenance of OPNFV specific components from base OpenStack installer
Maximize re-use of components built for “OPNFV install and maintenance” across multiple different base installers
Decouple Orchestration across different nodes from local configuration
Allow use of different frameworks for orchestration (e.g. Ansible or Salt based), even if local config is driven by through Puppet (in master-less mode)

9. BASE VM Manager INSTALLATION
Bootstrap/Get-Started: Installation Approach Two Main Phases: “Base Install”, “OPNFV Install and Maintain”
Phase 1
Phase 2
BASE VM Manager INSTALLATION
OPNFV-INSTALLATION and MAINTENANCE
Foreman / Quickstack
OpenDaylight Installation, Configuration, Maintenance
System level tests (Tests for Tempest, Robot)
Additional Modules
Fuel
OpenSteak
OpenStack Installer XYZ
Phase 1: Vanilla VM-manager install by one of the available installers. Once complete, installer terminates.
Phase 2: OPNFV specific installations and maintenance. Goal: Phase 2 to be as independent from base installer as possible

10. Bootstrap/Get-Started: Installation Approach
BASE-INSTALLATION: Installation of plain-vanilla VM-manager (for BGS, OpenStack will be used as VM-Manager)
(repeatable) install of a plain vanilla VM-manager (for BGS this is OpenStack) that deploys to bare metal and supports a HA-setup of the VM-manager
the installation is performed with an installer “i” that creates a system in state BASE(i).
Once the installation of the plain vanilla environment is complete, the installer “i” is terminated. The system is left in state BASE(i) and handed over to the second phase.
OPNFV-INSTALLATION and MAINTENANCE: Installation of OPNFV specific modules, maintenance of the overall OPNFV installation
the system state for this second phase is called OPNFV(x) (x will depend on the release)
install deltas to state BASE(i) to reach the desired state OPNFV(x). Deltas would be defined as a set of scripts/manifests. Given that the state BASE(i) differs by installer used, the scripts could also be different.
maintain the system in state OPNFV(x)

11. Base Installer: Current set of options being explored
“Experiment” #1 #2
Base Installer
Foreman/Quick-Stack
Cobbler (packaged with Fuel 6)
Local node config
Puppet (master/slave)
Fuel/Puppet
Orchestration
Khaleesi (Ansible framework)
OpenStack version
Juno
OpenDaylight version
Helium
Distro for compute nodes
Centos 7
Centos 6.5
Distro for Jumphost
Public deployment
References
Current Status
Foreman QuickStack Status

12. References
Wiki:

13. Thank You