OpenStack Collaboration Made in

Heaven

06.11.2017

Trinath Somanchi Bharath ThiruveedulaSridhar Ramaswamy,

Ex-PTL, Tacker CISCO NXP VERIZON INDIA

Dharmendra KushwahaNEC

with Tacker, Heat, Mistral and more…

OverviewCross project Collaboration

Need for Collaboration

Understanding the Do’s and Don’t

Case Study

Illustration using Tacker

Agenda

Features - Collaboration with

OpenStack Projects

Collaboration with Heat, Networking-sfc, Mistral and more

Collaboration beyond OpenStack

OPNFV, CNCF, Kubernetes and many more

Summary

Collaboration = Best in class features

Overview

Collaboration is crucial in the land of open source,

and with the rapid growth of projects and

communities, cross-project and cross-community

activities are more important than ever.

Libraries

Sub Projects

Projects

External Communities

Need for Collaboration

Microservices Philosophy

Make each program do one

thing well. To do a new job, build a fresh rather than complicate old programs by adding new "features".

Expect the output of every program

to become the input to another, as yet unknown, program. Don't

clutter output with extraneous information

Design and build software, even

operating systems, to be tried early,

ideally within weeks. Don't

hesitate to throw away the clumsy parts and rebuild

them.

Use tools in preference to

unskilled help to lighten a

programming task, even if you have to detour to build the tools and expect to

throw some of them out after you've finished

using them.

Microservices follows UNIX philosophy which was proposed by Douglas McIlroy

Required for OpenStack

Doing the right feature under right project

umbrella

Embrace Micro Services design

patterns

Collaboration

Collaboration beyond Openstack – Always possible to replace OpenStack project with another project which can complete the feature

– Operators.

Require a Official OpenStack

Project status

Vendor specific feature implementation

Need for Collaboration

Design of New feature

Auto deployment of existing features.

Making something around and within

OpenStack.

Require existing features to your own project.

Going beyond OpenStack, embed external

projects.

Management

Server

Event Service

Authorization

Service

Key Mgmt

Service

Logging

Service

Monitoring

Service

Usage

Tracking

Service

Image

repository

service

Project A

Compute

Services

Storage ServicesNetwork

Services

Neutron

Kuryr

Dragon

Flow

Tacker

Nova

Glance

Magnum

Zun

Cinder

Swift

Manila

Freezer

Identity and

WorkflowKeystone Barbican Mistral

Monitoring

&

Management

Aodh

Ceilometer

Horizon

Monasca

Need for Collaboration

Success Story - Tacker

Features – Collaboration with other projects

Feature Collaboration with Projects

TOSCA template based Orchestration of VNFs HEAT, TOSCA-PARSER

Monitoring Framework, Alarm Monitoring Mistral, Ceilometer

VNF Forwarding Graph Networking – SFC

Secured VIM credentials Barbican

Virtual Infrastructure Management Nova, Neutron, Glance and Keystone

Configuration, Logging Oslo libs

TOSCA-Parser, HEAT-Translator and Tacker

TOSCA Parser

• Parser for TOSCA simple profile in YAML and NFV YAML based specification

• Sub-project of OpenStack - HEAT

HEAT Translator

• OpenStack project to map and translate non-HEAT templates to Heat Orchestration Templates (HOT).

• Sub-Project of OpenStack - HEAT

Tacker

• NFVO and VNFM – NFV block in OpenStack

• All Tacker VNFDs, VNFFGs and NS description files are TOSCA YAML files.

ETSI NFV TOSCA

YAML OpenStack

Tacker

(VNFM and

NFVO)

NSD

VNFD

VNFFGD

Data models

OpenStack Heat

TOSCA Parser

Heat

Translator

Compute Networking Storage Compute Networking Storage Compute Networking Storage

VIMVIM VIM

Multi Site VIM Support

Heat - OpenStack orchestration engine that automates launching

multiple composite cloud applications.

Heat-Translator - map and translate non-Heat (e.g. TOSCA)

templates to Heat Orchestration Template (HOT).

Tosca-Parser - for TOSCA Simple Profile in YAML

Heat ?

Mistral and Tacker

Network Service Descriptor (NSD)

• Mistral driver between NFVO and VNFM will translate TOSCA template into workflow which in turn instantiate a Network Service.

• Mistral Driver will call Mistral interfaces for Network Service requests.

• Wait in PENDING_CREATE state for NS until all VNFs goes to ACTIVE state.

• Decide to move forward/backward in case of partial failure.

Scalable VNF Monitoring

• Mistral is an integral part of tacker system, a long-live Mistral workflow action can be used to do this kind of task.

• Tacker server will generate a VNF monitoring workflow and execute it if there is a VNF configured with monitor policies.

• When the workflow is removed, the VNFM plugin will kill the mistral action via MSG queue

Scalable VIM Monitoring

Long-live mistral workflow.Tacker server will generate a VIM reachability test workflow and execute it if a new vim is registered.The workflow and execution will be removed once the vim is de-registered from tacker server.

Tacker Server Mistral Workflow Conductor Server

DB

Mistral is a workflow service. Most business processes consist of

multiple distinct interconnected steps that need to be executed in

a particular order in a distributed environment.

One can describe such process as a set of tasks and task

relations and upload such description to Mistral so that it takes

care of state management, correct execution order, parallelism,

synchronization and high availability.

Mistral also provides flexible task scheduling so that we can run a

process according to a specified schedule (i.e. every Sunday at

4.00pm) instead of running it immediately.

We call such set of tasks and relations between them a workflow.

Mistral ?

1 2

3

Ceilometer and Tacker

Tacker

(TOSCA)Alarm Framework Ceilometer

The Ceilometer project is a data collection service that provides the ability

to normalise and transform data across all current OpenStack core

components with work underway to support future OpenStack components.

Ceilometer is a component of the Telemetry project. Its data can be used to

provide customer billing, resource tracking, and alarming capabilities across

all OpenStack core components.

Ceilometer

Ceilometer?

1 2

Monasca

Custom

Driver

VNF

• ETSI MANO architecture describes to monitor the VNF to take appropriate action such as fault

management, performance management. Monitoring became an important aspect in MANO

architecture.

• Monitoring Policy in TOSCA template – for single and Multiple VDUs.

• Default backend actions : scaling, respawn, log, and log_and_kill.

Networking-SFC with Tacker - VNFFG

• Abstract VNFFG TOSCA definitions are rendered into

Service Function Chains (SFCs) and Classifiers.

• The SFC makes up an ordered list of VNFs for traffic to

traverse, while the classifier decides which traffic should go

through them.

• Similar to how VNFs are described by VNFDs, VNFFGs are

described by VNF Forwarding Graph Descriptors (VNFFGD).

• After creating a VNFFGD, a VNFFG is instantiated by a

separate Tacker command. This action will build the chain

and classifier necessary to realize the VNFFG.

Service Function Chaining Extension for OpenStack Networking

Fundamentally SFC is the ability to cause network packet flows to route

through a network via a path other than the one that would be chosen by

routing table lookups on the packet’s destination IP address.

It is most commonly used in conjunction with Network Function

Virtualization when recreating in a virtual environment a series of network

functions that would have traditionally been implemented as a collection of

physical network devices connected in series by cables.

Networking-sfc ?

NFVO / VNFM / VNFFG API

Tacker

HeatNeutron

(networking-sfc)

SDN Controller

OVSDB

OVSDB

VNF

vRouter VNF 1 VNF 2

Compute Node A

OVSDB

VNF

DPIVNF 1 VNF 2

Compute Node A

VNFDVNFD

VNFDVNFFGD

VNFDNSD

1

2

3

4

Tacker with Nova, Glance, Keystone, Neutron

Keystone, Glance, Nova and Neutron (Core Services)

– Provide the Virtual Infrastructure Management required for

VNF management in Direct and Indirect mode by VNFM or NFVO.

Neutron, networking-sfc supports VNF Forwarding Graph.

Nova

Neutron

Glance

Cinder Keystone

Tacker

Tacker – uses OpenStack CORE

services to manage the VNFs. OpenStack

with its CORE services forms the VIM.

Barbican with Tacker

Designed for the secure storage, provisioning and management of

secrets. It is aimed at being useful for all environments, including

large ephemeral Clouds.

* Secrets API. It provides access to the secret / keying material stored

in the system, including Private Key/Certificate/Password/SSH Keys

* Secret Metadata API. It allows a user to be able to associate various

key/value pairs with a Secret.

* Containers API. It creates a logical object that can be used to

hold secret references.

* ACL API. It supports access control for secrets and containers.

* Certificate Authorities API. It is used as an interface to interact

with Certificate Authorities.

* Quotas API. It limit on the number of resources that are allowed

to be created.

* Consumers API. It is a way to register as an interested party

for a container.

Barbican ?

Why to collaborate with a OpenStack project that deals with Security?

Tacker supports registering VIM with credentials, which are used by NFVO and VNFM to operate resources in

NFVI. The credentials include username, password, and project information.

When Tacker Server is behind a load balancer, then the operation will fail if the request is not

fulfilled by the server node which created and stored the fernet key. We need a possible solution for syncing

the keys across multiple server nodes. This adds operational complexity for tacker administrators as they add

tacker-server instances for scaling.

Tacker uses Barbican’s Secrets API to restore the password of VIM. And in

future, we can use Barbican to support TLS in Tacker API

Oslo Libraries

Oslo – brings deployment and development experiences consistent across OpenStack projects.

•OpenStack projects share many common design patterns and implementation details.

•Early in the history of OpenStack this resulted in a lot of code being copied out of one project into another.

•The Oslo project was created to address this situation, and to provide a home for common code used by multiple other OpenStack projects.

•Adopting oslo libraries makes a project more similar to the rest of OpenStack, and that consistency in turn improves the Operator/Deployer experience.

Well known Oslo Libraries (not limited to) –

oslo.config : Provides tools for managing configuration option definitions, validation, configuration file

parsing, and command line option processing.

oslo.messaging: Implements common inter-process communication patterns such as notifications and

RPC. It includes drivers for different backends such as RabbitMQ, AMQP 1.0, and ZMQ. This pluggable

backend pattern is common across OpenStack as a way to provide options for deployers familiar with

different tool stacks.

oslo.log: Wrapper around Python’s standard logging tools, coupling them with oslo.config and applying

OpenStack-specific requirements.

Tacker Architecture

Heat

OpenStack

Nova &

Neutron

Infra

Driver

Tacker

NFVO / VNFM / SFC API DB

Monitoring

Driver

Management

DriverSFC Driver

SDN Controller

OVS

Mgmt NetTenant Net

Trend

Micro

VNF

VNFVPN

VNF

6Wind

Turbo

RouterMngrMngr

Monitoring

feedbackService

ConfigurationVNF Forwarding

Graph

YAML

YAMLYAML

YAML

YAML

Monitoring ConfigurationVNF

LCM

NFVI - Compute Node

VNF On-Boarding,

Orchestration

&

Life Cycle Management

Network Service Orchestration

&

VNF Forwarding Graph

Trend Micro VNF

6WindVNF

Brocade VNF

VNF/NS/VNFFG

TOSCA Templates

Horizon GUI

(or) CLI1

2

3 4

5

6

7

Demo

Cross Community Collaboration: OPNFVOPNFV

- Provides blueprints on how to deploy and configure different open source communities together.

- Requirements, use-cases and validation.

- OpenStack for NFV.

OPNFV Project OpenStack Project(s)

NetReady – Investigate and evolve OpenStack Networking to

support NFV usecases.

Neutron – Gluon

Connect network service providers with VMs

Doctor – Create a fault management framework for HA. Ceilometer, Aodh – Notification/Alarm

Vitrage, Congress – Monitoring and Analysis

Multisite – Connected NFV deployments across multiple

geographical locations

OpenStack Core Services,

Kingbird, Tricircle – Centralized Service for multi-region

OpenStack deployments and Networking automation across

neutron servers.

SFC – Provides ordered list of network services stitched

together to create a Network Service Chain.

OpenStack Core Services,

Tacker - VNFM and NFVO, Neutron – Networking-SFC

OVN – Open Virtual Networking for Containerized VNFs and

Edge NFV devices.

Neutron – Networking-OVN

Summary

Tacker

OsloNova

Heat

KeystoneGlance

Mistral

Barbican

Net-SFC

Tacker – Pike Release

Tacker Documentation

https://docs.openstack.org/tacker/latest/

Source Code

http://git.openstack.org/cgit/openstack/tacker

Weekly meeting

#openstack-meeting, Weekly Wednesday 04:30 UTC: 60 mins

IRC

#tacker

What’s next ?

Join us @ Tacker – 102 – Hands-on lab today.

@OpenStac

k

That’s all folks.Questions?

openstack openstack OpenStackFoundation