YouTube Recording: https://www.youtube.com/watch?v=cCdqOxD5G0M Whether you are a newbie to OpenStack looking at building your first cloud or an experienced operator with years of OpenStack success behind you, you've probably spent some time wondering what to expect from the OpenStack project over the next several releases. Will it finally support that new capability you've been waiting for? Should you plan for an upgrade in the next 6 months? While the development community is always working and planning new features, its takes a lot of time on IRC to get a complete view across the different projects. The OpenStack Product WG spent time this cycle working with the project teams and PTLs to understand their priorities for the next several OpenStack releases. Where we have always had an understanding of what's to come in the next release, we're hoping to present a long-term view of the future landscape of OpenStack. In this session, we'll present our findings across the different projects in an effort to give users a glimpse into the OpenStack roadmap

1. 1
What’s Next In
OpenStack
A Glimpse At The Roadmap
Data Collected and Presented by the PRODUCT WORKING GROUP

2. 2
MEET THE PRESENTERS & TEAM
Mike Cohen
Director of Product
Management
Cisco Systems
@mscohen
Product WG Socialization Sub-Team: Raul Flamenco (@flamenco_raul), Independent
Steve Gordon (@xsgordon), Red Hat
Naren Narendra (@narenhn), Cisco
Gavin Pratt (@gavinpratt), HP
Brian Rosmaita (@br14nr), Rackspace
THANK YOU TO THE PTL/CORE TEAMS FOR YOUR TIME!
Geoff Arnold (@geoffarnold), Cisco
Carol Barrett, Intel
Malini Bhandaru (@maliniKB),
Intel
Rob Esker (@r3sk3r), NetApp
Scott Drennan
Principal Product
Manager
Nuage Networks
@dttocs
Shamail Tahir
Sr. Consultant
Technologist
EMC
@ShamailXD
Sean Winn
Cloud/Network
Architect
EMC
@seanmwinn

3. 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. 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 Group
Gather 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. 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 PROCESS
Background 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. 6
LEVEL OF DETAIL BASED APPROACH
Multiple Views of a Multi-Release Roadmap
Ground Floor = Original Data Sources (Blueprints/Specs/Raw Data From PTL Conversations)

7. 7
Nova
Neutron
Cinder
Glance
Trove
Heat
Keyston
e
Ceilo-
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 ROADMAP
This is a GLIMPSE at the collected data and not the actual multi-release roadmap

8. 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
Scalability
Increase scale
Resiliency
Availability or Durability
Manageability
Operations and UX
Modularity
Service/Component
Modularity
Functionality
New Features or
Enhancements to Existing
K L M K L
M
K L M K L M K L M
Nova
Neutron
Cinder
Glance
Keystone
Heat
Swift
Trove
Ceilometer
Horizon
Ironic
Triple O
Sahara
Manila
Oslo
*Infra and Doc projects are listed on the detailed roadmap but not on summary view

9. 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
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. 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. 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 K
S
L
S
TBD Keystone KS LS TBD Triple O K
S
TBD TBD
Glance K
S
L
S
TBD Manila N
A
N
A
TBD Nova K
S
LS TBD
Neutron K
S
L
S
TBD Cinder KS LS TBD Ceilometer K
S
LS TBD
Oslo K
S
L
S
TBD Sahara KS LS TBD Ironic K
S
LS TBD
Swift K
S
L
S
TBD Horizon N
A
N
A
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. 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. 15
APPENDIX: 30 FT VIEWS
(PER PROJECT VIEW)

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

17. 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
GLANCE
Image 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. 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
NEUTRON
NETWORKING

19. 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
OSLO
COMMON 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. 20
• Kilo
– Erasure codes
– Encryption at rest
– Container sharding
– Replication improvements
– Service tokens
– Fast-post
• Liberty
– Kilo Overflow
• “M” Release
– TBD
SWIFT
OBJECT STORE

21. 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
HORIZON
USER INTERFACE

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

23. 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
CINDER
PERSISTENT STORAGE

24. 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
MANILA
FILE 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. 25
SAHARA
ELASTIC 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. 26
TROVE
DATABASE 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. 27
NOVA
VIRTUAL 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. 28
TRIPLE O
DEPLOYMENT
• 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. 29
CEILOMETER
TELEMETRY • 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. 30
IRONIC
BARE 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