Project Bootstrap/Get-StartedOverview
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 (“FuncTest”), Lab- and Performance Tests (“Pharos”)
BGS As A Nucleus For Several OPNFV Projects
BGS defined hardware runtime / deployment environment
BGS automated deployment to the hardware environment
BGS automated testing of the deployment
Lab- and Performance Tests (“Pharos”)
Continuous Integration(“Octopus”)
Functional Testing(“FuncTest”)
Bootstrap/Get-Started Components: Overview
OPNFV Confidential
Automatic System Test
Control Node #1(Centos 7)
OpenStack
Control Node #2(Centos 7)
OpenStack
HA
Compute Node #1(Centos 7)
Linux
Control Node #3(Centos 7)
OpenStack
Automatic setup/installTempest (Scenario tests), Rally, Robot
ODL
OpenStack
Compute Node #1(Centos 7)
Linux
OpenStack
HA
OVS
vRouter(OpenWRT)
vIDS(Snort) VNFs
Virtual Forwarder…
vLoop …
OVS
vRouter(OpenWRT)
vIDS(Snort) VNFs
Virtual Forwarder…
vLoop …
Future: ODL clustering
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
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
Bootstrap/Get-Started: Components from OpenDaylightName Version Repository Description
odl-dlux-all 0.1.1-Helium-SR1.1 odl-dlux-0.1.1-Helium-SR1.1
odl-config-persister-all 0.2.6-Helium-SR1.1 odl-config-persister-0.2.6-Helium-SR1.1 OpenDaylight :: Config Persister:: All
odl-aaa-all 0.1.1-Helium-SR1.1 odl-aaa-0.1.1-Helium-SR1.1 OpenDaylight :: AAA :: Authentication :: All Featu
odl-ovsdb-all 1.0.1-Helium-SR1.1 ovsdb-1.0.1-Helium-SR1.1 OpenDaylight :: OVSDB :: all
odl-ttp-all 0.0.2-Helium-SR1.1 odl-ttp-0.0.2-Helium-SR1.1 OpenDaylight :: ttp :: All
odl-openflowplugin-all 0.0.4-Helium-SR1.1 openflowplugin-0.0.4-Helium-SR1.1 OpenDaylight :: Openflow Plugin :: All
odl-adsal-compatibility-all 1.4.3-Helium-SR1.1 odl-adsal-compatibility-0.8.2-Helium-SR1.1 OpenDaylight :: controller :: All
odl-tcpmd5-all 1.0.1-Helium-SR1.1 odl-tcpmd5-1.0.1-Helium-SR1.1
odl-adsal-all 0.8.2-Helium-SR1.1 adsal-0.8.2-Helium-SR1.1 OpenDaylight AD-SAL All Features
odl-config-all 0.2.6-Helium-SR1.1 odl-config-0.2.6-Helium-SR1.1 OpenDaylight :: Config :: All
odl-netconf-all 0.2.6-Helium-SR1.1 odl-netconf-0.2.6-Helium-SR1.1 OpenDaylight :: Netconf :: All
odl-base-all 1.4.3-Helium-SR1.1 odl-base-1.4.3-Helium-SR1.1 OpenDaylight Controller
odl-mdsal-all 1.1.1-Helium-SR1.1 odl-mdsal-1.1.1-Helium-SR1.1 OpenDaylight :: MDSAL :: All
odl-yangtools-all 0.6.3-Helium-SR1.1 odl-yangtools-0.6.3-Helium-SR1.1 OpenDaylight Yangtools All
odl-restconf-all 1.1.1-Helium-SR1.1 odl-controller-1.1.1-Helium-SR1.1 OpenDaylight :: Restconf :: All
odl-integration-compatible-with-all 0.2.1-Helium-SR1.1 odl-integration-0.2.1-Helium-SR1.1
odl-netconf-connector-all 1.1.1-Helium-SR1.1 odl-controller-1.1.1-Helium-SR1.1 OpenDaylight :: Netconf Connector :: All
odl-akka-all 1.4.3-Helium-SR1.1 odl-controller-1.4.3-Helium-SR1.1 OpenDaylight :: Akka :: All
Bootstrap/Get-Started: Installation ApproachObjectives
• 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)
Bootstrap/Get-Started: Installation ApproachTwo Main Phases: “Base Install”, “OPNFV Install and Maintain”
BASE VM Manager INSTALLATION OPNFV-INSTALLATION and MAINTENANCE
OpenStack Installer XYZ
Foreman / Quickstack
Fuel
OpenSteak
OpenDaylightInstallation,
Configuration,Maintenance
System level tests
(Tests for Tempest, Robot)
Additional Modules
Phase 1 Phase 2
Phase 1: Vanilla VM-manager installby one of the available installers.
Once complete, installer terminates.
Phase 2: OPNFV specific installationsand maintenance. Goal: Phase 2 to be as
independent from base installer as possible
• 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)
Bootstrap/Get-Started: Installation Approach
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 Juno
OpenDaylight version Helium 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 QuickStack Status
13
Thank You
Top Related