709 lines
27 KiB
XML
709 lines
27 KiB
XML
<?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 <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>
|