Project BootstrapGetStarted Overview BootstrapGetstarted Project Team Frank Brockners

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

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 (“Func. Test”), Lab- and Performance Tests (“Pharos”)

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 (“Func. Test”)

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

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 80 G connectivity each – Per server: • 2 x 1. 2 TB 6 G SAS 10 K RPM SFF disks • Intel Xeon E 5 -2637 V 3 / 3. 5 GHz processor • 32 G Memory

Bootstrap/Get-Started Key Components • Open. Stack Juno Release • • MDSAL, Clustering, Restconf, OVSDB, Open. Flow, SFC, GBP, ML 2 plugin, Netconf KVM Forwarder Base Installers • • • OVS OS distro • Linux/Centos 7 v. Loop (simple loopback device) v. Router based on Open. WRT v. IDS based on SNORT Automation and Test-Frameworks • • • Foreman/Quickstack Fuel Open. Steak Example VNFs • Hypervisor • • Nova, Glance, Ceilometer Neutron, Keystone, Horizon, Heat My. SQL, Rabbit. MQ, Pacemaker cluster stack, Corosync Tempest, Rally (for testing) Open. Daylight Helium Release • • • Jenkins (to trigger deployment as well as Tempest/Robot) Robot Tempest, Rally

Bootstrap/Get-Started: Components from Open. Daylight Name Version Repository Description odl-dlux-all 0. 1. 1 -Helium-SR 1. 1 odl-dlux-0. 1. 1 -Helium-SR 1. 1 odl-config-persister-all 0. 2. 6 -Helium-SR 1. 1 odl-config-persister-0. 2. 6 -Helium-SR 1. 1 Open. Daylight : : Config Persister: : All odl-aaa-all 0. 1. 1 -Helium-SR 1. 1 odl-aaa-0. 1. 1 -Helium-SR 1. 1 Open. Daylight : : AAA : : Authentication : : All Featu odl-ovsdb-all 1. 0. 1 -Helium-SR 1. 1 ovsdb-1. 0. 1 -Helium-SR 1. 1 Open. Daylight : : OVSDB : : all odl-ttp-all 0. 0. 2 -Helium-SR 1. 1 odl-ttp-0. 0. 2 -Helium-SR 1. 1 Open. Daylight : : ttp : : All odl-openflowplugin-all 0. 0. 4 -Helium-SR 1. 1 openflowplugin-0. 0. 4 -Helium-SR 1. 1 Open. Daylight : : Openflow Plugin : : All odl-adsal-compatibility-all 1. 4. 3 -Helium-SR 1. 1 odl-adsal-compatibility-0. 8. 2 -Helium-SR 1. 1 Open. Daylight : : controller : : All odl-tcpmd 5 -all 1. 0. 1 -Helium-SR 1. 1 odl-tcpmd 5 -1. 0. 1 -Helium-SR 1. 1 odl-adsal-all 0. 8. 2 -Helium-SR 1. 1 adsal-0. 8. 2 -Helium-SR 1. 1 Open. Daylight AD-SAL All Features odl-config-all 0. 2. 6 -Helium-SR 1. 1 odl-config-0. 2. 6 -Helium-SR 1. 1 Open. Daylight : : Config : : All odl-netconf-all 0. 2. 6 -Helium-SR 1. 1 odl-netconf-0. 2. 6 -Helium-SR 1. 1 Open. Daylight : : Netconf : : All odl-base-all 1. 4. 3 -Helium-SR 1. 1 odl-base-1. 4. 3 -Helium-SR 1. 1 Open. Daylight Controller odl-mdsal-all 1. 1. 1 -Helium-SR 1. 1 odl-mdsal-1. 1. 1 -Helium-SR 1. 1 Open. Daylight : : MDSAL : : All odl-yangtools-all 0. 6. 3 -Helium-SR 1. 1 odl-yangtools-0. 6. 3 -Helium-SR 1. 1 Open. Daylight Yangtools All odl-restconf-all 1. 1. 1 -Helium-SR 1. 1 odl-controller-1. 1. 1 -Helium-SR 1. 1 Open. Daylight : : Restconf : : All odl-integration-compatible-with-all 0. 2. 1 -Helium-SR 1. 1 odl-integration-0. 2. 1 -Helium-SR 1. 1 odl-netconf-connector-all 1. 1. 1 -Helium-SR 1. 1 odl-controller-1. 1. 1 -Helium-SR 1. 1 Open. Daylight : : Netconf Connector : : All odl-akka-all 1. 4. 3 -Helium-SR 1. 1 odl-controller-1. 4. 3 -Helium-SR 1. 1 Open. Daylight : : Akka : : All

Bootstrap/Get-Started: Installation Approach Objectives • Modular architecture – • Support different Open. Stack installers (“Base Installer”) – • Customers often have an already established preference for an installer Decouple installation and maintenance of OPNFV specific components from base Open. Stack installer – • Maximize re-use of existing components while allowing for OPNFV specifics and customization 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)

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 Fuel Open. Steak Open. Stack Installer XYZ Phase 1: Vanilla VM-manager install by one of the available installers. Once complete, installer terminates. Open. Daylight Installation, Configuration, Maintenance System level tests (Tests for Tempest, Robot) Additional Modules Phase 2: OPNFV specific installations and maintenance. Goal: Phase 2 to be as independent from base installer as possible

Bootstrap/Get-Started: Installation Approach • BASE-INSTALLATION: Installation of plain-vanilla VM-manager (for BGS, Open. Stack will be used as VM-Manager) • (repeatable) install of a plain vanilla VM-manager (for BGS this is Open. Stack) 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)

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) Open. Stack version Juno Open. Daylight version Helium Distro for compute nodes Centos 7 Centos 6. 5 Distro for Jumphost Centos 7 Public deployment https: //wiki. opnfv. org/get_started/intel_hosting https: //wiki. opnfv. org/get_started/ericsson_hosting References https: //gerrit. opnfv. org/gerrit/gitweb? p=genesis. git; a=summary https: //gerrit. opnfv. org/gerrit/#/c/14/ Current Status Foreman Quick. Stack Status

References • Wiki: https: //wiki. opnfv. org/get_started 12

Thank You 13