516 lines
28 KiB
XML
516 lines
28 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<!DOCTYPE appendix [
|
||
<!-- Some useful entities borrowed from HTML -->
|
||
<!ENTITY ndash "–">
|
||
<!ENTITY mdash "—">
|
||
<!ENTITY hellip "…">
|
||
<!ENTITY plusmn "±">
|
||
]>
|
||
|
||
<appendix xmlns="http://docbook.org/ns/docbook"
|
||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
|
||
xml:id="working-with-roadmaps" label="C">
|
||
<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 Icehouse release and perhaps further afield.</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. The
|
||
<link linkend="release-cycle-diagram">figure</link> 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="5in"
|
||
fileref="figures/releasecyclegrizzlydiagram.png"
|
||
/>
|
||
</imageobject>
|
||
</mediaobject>
|
||
</figure>
|
||
<?hard-pagebreak?>
|
||
<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.</para>
|
||
<para>Release notes are maintained on the OpenStack
|
||
wiki:</para>
|
||
<informaltable rules="all" cellpadding="2" cellspacing="0">
|
||
<thead>
|
||
<tr>
|
||
<th>Series</th>
|
||
<th>Status</th>
|
||
<th>Releases</th>
|
||
<th>Date</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><para>Icehouse</para></td>
|
||
<td><para>
|
||
<link
|
||
xlink:href="https://wiki.openstack.org/wiki/Icehouse_Release_Schedule"
|
||
>Under development, Release
|
||
schedule</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 rowspan="2"><para>Havana</para></td>
|
||
<td rowspan="2"><para>
|
||
Current stable release, security-supported
|
||
</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 rowspan="5"><para>Grizzly</para></td>
|
||
<td rowspan="5"><para>Security-supported</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 rowspan="5"><para>Folsom</para></td>
|
||
<td rowspan="5"><para>Community-supported</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>Community-supported</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>
|
||
<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="http://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/Icehouse/Etherpads">
|
||
Rough-draft design discussions ("etherpads"), from the last design summit</link></para></listitem>
|
||
<listitem><para><link xlink:href="http://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.</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> (http://vmartinezdelacruz.com/how-to-work-with-blueprints-without-losing-your-mind/)
|
||
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>
|
||
(http://status.openstack.org/release/).</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 <link
|
||
xlink:href="https://blueprints.launchpad.net/nova"
|
||
>OpenStack Compute (nova) Blueprints</link>
|
||
(https://blueprints.launchpad.net/nova), <link
|
||
xlink:href="https://blueprints.launchpad.net/keystone"
|
||
>OpenStack Identity (keystone) Blueprints</link>
|
||
(https://blueprints.launchpad.net/keystone), 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">
|
||
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 technical leads of the projects.</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.</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. From Grizzly
|
||
onward (and significantly improved in Havana), 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, a lot of focus has been placed on database migrations. These are now
|
||
better managed, including the use of the Turbo Hipster tool,
|
||
which 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
|
||
Icehouse.</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
|
||
nova-network in production, there has been a
|
||
long-term plan to remove the code in favour of
|
||
the more flexible and full-featured OpenStack
|
||
Networking.</para>
|
||
<para>An attempt was made to deprecate nova-network
|
||
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 nova-network
|
||
traditionally supported. Though significant
|
||
effort has been made to address these concerns,
|
||
nova-network will not be deprecated in the
|
||
Icehouse release. In addition, the Program
|
||
Technical Lead of the Compute project has
|
||
indicated that, to a limited degree, patches to
|
||
nova-network will now again begin to be
|
||
accepted.</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 (IPv6 support, performance
|
||
issues in some scenarios)
|
||
and provides many more features than
|
||
nova-network. 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, nova-network may continue to be a
|
||
viable option for the next 12 to 18 months.</para>
|
||
<para>Similarly, if you have an existing cloud and are
|
||
looking to upgrade from nova-network 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
|
||
nova-network 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. If you must upgrade, please be aware
|
||
that both service and instance downtime is likely unavoidable.</para>
|
||
</section>
|
||
</section>
|
||
<section xml:id="roadmap-ML2">
|
||
<title>Replacement of Open vSwitch Plug-in with Modular Layer
|
||
2</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-nova-v3-api">
|
||
<title>Compute V3 API</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, but this is a great time to
|
||
evaluate the Compute API and provide comments while it
|
||
is being defined. Of particular note is the decision that the V3
|
||
API will not support XML messages—being JSON only. This was
|
||
based on the poor testing of existing XML responses in the V2
|
||
API and the lack of effort to continue to develop and maintain an
|
||
entire second response type. Feedback on this and any such
|
||
change is welcome by responding to the <link xlink:href="https://www.openstack.org/user-survey/">user survey</link>.</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
|
||
deployments.</para>
|
||
</section>
|
||
<section xml:id="roadmap-savanna">
|
||
<title>Hadoop-as-a-Service (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>Though bare-metal deployment has been widely lauded, and
|
||
development continues, the project to replace the Compute bare-metal
|
||
driver will not graduate in Icehouse. A particular blueprint to
|
||
follow is <link xlink:href="https://blueprints.launchpad.net/ironic/+spec/migration-from-nova">
|
||
Migration Path from Nova's BM Driver</link>, which tracks the ability
|
||
to move to the new project from an existing bare-metal deployment.</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 will finally
|
||
see the first integrated release of it in Icehouse.
|
||
Initially, it will only support MySQL, with further
|
||
options available in Juno onward, but it should be able
|
||
to deploy database servers out of the box in a highly
|
||
available way from this release.</para>
|
||
</section>
|
||
<section xml:id="roadmap-marconi">
|
||
<title>Messaging as a Service (Marconi)</title>
|
||
<para>A service to provide queues of messages and notifications
|
||
has entered 'incubation,' meaning if the upcoming
|
||
development cycles are successful, it will be released
|
||
in Juno.</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 the scheduler in
|
||
Block Storage is slated for a boost. Further down the
|
||
track, an effort started this cycle that aims to create
|
||
a holistic scheduler covering both will come to
|
||
fruition.</para>
|
||
<section xml:id="roadmap-volumes">
|
||
<title>Block Storage Improvements</title>
|
||
<para>The team discussed many areas of work at the Icehouse summit,
|
||
including volume migration support, Ceph integration, and access
|
||
control for volumes.</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.</para>
|
||
</section>
|
||
</section>
|
||
</appendix>
|