OPNFV Frank Brockners OPNFV TSC Member Distinguished Engineer, - - PowerPoint PPT Presentation

The art of assembling OPNFV

Frank Brockners

OPNFV TSC Member Distinguished Engineer, Cisco

Assembling a Platform for NFV

Enhancements Additions

OPNFV – Systems Integration as an open community effort.

Serving different Audiences – RUN, TEST, CREATE

End-User Developer in active Upstream Projects Does my new patch work at NFV-I system level? Developer

• f new features not

yet in Upstream (NFV specific requirements) How can I get my patches integrated/ accepted (OPNFV and Upstream)? Systems-Integrator/ Tester Could I get a tested foundation that avoids me re-starting all test-work with every new release? Could I get a NFV-I foundation with common UX to run any VNF on?

Deployable NFV-Infrastructure with a common User-Experience to run VNFs

VOID

Towards a Common User Experience

Tools Components

My VNF

“Black Box NFV-Infra”

Theme: “Run my VNF for real” Assemble a set of infrastructure to enable real-world VNF deployments

• Predictable performance –

Deploy to bare metal

• Validated –

Functional testing, multiple test environments

• Repeatable –

Automatic deployment

• Carrier-class –

High availability

Hardware

Clear-cut components: “This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together.” Build with lego-blocks instead

• f using clay.

Doug McIlroy

Focus: “Do One Thing And Do It Well – DOTADIW”

Arno Release: Bottom’s Up Approach to UX: Components Driven Do One Thing And Do It Well - DOTADIW

Fixed Set of Hardware Fixed Set of Components

(“consume upstream”)

(Mostly) Fixed Set of Tools

6 Servers

>= 3 Control nodes, >= 2 Compute nodes, 1 Provisioning node (“jumphost”) (Centos 7, runs test infra and installer VM)

Reference lab hosted by the Linux Foundation

Blade servers with 80G connectivity each (Cisco UCS-B), CIMC management

Test

Tempest, Rally, Robot

Install

Option: Either Fuel, or Foreman/Quickstack

Compute

O/S Nova, KVM

Storage

O/S Glance, O/S Cinder

Network

OpenDaylight, OVS

Infra

RabbitMQ, Corosync, Pacemaker, MySQL

See also: https://wiki.opnfv.org/get_started/get_started_system_state

• Component-selection drives

Platform Defintion

• Enhanced UX achieved through

different composition of components

– Virtual deployments (using nested virtualization – 1 server) – Simple deployments (no HA – 4 servers) – Deployments with HA (6 servers)

Arno Service Release 1 (SR1) ... follows the same bottoms-up approach

Flexibilized Minor version updates Minor version updates & fixes Arno SR1 improves Arno while keeping the platform composition approach

OPNFV – Number of Projects – When Arno was released

OPNFV – Number of Projects – As of Nov 11th, 2015

Arno Brahmaputra

See also: https://wiki.opnfv.org/releases/brahmaputra/release_plan#participating_projects

Do one thing and do it well... for the User Top-down UX definition to complement bottoms-up method

“Define” and “Observe”: Combining…

– “Observer approach” (black box: test driven definition) with – “System level requirements” (white box: requirements and building-block driven definition)

Common user-observable behavior achieved through

– Description of user-observable behavior (requirements, common capabilities). Definition of common building blocks. Comparable to a “law”. Example: “System to support IPv6-only transport network”. – System tests to verify existence of desired user-observable behavior. Comparable to test/check-points/samples that executive powers (“court & police”) do. Testing only observes a portion of the entire system behavior and can never fully describe the entire system behavior: Test samples can be defined to check IPv6 support for a specific set of scenarios.

Rules And Requirements (“Law”) Tests/Samples (“Law enforcement: Police/Court”)

+

Defining a common user-experience for OPNFV: Tests and Gating Conditions

Common UX definition: Definition of user-observable system behavior, common system requirements and common building blocks

Tests Hardware definition

Still a meritocracy: Healthy competition among deploy tools to allow merit to win

https://wiki.opnfv.org/testing https://wiki.opnfv.org/genesis

Project Genesis: Consolidate and Harmonize the UX

• Define common requirements

that all installer projects have to follow

– For Brahmaputra those are: Apex, Compass4NFV, Fuel, JOID

• Genesis project is a democracy

– All installer projects are equally represented in Genesis – Majority votes in case there is no consensus

See also: https://wiki.opnfv.org/genesis

Meritocracy with democratic elements

• OPNFV technical decision making follows standard meritocracy

model

• Genesis consolidates requirements for UX across deployment tools:

Define a baseline

• Installers can continue to differentiate (not on outcome, but on

process like e.g. ease of use, etc.)

– Only baseline “choices” – continue to allow for “choosing” of non-UX impacting capabilities – Installers can install different (and eventually competing) components

Developer of component(s) and Systems Integrator: Test components at system level in a variety of hardware setups

OPNFV Arno Core Infrastructure

• Arno established the key

capabilites for continous deploy and testing

• “Do one thing and do it well”
• Install/Deploy tools & System

Definition – Bootstrap/GetStarted

• CI/CD Pipeline – Octopus
• Docs – OPNFVdocs
• Testing - Functest
• Hardware definition - Pharos

Install/ Deploy Docs Function- Test Automation CI/CD Pipeline Hardware

Systems Integration And Evolution as a Community Effort Automatic Deploy and Test – CI/CD Pipeline

Install on reference system(s) Test on reference system(s)

Lab1 Lab2 Lab3 Lab1 Lab2 Lab3

Integrate & build* as a system

*OPNFV currently composes builts from existing artifacts (e.g. RPMs) rather than builds from source

Choice of existing and new components, System state definition

• OPNFV offers a set of community test labs
• Compliant to OPNFV hardware reference spec
• Individual hardware components for

custom/advanced testing

Build your own lab or choose an OPNFV community lab

See also: https://wiki.opnfv.org/pharos https://www.opnfv.org/sites/opnfv/files/release/pharos-spec.arno.2015.1.0.pdf

Developer of new/evolved components: Get components and associated requirements recognized by Upstream Projects

Private Features and Tests in Arno...

... weren’t really in scope

• “Arno consumed Upstream” – OPNFV purely “composed”
• Already Arno release time, there were already a lot of projects

that were working on additional things, and the number increased since then... For Brahmaputra, there are a lot of projects which compile requirements and perform development – focused on upstream...

OPNFV is very open to new projects...

If your project meet the following, then your project can likely have a life in OPNFV...

• Open Source
• Open Community
• Open Development
• Open Design
• Scope: NFV-I and VIM

Building/evolving features means contributing upstream Team Up To Drive Required Change Upstream

Swimming upstream is hard Team-up to increase the likelihood to succeed Swimming upstream is dangerous

Brahmaputra: Enable Choice

• More infrastructure tool

projects (e.g. installers, etc.)

• More test-tools and test

projects

• More component projects

(e.g. SDN controllers)

• More feature/component

evolution projects

OPNFV Brahmaputra

• Infra-Core and Features/Components

– Infrastructure: Continue to do-one-thing-and-do-it-well – Features/Components: Enable Choice

• Add additional components,

enhance individual components (complement/evolve upstream)

Test CI/CD Pipeline Install Docs Hardware

How to deal with choice and an exponentially growing set of combinations while allowing OPNFV to scale horizontally?

http://www.oxforddictionaries.com/us/definition/learner/subsidiarity

Enable Choice: Scale OPNFV Horizontally

Scale-out approach to new projects - All “well behaving projects” can be integrated Baseline Add new tests? Add new features?

Common Tools, Common User Experience How to deal with different test scenarios? Subsidiarity: You want the test! You create the test case! You integrate the test case into the OPNFV test tools! You make sure that the hardware to run the additional test cases exist. How to deal with new components? Subsidiarity: You want the component! You integrate it into the installers! You create the associated test cases.

Subsidiarity: “It is a fundamental principle of social philosophy, fixed and unchangeable, that one should not withdraw from individuals and commit to the community what they can accomplish by their own enterprise and industry.”

Oswald von Nell-Breuning Pope Pius XI Pope Leo XIII Pope Pius XI, Quadragesimo anno, 1931 https://en.wikipedia.org/wiki/Subsidiarity_(Catholicism)

Focus & Componentize

Do one thing and do it well

Meritocracy

Allow for healthy competition

Democracy

Achieve consistent UX definition

Subsidiarity

Scale horizontally

Open Community Open Source Open Development Open Design NFV-I & VIM Scope

Continous Systems Integration as an Open Community Effort

Thank you

Picture References

• Slide 8:

• Slide 25:

• Slide 30: