Cross-project collaboration is something OpenStack community has embraced for a long time. Common libraries like Oslo reduces the time and effort to build a new service. Another way this manifests is in new OpenStack services getting built using existing services to solve an higher level use-case. In this talk we are present how the band of projects comprising of Mistral, Tacker, Neutron, Heat, TOSCA-parser and Barbican came together to build an industry leading ETSI NFV Orchestrator that leveraged the best of these projects. Each of these projects brought in critical functionalities needed towards the final product. You will learn how, when strung together, this solution follows the classic Microservices design pattern that the industry is rapidly adopting.

1. OpenStack Collaboration Made in
Heaven
06.11.2017
Trinath Somanchi Bharath ThiruveedulaSridhar Ramaswamy,
Ex-PTL, Tacker CISCO NXP VERIZON INDIA
Dharmendra Kushwaha
NEC
with Tacker, Heat, Mistral and more…

2. Overview
Cross 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

3. 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

4. Need for Collaboration

5. 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

6. 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

7. 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

8. Compute
Services
Storage ServicesNetwork
Services
Neutron
Kuryr
Dragon
Flow
Tacker
Nova
Glance
Magnum
Zun
Cinder
Swift
Manila
Freezer
Identity and
Workflow
Keystone Barbican Mistral
Monitoring
&
Management
Aodh
Ceilometer
Horizon
Monasca
Need for Collaboration

9. Success Story - Tacker

10. 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

11. 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 ?

12. 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

13. 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.

14. 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
Heat
Neutron
(networking-sfc)
SDN Controller
OVSDB
OVSDB
VNF
vRouter VNF 1 VNF 2
Compute Node A
OVSDB
VNF
DPI VNF 1 VNF 2
Compute Node A
VNFD
VNFD
VNFD
VNFFGD
VNFD
NSD
1
2
3
4

15. 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.

16. 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

17. 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.

18. Tacker Architecture
Heat
OpenStack
Nova &
Neutron
Infra
Driver
Tacker
NFVO / VNFM / SFC API DB
Monitoring
Driver
Management
Driver
SFC Driver
SDN Controller
OVS
Mgmt NetTenant Net
Trend
Micro
VNF
VNFVPN
VNF
6Wind
Turbo
Router
MngrMngr
Monitoring
feedback
Service
Configuration
VNF Forwarding
Graph
YAML
YAML
YAML
YAML
YAML
Monitoring Configuration
VNF
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) CLI
1
2
3 4
5
6
7

19. Demo

20. Cross Community Collaboration: OPNFV
OPNFV
- 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

21. Summary
Tacker
Oslo
Nova
Heat
KeystoneGlance
Mistral
Barbican
Net-SFC

22. 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

23. What’s next ?
Join us @ Tacker – 102 – Hands-on lab today.

24. @OpenStac
k
That’s all folks.
Questions?
openstack openstack OpenStackFoundation