openstack/operations-guide
Code Issues Proposed changes
operations-guide/doc/openstack-ops/app_roadmaps.xml
venkatamahesh efce7cfd58 Technical leads of projects => PTL 
The words "technical leads of projects" is replaced by
"Project Team Leads"

Change-Id: I33e48c22934a0882bed6f8c898406be1029adba4
Closes-Bug: #1488309
2015-08-25 13:38:11 +05:30

709 lines
27 KiB
XML
Raw Blame History

<?xml version="1.0" encoding="UTF-8"?>
<appendix label="C" version="5.0" xml:id="working-with-roadmaps"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/1999/xhtml"
xmlns:ns4="http://www.w3.org/2000/svg"
xmlns:ns3="http://www.w3.org/1998/Math/MathML"
xmlns:ns="http://docbook.org/ns/docbook">
<title>Working with Roadmaps</title>
<para>The good news: OpenStack has unprecedented transparency when it comes
to providing information about what's coming up. The bad news: each release
moves very quickly. The purpose of this appendix is to highlight some of the
useful pages to track, and take an educated guess at what is coming up in
the next release and perhaps further afield.<indexterm class="singular">
<primary>Kilo</primary>
<secondary>upcoming release of</secondary>
</indexterm><indexterm class="singular">
<primary>OpenStack community</primary>
<secondary>working with roadmaps</secondary>
<tertiary>release cycle</tertiary>
</indexterm></para>
<para>OpenStack follows a six month release cycle, typically releasing in
April/May and October/November each year. At the start of each cycle, the
community gathers in a single location for a design summit. At the summit,
the features for the coming releases are discussed, prioritized, and
planned. <xref linkend="release-cycle-diagram" /> shows an example release
cycle, with dates showing milestone releases, code freeze, and string freeze
dates, along with an example of when the summit occurs. Milestones are
interim releases within the cycle that are available as packages for
download and testing. Code freeze is putting a stop to adding new features
to the release. String freeze is putting a stop to changing any strings
within the source code.</para>
<figure xml:id="release-cycle-diagram">
<title>Release cycle diagram</title>
<mediaobject>
<imageobject>
<imagedata width="6in" fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/osog_ac01.png"></imagedata>
</imageobject>
</mediaobject>
</figure>
<section xml:id="roadmap-information-available">
<title>Information Available to You</title>
<para>There are several good sources of information available that you can
use to track your OpenStack development desires.<indexterm
class="singular">
<primary>OpenStack community</primary>
<secondary>working with roadmaps</secondary>
<tertiary>information available</tertiary>
</indexterm></para>
<para>Release notes are maintained on the OpenStack wiki, and also shown
here:</para>
<informaltable cellpadding="2" cellspacing="0" rules="all">
<thead>
<tr>
<th>Series</th>
<th>Status</th>
<th>Releases</th>
<th>Date</th>
</tr>
</thead>
<tbody>
<tr>
<td><para>Liberty</para></td>
<td><para><link
xlink:href="https://wiki.openstack.org/wiki/Liberty_Release_Schedule">Under Development</link> </para>
</td>
<td><para>2015.2</para></td>
<td><para>Oct, 2015</para></td>
</tr>
<tr>
<td><para>Kilo</para></td>
<td><para><link
xlink:href="https://wiki.openstack.org/wiki/Kilo_Release_Schedule">Current stable release, security-supported</link> </para>
</td>
<td><para><link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Kilo">2015.1</link></para></td>
<td><para>Apr 30, 2015</para></td>
</tr>
<tr>
<td><para>Juno</para></td>
<td><para><link xlink:href="https://wiki.openstack.org/wiki/Juno_Release_Schedule">Security-supported</link> </para>
</td>
<td><para><link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Juno">2014.2</link></para></td>
<td><para>Oct 16, 2014</para></td>
</tr>
<tr>
<td rowspan="4"><para>Icehouse</para></td>
<td rowspan="4"><para><link xlink:href="https://wiki.openstack.org/wiki/Icehouse_Release_Schedule">End-of-life</link> </para></td>
<td><para><link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse">2014.1</link></para></td>
<td><para>Apr 17, 2014</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2014.1.1">2014.1.1</link> </para></td>
<td><para>Jun 9, 2014</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2014.1.2">2014.1.2</link> </para></td>
<td><para>Aug 8, 2014</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2014.1.3">2014.1.3</link> </para></td>
<td><para>Oct 2, 2014</para></td>
</tr>
<tr>
<td rowspan="6"><para>Havana</para></td>
<td rowspan="6"><para>End-of-life</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Havana">2013.2</link>
</para></td>
<td><para>Apr 4, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.1">2013.2.1</link> </para></td>
<td><para>Dec 16, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.2">2013.2.2</link> </para></td>
<td><para>Feb 13, 2014</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.3">2013.2.3</link> </para></td>
<td><para>Apr 3, 2014</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.4">2013.2.4</link> </para></td>
<td><para>Sep 22, 2014</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.1">2013.2.1</link> </para></td>
<td><para>Dec 16, 2013</para></td>
</tr>
<tr>
<td rowspan="6"><para>Grizzly</para></td>
<td rowspan="6"><para>End-of-life</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly">2013.1</link>
</para></td>
<td><para>Apr 4, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.1.1">2013.1.1</link> </para></td>
<td><para>May 9, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.1.2">2013.1.2</link> </para></td>
<td><para>Jun 6, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.1.3">2013.1.3</link> </para></td>
<td><para>Aug 8, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.1.4">2013.1.4</link> </para></td>
<td><para>Oct 17, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.1.5">2013.1.5</link> </para></td>
<td><para>Mar 20, 2015</para></td>
</tr>
<tr>
<td rowspan="5"><para>Folsom</para></td>
<td rowspan="5"><para>End-of-life</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Folsom">2012.2</link>
</para></td>
<td><para>Sep 27, 2012</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2012.2.1">2012.2.1</link> </para></td>
<td><para>Nov 29, 2012</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2012.2.2">2012.2.2</link> </para></td>
<td><para>Dec 13, 2012</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2012.2.3">2012.2.3</link> </para></td>
<td><para>Jan 31, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2012.2.4">2012.2.4</link> </para></td>
<td><para>Apr 11, 2013</para></td>
</tr>
<tr>
<td rowspan="4"><para>Essex</para></td>
<td rowspan="4"><para>End-of-life</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Essex">2012.1</link>
</para></td>
<td><para>Apr 5, 2012</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2012.1.1">2012.1.1</link> </para></td>
<td><para>Jun 22, 2012</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2012.1.2">2012.1.2</link> </para></td>
<td><para>Aug 10, 2012</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2012.1.3">2012.1.3</link> </para></td>
<td><para>Oct 12, 2012</para></td>
</tr>
<tr>
<td rowspan="2"><para>Diablo</para></td>
<td rowspan="2"><para>Deprecated</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Diablo">2011.3</link>
</para></td>
<td><para>Sep 22, 2011</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2011.3.1">2011.3.1</link> </para></td>
<td><para>Jan 19, 2012</para></td>
</tr>
<tr>
<td><para>Cactus</para></td>
<td><para>Deprecated</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Cactus">2011.2</link>
</para></td>
<td><para>Apr 15, 2011</para></td>
</tr>
<tr>
<td><para>Bexar</para></td>
<td><para>Deprecated</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Bexar">2011.1</link>
</para></td>
<td><para>Feb 3, 2011</para></td>
</tr>
<tr>
<td><para>Austin</para></td>
<td><para>Deprecated</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Austin">2010.1</link>
</para></td>
<td><para>Oct 21, 2010</para></td>
</tr>
</tbody>
</informaltable>
<para>Here are some other resources:</para>
<itemizedlist>
<listitem>
<para><link xlink:href="http://status.openstack.org/release/">A breakdown of
current features under development, with their target
milestone</link></para>
</listitem>
<listitem>
<para><link xlink:href="https://blueprints.launchpad.net/openstack">A list of all
features, including those not yet under development</link></para>
</listitem>
<listitem>
<para><link xlink:href="https://wiki.openstack.org/wiki/Summit/Kilo/Etherpads">Rough-draft design
discussions ("etherpads") from the last design summit</link></para>
</listitem>
<listitem>
<para><link xlink:href="https://review.openstack.org/">List of individual
code changes under review</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="roadmap-influencing">
<title>Influencing the Roadmap</title>
<para>OpenStack truly welcomes your ideas (and contributions) and highly
values feedback from real-world users of the software. By learning a
little about the process that drives feature development, you can
participate and perhaps get the additions you desire.<indexterm
class="singular">
<primary>OpenStack community</primary>
<secondary>working with roadmaps</secondary>
<tertiary>influencing</tertiary>
</indexterm></para>
<para>Feature requests typically start their life in Etherpad, a
collaborative editing tool, which is used to take coordinating notes at a
design summit session specific to the feature. This then leads to the
creation of a blueprint on the Launchpad site for the particular project,
which is used to describe the feature more formally. Blueprints are then
approved by project team members, and development can begin.</para>
<para>Therefore, the fastest way to get your feature request up for
consideration is to create an Etherpad with your ideas and propose a
session to the design summit. If the design summit has already passed, you
may also create a blueprint directly. Read this <link
xlink:href="http://vmartinezdelacruz.com/how-to-work-with-blueprints-without-losing-your-mind/">blog post about how to work with
blueprints</link> the perspective of Victoria Martínez, a developer
intern.</para>
<para>The roadmap for the next release as it is developed can be seen at
<link xlink:href="http://status.openstack.org/release/">Releases</link>.</para>
<para>To determine the potential features going in to future releases, or
to look at features implemented previously, take a look at the existing
blueprints such as&#160;<link
xlink:href="https://blueprints.launchpad.net/nova">OpenStack Compute (nova)
Blueprints</link>, <link xlink:href="https://blueprints.launchpad.net/keystone">OpenStack
Identity (keystone) Blueprints</link>, and release notes.</para>
<para>Aside from the direct-to-blueprint pathway, there is another very
well-regarded mechanism to influence the development roadmap: the user
survey. Found at <link
xlink:href="http://openstack.org/user-survey"></link>, it allows you to
provide details of your deployments and needs, anonymously by default.
Each cycle, the user committee analyzes the results and produces a report,
including providing specific information to the technical committee and
project team leads.</para>
</section>
<section xml:id="aspects-to-watch">
<title>Aspects to Watch</title>
<para>You want to keep an eye on the areas improving within OpenStack. The
best way to "watch" roadmaps for each project is to look at the blueprints
that are being approved for work on milestone releases. You can also learn
from PTL webinars that follow the OpenStack summits twice a
year.<indexterm class="startofrange" xml:id="OSaspect">
<primary>OpenStack community</primary>
<secondary>working with roadmaps</secondary>
<tertiary>aspects to watch</tertiary>
</indexterm></para>
<section xml:id="roadmap-driver-improvements">
<title>Driver Quality Improvements</title>
<para>A major quality push has occurred across drivers and plug-ins in
Block Storage, Compute, and Networking. Particularly, developers of
Compute and Networking drivers that require proprietary or hardware
products are now required to provide an automated external testing
system for use during the development process.</para>
</section>
<section xml:id="roadmap-easier-upgrades">
<title>Easier Upgrades</title>
<para>One of the most requested features since OpenStack began (for
components other than Object Storage, which tends to "just work"):
easier upgrades. In all recent releases internal messaging communication
is versioned, meaning services can theoretically drop back to
backward-compatible behavior. This allows you to run later versions of
some components, while keeping older versions of others.</para>
<para>In addition, database migrations are now tested with the Turbo
Hipster tool. This tool tests database migration performance on copies of
real-world user databases.</para>
<para>These changes have facilitated the first proper OpenStack upgrade
guide, found in <xref linkend="ch_ops_upgrades" />, and will continue to
improve in the next release.<indexterm class="singular">
<primary>Kilo</primary>
<secondary>upgrades in</secondary>
</indexterm></para>
</section>
<section xml:id="nova-network-deprecation">
<title>Deprecation of Nova Network</title>
<para>With the introduction of the full software-defined networking
stack provided by OpenStack Networking (neutron) in the Folsom release,
development effort on the initial networking code that remains part of
the Compute component has gradually lessened. While many still use
<literal>nova-network</literal> in production, there has been a
long-term plan to remove the code in favor of the more flexible and
full-featured OpenStack Networking.<indexterm class="singular">
<primary>nova</primary>
<secondary>deprecation of</secondary>
</indexterm></para>
<para>An attempt was made to deprecate <literal>nova-network</literal>
during the Havana release, which was aborted due to the lack of
equivalent functionality (such as the FlatDHCP multi-host
high-availability mode mentioned in this guide), lack of a migration
path between versions, insufficient testing, and simplicity when used
for the more straightforward use cases <literal>nova-network</literal>
traditionally supported. Though significant effort has been made to
address these concerns, <literal>nova-network</literal> was not be
deprecated in the Juno release. In addition, to a limited degree,
patches to <literal>nova-network</literal> have again begin to be
accepted, such as adding a per-network settings feature and SR-IOV
support in Juno.<indexterm class="singular">
<primary>Juno</primary>
<secondary>nova network deprecation</secondary>
</indexterm></para>
<para>This leaves you with an important point of decision when designing
your cloud. OpenStack Networking is robust enough to use with a small
number of limitations (performance issues in some scenarios, only basic
high availability of layer 3 systems) and provides many more features than
<literal>nova-network</literal>. However, if you do not have the more
complex use cases that can benefit from fuller software-defined
networking capabilities, or are uncomfortable with the new concepts
introduced, <literal>nova-network</literal> may continue to be a viable
option for the next 12 months.</para>
<para>Similarly, if you have an existing cloud and are looking to
upgrade from <literal>nova-network</literal> to OpenStack Networking,
you should have the option to delay the upgrade for this period of time.
However, each release of OpenStack brings significant new innovation,
and regardless of your use of networking methodology, it is likely best
to begin planning for an upgrade within a reasonable timeframe of each
release.</para>
<para>As mentioned, there's currently no way to cleanly migrate from
<literal>nova-network</literal> to neutron. We recommend that you keep a
migration in mind and what that process might involve for when a proper
migration path is released.</para>
</section>
</section>
<section xml:id="roadmap-DVR">
<title>Distributed Virtual Router</title>
<para>One of the long-time complaints surrounding OpenStack Networking was
the lack of high availability for the layer 3 components. The Juno release
introduced Distributed Virtual Router (DVR), which aims to solve this
problem.</para>
<para>Early indications are that it does do this well for a base set of
scenarios, such as using the ML2 plug-in with Open vSwitch, one flat
external network and VXLAN tenant networks. However, it does appear that
there are problems with the use of VLANs, IPv6, Floating IPs, high
north-south traffic scenarios and large numbers of compute nodes. It is
expected these will improve significantly with the next release, but
bug reports on specific issues are highly desirable.</para>
</section>
<section xml:id="roadmap-ML2">
<title>Replacement of Open vSwitch Plug-in with <phrase
role="keep-together">Modular Layer 2</phrase></title>
<para>The Modular Layer 2 plug-in is a framework allowing OpenStack
Networking to simultaneously utilize the variety of layer-2 networking
technologies found in complex real-world data centers. It currently works
with the existing Open vSwitch, Linux Bridge, and Hyper-V L2 agents and is
intended to replace and deprecate the monolithic plug-ins associated with
those L2 agents.</para>
</section>
<section xml:id="roadmap-new-api">
<title>New API Versions</title>
<para>The third version of the Compute API was broadly discussed and
worked on during the Havana and Icehouse release cycles. Current
discussions indicate that the V2 API will remain for many releases, and
the next iteration of the API will be denoted v2.1 and have similar
properties to the existing v2.0, rather than an entirely new v3 API.
This is a great time to evaluate all API and provide comments
while the next generation APIs are being defined. A new working group was
formed specifically to
<link xlink:href="https://wiki.openstack.org/wiki/API_Working_Group">improve
OpenStack APIs</link> and create design guidelines, which you are welcome to join.
<indexterm class="singular"><primary>Kilo</primary>
<secondary>Compute V3 API</secondary>
</indexterm></para>
</section>
<section xml:id="roadmap-triple-o">
<title>OpenStack on OpenStack (TripleO)</title>
<para>This project continues to improve and you may consider using it for
greenfield <phrase role="keep-together">deployments</phrase>, though
according to the latest user survey results it remains to see widespread
uptake.</para>
</section>
<section xml:id="roadmap-savanna">
<title>Data processing service for OpenStack (sahara)</title>
<para>A much-requested answer to big data problems, a dedicated team has
been making solid progress on a Hadoop-as-a-Service project.</para>
</section>
<section xml:id="roadmap-baremetal">
<title>Bare metal Deployment (ironic)</title>
<para>The bare-metal deployment has been widely lauded, and development
continues. The Juno release brought the OpenStack Bare metal drive into the Compute
project, and it was aimed to deprecate the existing bare-metal driver in
Kilo.
If you are a current user of the bare metal driver, a particular blueprint to follow is <link
xlink:href="https://blueprints.launchpad.net/nova/+spec/deprecate-baremetal-driver">
Deprecate the bare metal driver</link>.<indexterm class="singular">
<primary>Kilo</primary>
<secondary>Compute bare-metal deployment</secondary>
</indexterm></para>
</section>
<section xml:id="roadmap-trove">
<title>Database as a Service (trove)</title>
<para>The OpenStack community has had a database-as-a-service tool in
development for some time, and we saw the first integrated
release of it in Icehouse. From its release it was able to deploy database
servers out of the box in a highly available way, initially supporting only
MySQL. Juno introduced support for Mongo (including clustering), PostgreSQL and
Couchbase, in addition to replication functionality for MySQL. In Kilo,
more advanced clustering capability was delivered, in addition to better
integration with other OpenStack components such as Networking.
<indexterm class="singular">
<primary>Juno</primary>
<secondary>database-as-a-service tool</secondary>
</indexterm></para>
</section>
<section xml:id="roadmap-zaqar">
<title>Message Service (zaqar)</title>
<para>A service to provide queues of messages and notifications was released.</para>
</section>
<section xml:id="roadmap-designate">
<title>DNS service (designate)</title>
<para>A long requested service, to provide the ability to manipulate DNS
entries associated with OpenStack resources has gathered a following. The
designate project was also released.</para>
</section>
<section xml:id="roadmap-scheduling">
<title>Scheduler Improvements</title>
<para>Both Compute and Block Storage rely on schedulers to determine where
to place virtual machines or volumes. In Havana, the Compute scheduler
underwent significant improvement, while in Icehouse it was the scheduler in
Block Storage that received a boost. Further down the track, an effort
started this cycle that aims to create a holistic scheduler covering both
will come to fruition. Some of the work that was done in Kilo can be found under the
<link xlink:href="https://wiki.openstack.org/wiki/Gantt/kilo">Gantt
project</link>.<indexterm class="singular">
<primary>Kilo</primary>
<secondary>scheduler improvements</secondary>
</indexterm></para>
<section xml:id="roadmap-volumes">
<title>Block Storage Improvements</title>
<para>Block Storage is considered a stable project, with wide uptake
and a long track record of quality drivers. The team
has discussed many areas of work at the summits,
including better error reporting, automated discovery, and thin
provisioning features.</para>
</section>
<section xml:id="roadmap-python-sdk">
<title>Toward a Python SDK</title>
<para>Though many successfully use the various python-*client code as an
effective SDK for interacting with OpenStack, consistency between the
projects and documentation availability waxes and wanes. To combat this,
an <link xlink:href="https://wiki.openstack.org/wiki/PythonOpenStackSDK">effort to improve the
experience</link> has started. Cross-project development efforts in
OpenStack have a checkered history, such as the <link
xlink:href="https://wiki.openstack.org/wiki/OpenStackClient"> unified client project</link>
having several false starts. However, the early signs for the SDK
project are promising, and we expect to see results during the Juno
cycle.<indexterm class="endofrange" startref="OSaspect" /></para>
</section>
</section>
</appendix>
View Git Blame Copy Permalink