1b7058a15c
- Also includes these changes: GlusterFS supports Block Storage Fix options for nova flavor-access-list Fixes bug 1316040 - reference a generic SQL database "once instance" -> "one instance" recover sheepdog doc Change-Id: I81f57c189bb5138c89f0208404f31c4453ec0aac
604 lines
22 KiB
XML
604 lines
22 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 Icehouse release and perhaps further afield.<indexterm class="singular">
|
|
<primary>Icehouse</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="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>Juno</para></td>
|
|
|
|
<td><para>Under
|
|
development</para></td>
|
|
|
|
<td><para><link
|
|
xlink:href="http://opsgui.de/NPFhMW">2014.1</link></para></td>
|
|
|
|
<td><para>Apr 17, 2014</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><para>Icehouse</para></td>
|
|
|
|
<td><para><link xlink:href="http://opsgui.de/1eLzG51">Current stable release, security-supported</link> </para></td>
|
|
|
|
<td><para><link
|
|
xlink:href="http://opsgui.de/NPFhMW">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>Security-supported
|
|
</para></td>
|
|
|
|
<td><para> <link xlink:href="http://opsgui.de/1eLzHFY">2013.2</link>
|
|
</para></td>
|
|
|
|
<td><para>Apr 4, 2013</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><para> <link
|
|
xlink:href="http://opsgui.de/NPFjEI">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>EOL</para></td>
|
|
|
|
<td><para> <link xlink:href="http://opsgui.de/1eLzK4A">2013.1</link>
|
|
</para></td>
|
|
|
|
<td><para>Apr 4, 2013</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><para> <link
|
|
xlink:href="http://opsgui.de/NPFlw8">2013.1.1</link> </para></td>
|
|
|
|
<td><para>May 9, 2013</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><para> <link
|
|
xlink:href="http://opsgui.de/1eLzMtp">2013.1.2</link> </para></td>
|
|
|
|
<td><para>Jun 6, 2013</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><para> <link
|
|
xlink:href="http://opsgui.de/NPFks3">2013.1.3</link> </para></td>
|
|
|
|
<td><para>Aug 8, 2013</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><para> <link
|
|
xlink:href="http://opsgui.de/1eLzNgP">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="http://opsgui.de/NPFmjO">2012.2</link>
|
|
</para></td>
|
|
|
|
<td><para>Sep 27, 2012</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><para> <link
|
|
xlink:href="http://opsgui.de/1eLzOBB">2012.2.1</link> </para></td>
|
|
|
|
<td><para>Nov 29, 2012</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><para> <link
|
|
xlink:href="http://opsgui.de/NPFobr">2012.2.2</link> </para></td>
|
|
|
|
<td><para>Dec 13, 2012</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><para> <link
|
|
xlink:href="http://opsgui.de/1eLzPpd">2012.2.3</link> </para></td>
|
|
|
|
<td><para>Jan 31, 2013</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><para> <link
|
|
xlink:href="http://opsgui.de/NPFos2">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="http://opsgui.de/1eLzSRP">2012.1</link>
|
|
</para></td>
|
|
|
|
<td><para>Apr 5, 2012</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><para> <link
|
|
xlink:href="http://opsgui.de/NPFqjB">2012.1.1</link> </para></td>
|
|
|
|
<td><para>Jun 22, 2012</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><para> <link
|
|
xlink:href="http://opsgui.de/1eLzUsX">2012.1.2</link> </para></td>
|
|
|
|
<td><para>Aug 10, 2012</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><para> <link
|
|
xlink:href="http://opsgui.de/NPFqQs">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="http://opsgui.de/1eLzVwW">2011.3</link>
|
|
</para></td>
|
|
|
|
<td><para>Sep 22, 2011</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><para> <link
|
|
xlink:href="http://opsgui.de/NPFsYy">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="http://opsgui.de/1eLzYsI">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="http://opsgui.de/NPFtvH">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="http://opsgui.de/1eLA1Vm">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://opsgui.de/NPFvnh">A breakdown of
|
|
current features under development, with their target
|
|
milestone</link></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><link xlink:href="http://opsgui.de/1eLA2IT">A list of all
|
|
features, including those not yet under development</link></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><link xlink:href="http://opsgui.de/NPFwaQ">Rough-draft design
|
|
discussions ("etherpads") from the last design summit</link></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><link xlink:href="http://opsgui.de/1eLA43u">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://opsgui.de/NPFy2x">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://opsgui.de/1eLA7wg">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="http://opsgui.de/NPFxf5">OpenStack Compute (nova)
|
|
Blueprints</link>, <link xlink:href="http://opsgui.de/1eLA8An">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
|
|
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.<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. 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.<indexterm class="singular">
|
|
<primary>Icehouse</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> 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 <literal>nova-network</literal> will now again begin to be
|
|
accepted.<indexterm class="singular">
|
|
<primary>Icehouse</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 (IPv6 support, performance issues in some
|
|
scenarios) 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 to 18 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. 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 <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-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="http://opsgui.de/1eLAaba">user survey</link>.<indexterm
|
|
class="singular">
|
|
<primary>Icehouse</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>.</para>
|
|
</section>
|
|
|
|
<section xml:id="roadmap-savanna">
|
|
<title>Data Processing (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="http://opsgui.de/NPFBex"> Migration Path from Nova's BM
|
|
Driver</link>, which tracks the ability to move to the new project from an
|
|
existing bare-metal deployment.<indexterm class="singular">
|
|
<primary>Icehouse</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 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.<indexterm class="singular">
|
|
<primary>Icehouse</primary>
|
|
|
|
<secondary>database-as-a-service tool</secondary>
|
|
</indexterm></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 <phrase
|
|
role="keep-together">Juno</phrase>.</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.<indexterm class="singular">
|
|
<primary>Icehouse</primary>
|
|
|
|
<secondary>scheduler improvements</secondary>
|
|
</indexterm></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="http://opsgui.de/1eLAaYU">effort to improve the
|
|
experience</link> has started. Cross-project development efforts in
|
|
OpenStack have a checkered history, such as the <link
|
|
xlink:href="http://opsgui.de/NPFBLH"> 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> |