What's new in OpenStack Liberty

WHAT’S NEW IN OPENSTACK
LIBERTY
Sean Cohen
Principal Product Manager
October 1st, 2015
Stephen Gordon
Sr. Technical Product Manager

WHAT’S NEW IN OPENSTACK LIBERTY
INTRODUCTION
2
Stephen Gordon
Sr. Technical Product Manager
@xsgordon
Sean Cohen
Principal Product Manager
@SeanCohen_RH

AGENDA
● Liberty Overview
● Project Updates
● Q&A

October
2015
“Mitaka” - is a
city located in
Tokyo
Metropolis,
Japan.
RELEASE TIMELINE
5
“Kilo”
Sèrves,
France is
home to the
Kilogram.
April
2015
“Liberty” - a village in the
Canadian province of
Saskatchewan.
TBD
2016
https://wiki.openstack.org/wiki/Release_Naming
N - Austin Summit
O - Barcelona Summit
TBD
TBD

POLL QUESTION
Which OpenStack release are you currently using, if any?
● None
● Grizzly
● Havana
● Icehouse
● Kilo
● Juno
● Liberty (master)

STATISTICS
OpenStack “Liberty”
● 27,000+ commits
● 163,000+ reviews
● ~160 corporate contributors
● ~2100 individual contributors
http://stackalytics.com/?release=liberty&metric=commits
http://stackalytics.com/?release=liberty&metric=reviews

THE OPENSTACK BIG TENT
● Previously projects were either in the integrated release or not,
which meant different things to different people and potentially
excluding projects that were just as much a part of the OpenStack
community.
● Changes toward a “big tent” model endeavor to:
○ More clearly define what it means to be an OpenStack project.
○ Be more broadly inclusive that projects that meet this definition, even
those which compete with each other.
○ Provide a more precise taxonomy for navigating the ecosystem of
OpenStack projects.

DEFINING THE BIG TENT
● Project aligns with the OpenStack Mission
● Project follows the OpenStack way (“4 opens”):
○ Open Source
○ Open Community
○ Open Development
○ Open Design
● Project ensures basic interoperability with the rest of OpenStack
● Project has an active team of one or more contributors
● Project meets any policies the TC requires all projects to meet
http://governance.openstack.org/reference/new-projects-requirements.html

TAGGING THE BIG TENT
● Tag types:
○ Technical Committee Managed
○ Team Description
○ Project Assertions
○ Release Management
○ Vulnerability Management
http://governance.openstack.org/reference/tags/index.html
● E.g:
○ Starter kit, approved release
○ Team diversity
○ Follows deprecation policy
○ Has stable branches, cycle-wit
○ Vulnerability team managed
● Tags introduced to help operators navigate all the projects that make
up OpenStack.

API MICRO-VERSIONING
● Compute API v2 has been in place for some time, expanded by
adding “extensions”, lots of them.
● Determined that implementing new major version of API (v3) would
be too difficult:
○ User impact
○ Developer overhead
● Micro-versions aim to:
○ Make it possible to evolve the API incrementally
○ Provided backwards compatibility to REST API users
○ Improve code cleanliness to make doing the “right thing” easier

API MICRO-VERSIONING (cont.)
● Use a single monotonic counter of the form where X.Y where:
○ X will only be changed due to a significant backwards incompatible API
change being made. Expected to rarely never be incremented.
○ Y will change when making any change to the API.
● Client will specify version it supports, e.g.:
○ X-OpenStack-Nova-API-Version: 2.114
● In Kilo, v2.0 API code was still used to serve v2.0 requests, v2.0 API
was frozen
● In Liberty, v2.1 API code handles all requests - implementing both
the v2.0 and v2.1 API endpoints

EXPERIMENTAL ONLINE SCHEMA CHANGES
● Endeavours to make database schema changes occur online (either with no
service outage or a minimized one)
● Instead of using migration scripts:
○ Compares running schema against the model defined in Nova
○ Generates DDL statements to close the gap
○ Optionally, executes the DDL to make the running schema match the model
● Schema changes that aren’t in use today or are difficult to automate are not
catered to in the initial online schema migration implementation.
● Currently extremely experimental, requires further work in subsequent
releases. Not yet a recommended path to upgrading.

INSTANCE HIGH AVAILABILITY
● Provided using external tools such as Pacemaker (previously
demonstrated at Red Hat Summit with Intel, Dell).
● Liberty allows for cutting down on the time to evacuate guests after
detecting node failure:
○ “Mark host down”/“force down” API allows external tooling to notify
Nova that a host is down before periodic tasks would normally detect it.
○ As soon as host has been explicitly marked down evacuation can
commence, triggered by the external tool (e.g. Pacemaker fence agent).

VIRTIO NETWORKING PERFORMANCE
● Default behavior provides a single VirtIO-net queue:
○ Restricts scale of guest protocol stack
○ Does not scale with # of vCPUs
○ Guests cannot transmit or receive in parallel (only one TX/RX queue)
● Multiple queues provide greater throughput when:
○ Packets are relatively large
○ Guest is active on many connections at the same time
○ Number of queues == number of vCPUs
● Enabling:
○ hw_vif_multiqueue_enabled=true|false (default false)
○ Nova will match number of queues to number of vCPUs

IMPROVED BAREMETAL DRIVER SUPPORT
● Maturing and increased driver support:
○ Dell, HP, Open CloudServer, SeaMicro, Cisco UCS, Fujitsu, AMT
○ Generic and virtual driver coverage
■ Wake-on-LAN power driver
■ SSH driver support for VirtualBox, Parallels, Virsh
● Specific driver enhancements:
○ HP (iLO)
■ UEFI secure boot
○ Fujitsu Primergy
■ booting from virtual media using NFS or CIFS supported

QUALITY OF SERVICE
● QoS is a general term referring to capability of a network to provide
better service to select network traffic.
○ Various tools exist and may be applied in different places.
○ Examples include traffic classification, policing, marking, and shaping.
● OpenStack tenant administrator may want to offer different service
levels based on application needs and available bandwidth.
● In Liberty OpenStack Networking (“Neutron”) provides a new
extensible API for defining QoS policies.

QUALITY OF SERVICE (cont.)
● Policies can be applied:
○ Per port - a specific Neutron port has the policy applied.
○ Per network - all ports plugged on the Neutron network inherit the
policy.
● Initial support allows rate limiting the traffic a virtual machine can
send - packets beyond the specified rate are dropped:
○ Virtual interfaces using OVS
○ Virtual Functions (VFs) using SR-IOV
● Policy can be applied, modified, or removed dynamically.

PLUGGABLE IP ADDRESS MANAGEMENT
● Deployers have a need to integrate OpenStack with their existing
infrastructure that uses external IPAM solutions.
● Historically most OpenStack Networking (“Neutron”) plug-ins
leverage an embedded IPAM implementation.
○ While DHCP provider could be changed, allocation logic could not.
● Liberty introduces pluggable IPAM framework into Neutron.
○ Reference implementation remains unchanged but there is now a plug-
in system to support external IPAM offerings.

ROLE-BASED ACCESS CONTROL
● Network sharing in Neutron has historically been binary, a network is
shared with every tenant or not shared at all.
● Liberty introduces a RBAC table that allows finer grained sharing of
Neutron networks between tenants.
○ Allow only specific tenants to attach virtual machines to the network.
○ Eliminate the ability for some tenants to create networks at all instead
only allow attachment to pre-created networks corresponding to their
project.

IDENTITY
● Support for tokenless authorization with X.509 SSL client certificate
● Per identity provider Web Single Sign-On (WebSSO) support.
● Additional attributes added to SAML assertion in order to map user
and project domains.

GENERIC VOLUME MIGRATION
● Volume migration allows you to migrate a volume with its data
between two backends in a manner that is transparent to users and
workloads.
● The original API implementation assumed that both source and
destination volumes can be attached locally via iSCSI.
● The new generic API now allows more drivers such as Ceph RBD to
perform the migration functionality.

IMPORT/EXPORT SNAPSHOTS
● Complementing feature for the import/export volume function.
● Allows to import volumes snapshot from one Cinder to another.
● The imported snapshots can be used as volume templates.
● Allows to import "non" openstack snapshots already on a backend-
device. Where, export snapshots should work the same way as
export volumes.

VOLUME REPLICATION (v2)
● Provides a new implementation for replication of volumes between
backends that leaves the bulk of the work to the driver.
● Provides basic administrative API methods to perform actions such
as enable/disable and fail-over.
● First iteration of this new API supports only a single remote device,
with limited tenant visibility.
● Allowing to introduce new replication drivers in the Mitaka cycle.

NON-DISRUPTIVE BACKUP
● Allows OpenStack administrators to perform a non-disruptive
volume backup while the volume is still attached to a guest.
○ By allowing the backup driver to:
■ Take a temporary snapshot
■ Attach the temporary snapshot
■ Do backup from the temporary snapshot
■ Detach the temporary snapshot
■ Cleanup temporary snapshot
(Until now, volumes had to be detached first before they could be backed up)

GENERIC IMAGE CACHE
● With this new feature backends are able to use cached glance
images when creating volumes from images.
● If enabled, and the cinder internal tenant is configured, it will create
a minimal sized clone of a volume the first time it is downloaded
from glance. The original will then be extended to full size.
● Any following requests to create a volume from an image will be
able to do a volume clone from the image-volume cache entry
instead of downloading the image data from glance again.

IMAGE SIGNING AND ENCRYPTION
● Protect image integrity by ensuring no modifications occur after the
image is uploaded by a user.
● Supports both signing of the image and signature validation of
bootable images when used.

OBJECT STORAGE
● Increasing ring partition power
○ A new swift-ring-tool has been introduced to increase or decrease the
partition power of an OpenStack Swift ring without the need to copy all
data to a new cluster.
● Symbolic links
○ Swift has gained the notion of a symbolic link (“symlink”) object allowing
to do aliases or multiple names to the same object.
○ This object will reference another object, where GET, HEAD, POST, and
OPTIONS requests for a symlink object will operate on the referenced
object.

DATA PROCESSING
● Spark now available on YARN based (generation 2) distributions
● Storm elastic data processing (EDP) support
● EDP jobs can now be suspended and resumed
● Can now launch multiple clusters in parallel
● Hadoop generation 1 support has been deprecated
● Manila as a runtime data source

DATABASE AS A SERVICE
● DB Cluster Scaling - Adds cluster grow and shrink functionality
● Expanding Backup/Restore capabilities to MongoDB
● Adding MariaDB support
● Guestagent configuration manager functionality - provides ability to
allow custom configuration overrides
● Floating IP for Vertica management master node - provides external
access to Vertica cluster management console
● Database log file downloads - create API for end user to access log
files stored in swift containers

CONVERGENCE UPDATES
● Initial steps in longer term trend towards supporting a convergence
model for Heat stack updates.
● Liberty introduces an (optional) mode to persist per-resource state
during stack updates.
○ Improved fault tolerance, including recovery from a failure of the Heat
engine.
○ Improved scalability, potential to spread work over engine workers in a
more granular way than was previously possible.
● Lays groundwork for auto-healing style features in future.

STACK TAGS
● Allow categorization of Heat stacks when they are created.
● Includes ability to mark a stack as hidden based on a tag. E.g.:
○ Cloud provider wants to use a heat stack for behind the scenes
orchestration such as automating networking configuration when
launching an instance

BROADER PROJECT SUPPORT
● New Heat resources for emerging projects including:
○ Barbican
○ Mistral
○ Manila
○ Monasca
○ Designate
● Zaqar integration for SoftwareConfig
○ SoftwareDeployment resources now support providing metadata and
signalling via Zaqar as an alternative to existing transports.

CEILOMETER SPLIT UP
● Lack of clarity around how to
best use ceilometer for
different use cases in the past.
● Split into multiple sub-projects,
each aimed at one high level
use and using its own storage
backend:
○ Collectors
○ Metrics (“Gnocchi”)
○ Alarms (“AODH”)
○ Events

CEILOMETER TIME SERIES METRICS
● Ceilometer’s poor
performances on large scale
metrics API requests was one
of the biggest issues
● Gnocchi (Time Series
Database as a Service)
project was created to
address this under the
Ceilometer program
umbrella.

SHARED FILE SYSTEMS SERVICE (MANILA)
● Share Extend & Shrink
○ New REST API for extending and
shrinking shares
● Share migration
○ Share Migration allows a share
to be migrated from one host
pool to another hostpool, as well
as allowing to perform migration
between different backends.
● Big data (Sahara) support for Manila as a data source

CONTAINERS SERVICE (MAGNUM)
● API service developed by the OpenStack Containers Team.
● Aims to make container orchestration engines (COE) first class
resources in OpenStack.
● Uses Heat to orchestrate deploying and configuring an OS image
which contains Docker and a COE on virtual machines or bare-metal.
Liberty enhancements:
● Smart(er) scale down for Kubernetes clusters.
● High availability (2N) for Kubernetes master node.
● Ability to act as a CA (stepping stone to TLS support etc.)

Zaqar is a multi-tenant cloud messaging service for web developers. The
service enables cloud developers to send messages between various
components.
Liberty enhancements include:
● Pre-Signed URLs: auth-less URLs to access resources
● Persistent transport (websocket): Persistent connections and
streamed API calls.
● Email push-notifications: Notify users over email on messages for
certain topics.
MESSAGE SERVICE (ZAQAR)

Which projects in the OpenStack “big tent” would you like to hear more
about in the future?
● Key management (Barbican)
● DNS as a Service (Designate)
● Application catalog (Murano)
● Governance service (Congress)
● Workflow service (Mistral)
● Key-value store as a Service (MagnetoDB)
● Deployment (TripleO)
● Benchmark service (Rally)
POLL QUESTION

WHAT’S NEW IN OPENSTACK LIBERTY49
OPENSTACK SUMMIT TOKYO

THANK YOU
plus.google.com/+RedHat
linkedin.com/company/red-hat
youtube.com/user/RedHatVideos
facebook.com/redhatinc
redhatstack.com
twitter.com/RedHatNews

What's new in OpenStack Liberty

More Related Content

What's hot (19)

Viewers also liked (12)

Similar to What's new in OpenStack Liberty (20)

More from Stephen Gordon (12)

Recently uploaded (20)

What's new in OpenStack Liberty