1

What’s Next In OpenStack

A Glimpse At The Roadmap

Data Collected and Presented by the PRODUCT WORKING GROUP

2

MEET THE PRESENTERS & TEAM

Mike CohenDirector of Product ManagementCisco Systems @mscohen

Product WG Socialization Sub-Team: Raul Flamenco (@flamenco_raul), IndependentSteve Gordon (@xsgordon), Red HatNaren Narendra (@narenhn), CiscoGavin Pratt (@gavinpratt), HPBrian Rosmaita (@br14nr), Rackspace

THANK YOU TO THE PTL/CORE TEAMS FOR YOUR TIME!

Geoff Arnold (@geoffarnold), CiscoCarol Barrett, Intel Malini Bhandaru (@maliniKB), IntelRob Esker (@r3sk3r), NetApp

Scott DrennanPrincipal Product ManagerNuage Networks @dttocs

Shamail TahirSr. Consultant TechnologistEMC @ShamailXD

Sean WinnCloud/Network ArchitectEMC @seanmwinn

3

DISCLAIMER: ROADMAPS CHANGE.The information presented here is for information only. It is the authors’ interpretation of information collected and does not represent commitments for features or timelines by the projects or PTLs.

As with any open-source project, items proposed by the team can be impacted by number of developers, hurdles, external forces, and change in direction… All decisions for the accepted blueprints/specs will ultimately be at the discretion of the project core teams. We can merely show a snapshot of a point-in-time in the projects’ evolution and the actual “delivery” of items may shift after that point-in-time. We will try our best to keep this snapshot updated.

Image Source: Flickr - Grand_Canyon_NPS, CC 2.0

4

User Committee N+3 members: 3 selected by the board, the TC and an additional nominated representative. An additional N

members elected by the user community.

Enterprise

Focused teams to gather user requirements from segments and represent them

Telco / OPNFV

Application Ecosystem

Large Deployments

API Working Group

Working Groups to address a particular requirement set.These WGs should have a target set of deliverables and conclude when those are met. Maintenance should be a

function of the regular workflows.

Logging

Ops Tools

Monitoring

HPC

Product Working GroupGather requirements from both sets of WGs (Segment and Requirement Oriented) above in the form of user

stories, work with cross-project team to populate blueprints from user stories across projects, work to identify developers to help complete blueprints, communicate with project PTLs and core team to collect feedback on

future directions, and compile this data into a multi-release roadmap that is publicly available.

Multi-Release Roadmap

In summary, facilitate a feedback loop between projects, user community, and working groups.

5

• Product WG Socialization team distributed the task of obtaining feedback for various projects across its members.

• The goal was to figure out what project teams envisioned for the next 18 months of OpenStack.

• Each member asked the PTL/core member the same 4 questions (interviews occurred from 02/15 - 04/15):

– What are you delivering for Kilo?– What do you plan on delivering for the L cycle? (we understand confidence is lower with time)– What do you plan on delivering for the M cycle? (we understand confidence is lower with time)– How can the Product WG help you/your team?

• Raw data available at https://etherpad.openstack.org/p/ProductWG_Roadmap_Glimpse

PTL FEEDBACK PROCESSBackground on Data Collection Process

Note: Some PTLs did change during the last election cycle and the data for all projects was collected prior to the election.

6

LEVEL OF DETAIL BASED APPROACHMultiple Views of a Multi-Release Roadmap

30 Foot

• Summary of User Impacting Changes Per Project/Per Release

10,000 Foot

• Summary of changes by per project/per theme

30,000 Foot

•High-level overview focused on showing which themes are priority for a project in any given release

Ground Floor = Original Data Sources (Blueprints/Specs/Raw Data From PTL Conversations)

7

Nova

Neutron

Cinder

Glance

Trove

Heat KeystoneCeilo-meter

Swift Oslo

Horizon Ironic Manila

Sahara Doc

Infra QA Release

• Roadmap was compiled using feedback from PTLs on directions/items that the project teams are considering for the next few releases.

• The roadmap (content and structure) will evolve as the team continues to refine our processes and workflow for helping compiling a multi-release roadmap

• This session is called a glimpse at the roadmap, a glimpse is the operating word… detailed feedback (in original form) from the PTLs can be found at: https://etherpad.openstack.org/p/ProductWG_Roadmap_Glimpse

• The team started collecting feedback after our inaugural mid-cycle meetup, therefore the project list is not identical to the current set of projects in the OpenStack ‘name space’ (as of Kilo)

• We might need to eventually consider multiple roadmap types (one for developers, one for users)

STATE OF THE ROADMAPThis is a GLIMPSE at the collected data and not the actual multi-release roadmap

8

30,000 FT OVERVIEWThemes Alignment* - Based on ‘Top 3’ Priorities Data (Slide 1 of 1)

*Infra and Doc projects are listed on the detailed roadmap but not on summary view

ScalabilityIncrease scale

ResiliencyAvailability or Durability

ManageabilityOperations and UX

ModularityService/Component

Modularity

FunctionalityNew Features or

Enhancements to Existing

K L M K L M K L M K L M K L M

NovaNeutron

CinderGlance

KeystoneHeatSwiftTrove

CeilometerHorizon

IronicTriple OSaharaManila

Oslo

*Infra and Doc projects are listed on the detailed roadmap but not on summary view

9

10,000 FT OVERVIEWThemes Alignment* - Based on ‘Top 3’ Priorities Data (Slide 1 of 3)

*Infra and Doc projects are listed on the detailed roadmap but not on summary view

Heat Glance

Oslo Swift

Neutron

Scalability Resiliency Manageability Modularity

Kilo

Liberty

“M”Release

Heat(Improved HA)

Heat(Convergence)

Heat(Auto-Scaling Split)

Heat(Upgrades, Templates UX)

Functionality

Heat(Multi-Region & Cinder V2

Support)Oslo(Versioned Objects)

Oslo(Graduate Others)

Oslo(Log Standardization)

Oslo(Graduate Context)

Swift(Erasure Coding, Replication

Enhancements)

Swift(Encryption at Rest)

Swift(Container Sharding)

Glance(Multi-Container Swift)

Glance(Multiple Operational

Enhancements)

Glance(TaskFlow Integration)

Glance(Separate Config. Files)

Glance(Library FE glance_store, Image Conversions, OVF

Support)

Glance(Upgraded Scrubber)

Neutron(Services Split)

Neutron(OVS Support Enhancements)

Neutron(Full IPv6 Support, Initial V3

API, NFV Focus)

Neutron(Continued NFV Focus, Finish

V3)

Continuation of K+ Continuation of K+ Continuation of K+ Continuation of K+ Continuation of K+

Continuation of L+ Continuation of L+ Continuation of L+ Continuation of L+ Continuation of L+

Oslo(Heartbeat for RabbitMQ, Enhanced TaskFlow lib)

Oslo(DebtCollector for Depreciation)

Oslo(Continue Versioned Object

Lib)

Oslo(Re-evaluate ZeroMQ Driver)

10

10,000 FT OVERVIEWThemes Alignment* - Based on ‘Top 3’ Priorities Data (Slide 2 of 3)

*Infra and Doc projects are listed on the detailed roadmap but not on summary view

Keystone Manila

Cinder Sahara

Trove

Scalability Resiliency Manageability Modularity

Kilo

Liberty

“M”Release

Functionality

Keystone(Federation, Token Format)

Keystone(Hierarchical Multi-Tenancy,

enhancements)

Keystone(Restructuring Tests)

Keystone(Depreciate V2)

Continuation of K+ Continuation of K+ Continuation of K+ Continuation of K+ Continuation of K+

Continuation of L+ Continuation of L+ Continuation of L+ Continuation of L+ Continuation of L+

Keystone(Identify and Assignment Split)

Keystone(Improve Ops UX, Horizon

Integration)

Keystone(Keystone Middleware)

Keystone(Single Sign-On)

Keystone(Performance)

Cinder(Incremental Backup, NFS Backup

Driver, )

Cinder(Rolling Upgrades)

Cinder(Multi-Attach, Storage

Policies)

Cinder(Changing Glance Meta for Boot Vols,

New Scheduler Evaluator)

Sahara(Plugins, Better Heat Integration)

Sahara(UX, Horizon Wizards)

Sahara(Stability Improvements)

Manila(Plugins, Pools)

Manila([Un]manage, More Network

options, Horizon)

Manila(More/Robust Tests)

Manila(Replace Libs with Oslo Libs)

Manila(NDU)

Manila(Backup, Replication, More Plugins, Migrate, Resize)

Trove(Big Fixes) Trove

(Replace older Oslo code with Oslo libs)

Trove(Integrate with Ceilometer)

Trove(Plugins, Vertical Cluster Support)

11

10,000 FT OVERVIEWThemes Alignment* - Based on ‘Top 3’ Priorities Data (Slide 3 of 3)

*Infra and Doc projects are listed on the detailed roadmap but not on summary view

Horizon Triple O

Ceilometer Ironic

Nova

Scalability Resiliency Manageability Modularity

Kilo

Liberty

“M”Release

Functionality

TripleO(Puppet Integration)

Continuation of K+ Continuation of K+ Continuation of K+ Continuation of K+ Continuation of K+

Continuation of L+ Continuation of L+ Continuation of L+ Continuation of L+ Continuation of L+

TripleO(Heat Offload for SW

Deployment)

TripleO(Stability Improvements)

Horizon(Scalability)

TripleO(Heat Breakpoints)

TripleO(Upgrades, UX)

TripleO(Kolla Integration)

Horizon(Policy File Support, SSO w/ no discovery, Magic Search, Simplify Launch Instance)

Horizon(Client Side Conversions)

Horizon(Multi-Rack)

Horizon(UX)

Horizon(Enhanced RBAC)

Horizon(UX)

Nova(Start Cells V2)

Nova(V2.1 API)

Nova(No DB DT Upgrades)

Ceilometer(Data Model and Storage)

Ceilometer(Separate Alarming)

Ceilometer(Retire 3rd party w/o CI)

Ironic(API Microversioning,

Standalone Ironic)

Ironic(More Robust HW Drivers, Pluggable Cleaning Steps)

Ironic(Logical Names for Host in

Smaller Envs)

Ironic(State Machine)

Ironic(Split Boot and Deploy ints)

Ironic(Client side of C/S Version Negotiation, Better Feature

Parity in Drivers)

Ironic(UX)

Nova(Continue Cells V2)

Nova(Finish Cells V2)

12

SPECIFICATIONS PER PROJECT* (PER RELEASE)KS = Kilo-Specs, LS = Liberty-Specs

Project Name K L M Project Name K L M Project Name K L M

Heat KS

LS TBD Keystone KS LS TBD Triple O KS

TBD TBD

Glance KS

LS TBD Manila NA NA TBD Nova KS

LS TBD

Neutron KS

LS TBD Cinder KS LS TBD Ceilometer KS

LS TBD

Oslo KS

LS TBD Sahara KS LS TBD Ironic KS

LS TBD

Swift KS

LS TBD Horizon NA NA TBD

Original Format of PTL/Core Team Feedback (“raw data”)https://etherpad.openstack.org/p/ProductWG_Roadmap_Glimpse

*30 Foot Views Available in Appendix

13

You are cordially invited

THANK YOU

Cross Project Product WG Session(Monday @ 3:40P, Room 212)

State Of OpenStack Product Management

(Tuesday @ 11:15A, Room 110)

15

APPENDIX: 30 FT VIEWS (PER PROJECT VIEW)

16

• Kilo– Template Usability with Template Breakpoints– Enhanced Scalability by Delivering Against The

“Convergence” Blueprint– Convergence Observer & Continuous Observer– Convergence Engine– Better “Upgradability” By Adopting Versioned Objects– Multi-Region Support– Keeping Up With APIs (Cinder V2 Support, etc.)– Improved Validation and SW Config Signaling

• Liberty– Improved Support for High Availability– Make ‘Autoscaling’ a Separate Project

• “M” Release– TBD

HEATOrchestration

17

• Kilo– Glance swift store using multiple containers– Separate config file for glance-manage– Metadata definition catalog for tags– Refactoring glance logging– Software metadata definitions– Taskflow integration– Operation to deactivate an image in glance– Glance vmware store to support multiple

datastores– Pass targets to glance’s policy enforcers– Store-capabilities enhancements– Catalog index service– Reload configuration files on sighup signal– Semver utility for DB storage– Notification support for metadata definitions– Metadata multi-value operators support

GLANCEImage Service

• Liberty– Update scrubber to spread deletes

over time (carryover)– Healthcheck middleware (carryover)– Use oslo-versioned-objets to deal with

upgrades (carryover)– HTTPS verification of glance-replicator– Library fronting glance-store– Support image conversion during

import– Support OVS artifact– Glance error codes– Continued code stability including

glance store– Community-level v2 image sharing– Artifacts Experimental API

• “M” Release– TBD

18

• Kilo– Enable NFV– Nova-network to neutron migration– Continued evolution of services (LBaaS, VPNaaS,

FWaaS)– Make neutron scalable operationally– LBaaS API V2.0

• Liberty– Enable NFV (continued)– Full IPv6 support– First implementation of V3 API– BGP support in L3 agent– Neutron functional testing

• “M” Release– NFV (continued)– Finalize V3 API

NEUTRONNETWORKING

19

• Kilo– Versioned object support– Graduate oslo context– Drop namespace packages– Heartbeat Mechanism for

RabbitMQ driver in Oslo.Messaging

– Enhanced TaskFlow Library For Building Workflows into Applications 1st Class Objects

– Standardized Depreciation Process via DebtCollector lib

OSLOCOMMON LIBS • Liberty

– Deferred Kilo features– Oslo.log standardization– Code graduation– Investigate Alternative

Concurrency Models– Continue work on Versioned

Objects Lib• Will be leveraged for rolling upgrade

support across projects

– Re-evaluate 0MQ driver support for Oslo.Messaging

• “M” Release– TBD

20

• Kilo– Erasure codes– Encryption at rest– Container sharding– Replication improvements– Service tokens– Fast-post

• Liberty– Kilo Overflow

• “M” Release– TBD

SWIFTOBJECT STORE

21

• Kilo– Workflow Improvements for Sahara– Expanded Support for OpenStack APIs– Domain Administration using Policy Files– Federated Sign-In (SSO w/o Discovery)– Simplified Workflow for “Launch Instance”– Client Side Conversions– Enhanced Search Capabilities (Magic Search)

• Liberty– Increase scalability (Multi-rack as target)– Target enhancements to help medium/large installs– Increased RBAC Support– User Experience as a Focus

• “M” Release– Scalability as a Focus Area– User Experience as a Focus Area

HORIZONUSER INTERFACE

22

• Kilo– Clean Up Keystone to Keystone Federation– Testing Improvements and restructuring– Token Scaling Cleanup (new token format spec)– Implemented Hierarchical Multi-tenancy– Enhancements for splitting Identity and Assignment

• Liberty– Middleware Stability– Single Sign-On and Integrate w/ Horizon– Token Improvement

• “M” Release– Complete Keystone V3 API– Depreciate Keystone V2 API– Performance Improvements

KEYSTONEIDENTITY

23

• Kilo– NFS and POSIX Backup Drivers– Incremental Backup Support (Swift as Target)– Evaluator, Weighter, and Filter for Volume Scheduling– Rolling Updates Start

• Liberty– Glance Image Meta-Data Editing for Boot Volumes– Volume Multi-Attach– Rolling Upgrades Finish– Storage Policies

• “M” Release– TBD

CINDERPERSISTENT STORAGE

24

• Kilo– Driver Modes– Network Plugins– Share Manage/Unmanage– Pools Support– Improved Functional Tests and

Better Coverage– OpenStack Integration

Enhancements– New Drivers: NetApp single v-

server, RedHat GlusterFS with Ganesha support for NFS, EMC Isilon, Hadoop Distributed File-System, HDS Scale-Out Platform, HP 3PAR, Huawei OceanStor, IBM GPFS with Ganesha support for NFS, Oracle ZFS storage appliance, Quobyte NFS

MANILAFILE SHARES • Liberty

– Support for Non-Disruptive Upgrades

– Requirement for CI from all vendors

– Share resize, migrate, retype, backup, and replication

– Access Groups– Yet more drivers

• “M” Release– TBD

25

SAHARAELASTIC DATA PROCESSING

• Kilo– Cloudera Distribution of Hadoop (CDH)

Support Plugin– MapR Support Plugin– Apache Storm Support Plugin– Better Integration with Heat

• Liberty– UX Improvements (e.g. Wizard for

Sahara pages)– Stability Improvements

• “M” Release– TBD

26

TROVEDATABASE AS A SERVICE

• Kilo– New Data Stores: DB2, Vertica, and CouchDB– Classification of stable versus experimental data

stores (based on test coverage)– Removing depreciated Oslo code and moving to

official Oslo libraries– Significant Bug Fixes (20-30% of team)– Master-Slave Replication Based Upon Global ID

• Liberty– Expand Cluster API (more parameter support)– Add Support for MySQL Clustering– Start Normalizing Test Coverage Across Data

Stores

• “M” Release– Ceilometer Integration (Monitoring)– Barbican Integration (Encrypted Backup Support)

27

NOVAVIRTUAL COMPUTE

• Kilo– Cells V2– Objects Conversion– Preparing to Split-out nova-scheduler– V2.1 API (mainly for better improvement path in the future) – Functional Testing Improvements– Nova-network to Neutron Migration– Bug Squashing– CI Improvements

• Liberty– Continue work on Cells V2– No-downtime DB Upgrades

• “M” Release– Finish Cells V2

28

TRIPLE ODEPLOYMENT

• Kilo– Stackforge Puppet Module Integration– Stepwise Deployment– Improved Validation During Deployment

• Liberty– Focus on Upgrades– Improved Stability– Support More Use Cases in Production– Further Discussion at Liberty Design Summit

• “M” Release– TBD

on

29

CEILOMETERTELEMETRY • Kilo

– Support to add Jitter to Polling Cycles– API Role-Based Access Controls– Improved Event Support– Improved Pipeline Publishing– Additional Meters– IPv6 Support– Gnocchi Dispatch Support for ceilometer-collector– Self-Disabled Pollster Mechanism

• Liberty– Continued Adoption of Gnocchi Project– Begin to Split Ceilometer Elements– Focus on Alarming

• “M” Release– Explore Removing non-tested components– Reduce/Remove Niche Architecture Dependencies

30

IRONICBARE METAL • Kilo

– Proper Modeling of Hardware States– Micro-versioned API– Empowered Hardware Drivers– Integrated ironic-python-agent Deployment RAM Agent– Hardware Introspection In/Out-of-Band– Pluggable Erasure of Nodes– Logical Node Naming– Stand-alone Installation Modules

• Liberty– Completion of State Machine– Split Boot and Deploy Interfaces– Complete Client-Side Version Negotiation

• “M” Release– Additional Feature Coverage Across Hardware Drivers