openstack
/
openstack-manuals
Code Issues Proposed changes

Release candidate for a stable/folsom branch. 

Did all steps in http://wiki.openstack.org/Documentation/Release.

Next need to let CI team know this is the branch we want.

Rebased against master.

Change-Id: Ie2b85880ba30328de2c14f00849cde6892226d03
This commit is contained in:
annegentle 2012-11-09 15:23:25 -06:00
parent dcf0496298
commit cdd232957d
14 changed files with 121 additions and 898 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/src/docbkx/cli-guide/pom.xml
View File

@ -50,7 +50,7 @@
<plugin>
<groupId>com.rackspace.cloud.api</groupId>
<artifactId>clouddocs-maven-plugin</artifactId>
<version>1.5.0</version>
<version>1.5.1</version>
<executions>
<execution>
<id>goal1</id>
@ -78,7 +78,7 @@
<enableDisqus>1</enableDisqus>
<disqusShortname>os-cliguide</disqusShortname>
<enableGoogleAnalytics>1</enableGoogleAnalytics>
<googleAnalyticsId>UA-17511903-6</googleAnalyticsId>
<googleAnalyticsId>UA-17511903-1</googleAnalyticsId>
<generateToc>
appendix toc,title
article/appendix nop

4
doc/src/docbkx/cli-guide/src/bk-cli-guide.xml
View File

@ -4,9 +4,9 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:html="http://www.w3.org/1999/xhtml" version="5.0"
xml:id="openstack-cli-guide">
xml:id="openstack-cli-guide-folsom">
<title>OpenStack CLI Guide</title>
<para> Each OpenStack project has a Command-Line-Interface (CLI)
<para>Each OpenStack project has a Command-Line-Interface (CLI)
that interacts with the service's REST API. </para>
<xi:include href="cli_overview.xml" />

4
doc/src/docbkx/common/glossary/pom.xml
View File

@ -54,7 +54,7 @@
<plugin>
<groupId>com.rackspace.cloud.api</groupId>
<artifactId>clouddocs-maven-plugin</artifactId>
<version>1.5.0</version>
<version>1.5.1</version>
<executions>
<execution>
<id>goal1</id>
@ -80,7 +80,7 @@
<enableDisqus>1</enableDisqus>
<disqusShortname>openstackdocs</disqusShortname>
<enableGoogleAnalytics>1</enableGoogleAnalytics>
<googleAnalyticsId>UA-17511903-6</googleAnalyticsId>
<googleAnalyticsId>UA-17511903-1</googleAnalyticsId>
<!--<generateToc>
appendix toc,title
article/appendix nop

14
doc/src/docbkx/common/nova_cli_userdata.xml
View File

@ -6,10 +6,18 @@
version="5.0"
xml:id="inserting_userdata">
<title>Providing User Data to Instances</title>
<para><literal>User Data</literal> is a special key in the metadata service which holds a file that cloud aware applications within the guest instance can acccess. For example the <link xlink:href="https://help.ubuntu.com/community/CloudInit">cloudinit</link> system is an opensource package from Ubuntu that handles early initialization of a cloud instance that makes use of this <literal>user data</literal>.
</para>
<para><literal>User Data</literal> is a special key in the metadata
service which holds a file that cloud aware applications within
the guest instance can access. For example the <link
xlink:href="https://help.ubuntu.com/community/CloudInit"
>cloudinit</link> system is an open source package from Ubuntu
that handles early initialization of a cloud instance that makes
use of this <literal>user data</literal>. </para>
<para>This user-data can be put in a file on your local system and then passed in at instance creation with the flag <literal>--user-data &lt;user-data-file&gt;</literal> for eample:<screen>
<para>This user-data can be put in a file on your local system and
then passed in at instance creation with the flag
<literal>--user-data &lt;user-data-file&gt;</literal> for
example:<screen>
<prompt>$</prompt> <userinput>nova boot --image ubuntu-cloudimage --flavor 1 --user-data mydata.file</userinput></screen></para>
</section>

11
doc/src/docbkx/openstack-compute-admin/bk-compute-adminguide.xml
View File

@ -5,8 +5,8 @@
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:html="http://www.w3.org/1999/xhtml"
version="5.0"
xml:id="openstack-compute-admin-manual">
<?rax pdf.url="../bk-compute-adminguide-trunk.pdf"?>
xml:id="openstack-compute-admin-manual-folsom">
<?rax pdf.url="../bk-compute-adminguide-folsom.pdf"?>
<title>OpenStack Compute Administration Manual</title>
<info>
<author>
@ -24,9 +24,9 @@
<year>2012</year>
<holder>OpenStack LLC</holder>
</copyright>
<releaseinfo>trunk</releaseinfo>
<releaseinfo>Folsom, 2012.2</releaseinfo>
<productname>OpenStack Compute</productname>
<pubdate>2012-09-17</pubdate>
<pubdate>2012-11-09</pubdate>
<legalnotice role="apache2">
<annotation>
<remark>Copyright details are filled in by the template.</remark>
@ -47,6 +47,9 @@
<date>2012-11-09</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Folsom release of this document.</para>
</listitem>
<listitem>
<para>Adds Cinder Volume service configuration and troubleshooting information.</para>
</listitem>

17
doc/src/docbkx/openstack-install/bk_openstackinstallguide.xml
View File

@ -5,7 +5,7 @@
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:html="http://www.w3.org/1999/xhtml"
version="5.0"
xml:id="openstack-compute-admin-manual">
xml:id="openstack-install-manual-folsom">
<?rax subtitle.font.size="20px"?>
<title>OpenStack Install and Deploy Manual -
<phrase os="rhel;centos;fedora">Red Hat</phrase>
@ -24,9 +24,10 @@
<year>2012</year>
<holder>OpenStack LLC</holder>
</copyright>
<releaseinfo>trunk</releaseinfo>
<releaseinfo>Folsom, Compute 2012.2, Network 2012.2, Object Storage
1.4.8</releaseinfo>
<productname>OpenStack</productname>
<pubdate>2012-10-10</pubdate>
<pubdate>2012-11-09</pubdate>
<legalnotice role="apache2">
<annotation>
<remark>Copyright details are filled in by the template.</remark>
@ -51,6 +52,16 @@
as well as sample configuration files. </para>
</abstract>
<revhistory>
<revision>
<date>2012-11-09</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Folsom release of this document.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2012-10-10</date>
<revdescription>

2
doc/src/docbkx/openstack-install/pom.xml
View File

@ -13,7 +13,7 @@
<properties>
<!-- This is set by Jenkins according to the branch. -->
<release.path.name>trunk</release.path.name>
<release.path.name>local</release.path.name>
<comments.enabled>1</comments.enabled>
<operating.system>yum</operating.system>
<!-- This is set by Jenkins to run twice for each similar operating system group -->

21
doc/src/docbkx/openstack-network-connectivity-admin/bk-quantum-admin-guide.xml
View File

@ -16,9 +16,9 @@
xmlns:db="http://docbook.org/ns/docbook"
version="5.0"
status="final"
xml:id="Quantum-admin-guide">
<?rax pdf.url="../bk-quantum-admin-guide-trunk.pdf"?>
<title>OpenStack Quantum Administration Guide</title>
xml:id="Quantum-admin-guide-folsom">
<?rax pdf.url="../bk-quantum-admin-guide-folsom.pdf"?>
<title>OpenStack Network (Quantum) Administration Guide</title>
<info>
<author>
<personname>
@ -32,8 +32,8 @@
<holder>OpenStack</holder>
</copyright>
<releaseinfo>Folsom (2012.2)</releaseinfo>
<productname>OpenStack Quantum</productname>
<pubdate>2012-09-18</pubdate>
<productname>OpenStack Networking (Quantum)</productname>
<pubdate>2012-11-09</pubdate>
<legalnotice role="apache2">
<annotation>
<remark>Copyright details are filled in by the template.</remark>
@ -46,6 +46,17 @@
<revhistory>
<!-- ... continue adding more revisions here as you change this document using the markup shown below... -->
<revision>
<date>2012-11-09</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Folsom release of this document.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2012-09-18</date>
<revdescription>

4
doc/src/docbkx/openstack-network-connectivity-admin/pom.xml
View File

@ -13,7 +13,7 @@
<properties>
<!-- This is set by Jenkins according to the branch. -->
<release.path.name>unknown</release.path.name>
<release.path.name>local</release.path.name>
<comments.enabled>1</comments.enabled>
</properties>
<!-- ################################################ -->
@ -123,7 +123,7 @@
<move failonerror="false"
file="${basedir}/target/docbkx/pdf/bk-quantum-admin-guide.pdf"
tofile="${basedir}/target/docbkx/webhelp/${release.path.name}/openstack-network/admin/bk-quantum-admin-guide-trunk.pdf"/>
tofile="${basedir}/target/docbkx/webhelp/${release.path.name}/openstack-network/admin/bk-quantum-admin-guide-${release.path.name}.pdf"/>
<!--Deletes leftover uneeded directories -->

834
doc/src/docbkx/openstack-network-connectivity-admin/quantum-admin-guide.xml
View File

@ -1,834 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book[
<!-- Some useful entities borrowed from HTML -->
<!ENTITY ndash "&#x2013;">
<!ENTITY mdash "&#x2014;">
<!ENTITY hellip "&#x2026;">
<!ENTITY plusmn "&#xB1;">
]>
<book xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:m="http://www.w3.org/1998/Math/MathML"
xmlns:html="http://www.w3.org/1999/xhtml"
xmlns:db="http://docbook.org/ns/docbook"
version="5.0"
status="final"
xml:id="Quantum-admin-guide">
<?rax pdf.url="../quantum-admin-guide-trunk.pdf"?>
<title>OpenStack Quantum Administration Guide</title>
<info>
<author>
<personname>
<firstname/>
<surname/>
</personname>
</author>
<copyright>
<year>2011</year>
<year>2012</year>
<holder>OpenStack</holder>
</copyright>
<releaseinfo>Essex (2012.1)</releaseinfo>
<productname>OpenStack Quantum</productname>
<pubdate>2012-04-28</pubdate>
<legalnotice role="apache2">
<annotation>
<remark>Copyright details are filled in by the template.</remark>
</annotation>
</legalnotice>
<abstract>
<para>This document is intended for administrators interested in running the OpenStack
Quantum Virtual Network Service. </para>
</abstract>
<revhistory>
<!-- ... continue addding more revisions here as you change this document using the markup shown below... -->
<revision>
<date>2012-05-17</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Further clarifications around using nova-manage for Quantum networks.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2012-05-14</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Add description of how to delete networks.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2012-04-28</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Add link for <citetitle>Quantum API Guide</citetitle>. </para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2012-04-23</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Essex-final Update </para>
<itemizedlist spacing="compact">
<listitem><para>Clarify limitations around nova-manage, Melange, mulit_host, and L3/NAT
gateways.</para> </listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2012-02-29</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Essex-4 update </para>
<itemizedlist spacing="compact">
<listitem><para>remove workarounds for E-3 install issues</para> </listitem>
<listitem><para>fix dependencies for source install</para> </listitem>
<listitem><para>mention new plugins</para> </listitem>
<listitem><para>change nova link to floating ip docs from catcus to diablo docs</para> </listitem>
<listitem><para>add example of using --nic</para></listitem>
<listitem><para>update keystone example to work with new CLI syntax</para></listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2012-01-31</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Essex-3 update (2).</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2011-12-15</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Essex-2 update.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2011-09-22</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Initial draft.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
</revhistory>
</info>
<chapter xml:id="Preface-d1e71">
<title>Preface</title>
<para>Quantum is a project to provide "network connectivity as
a service" between entities managed by other OpenStack
services (e.g., vNICs from the OpenStack Nova compute
service).</para>
<section xml:id="Intended_Audience-d1e85">
<title>Intended Audience</title>
<para>This guide is intended to assist OpenStack
administrators looking to run an OpenStack cloud that
leverages Quantum for advanced networking. This
document only covers the process of installing,
configuring, and running Quantum. </para>
<para>The user should also have access to a plugin
providing the implementation of the Quantum service.
Several plugins are included in the Quantum
distribution: </para>
<itemizedlist spacing="compact">
<listitem>
<para>Openvswitch - Implementing Quantum with Open vSwitch for the KVM and
XenServer compute platforms.</para>
</listitem>
<listitem>
<para>Cisco - Implementing Quantum for deployments using Cisco UCS blades and
Nexus switches for KVM compute platforms.</para>
</listitem>
<listitem>
<para>Linux Bridge - Implementing Quantum with the Linux Bridge for the KVM
compute platforms. </para>
</listitem>
<listitem>
<para>Nicira NVP - Implementing Quantum using the Nicira Network Virtualization
Platform (NVP) for KVM and XenServer compute platforms. </para>
</listitem>
<listitem>
<para>Ryu - Implementing Quantum using the Ryu OpenFlow Controller for KVM
compute platforms. </para>
</listitem>
<listitem>
<para>NEC OpenFlow - Implementing Quantum using
Trema Sliceable Switch OpenFlow Controller or
NEC ProgrammableFlow Controller for KVM compute platforms.
</para>
</listitem>
</itemizedlist>
<para>Plugins can also be distributed separately from
Quantum. </para>
<para>You should also be familiar with running the
OpenStack Nova compute service as described in the
Nova documentation. </para>
</section>
<section xml:id="Document_Change_History-d1e118">
<title>Document Change History</title>
<para>The most recent changes are described in the table below:</para>
<?rax revhistory?>
</section>
<section xml:id="resources"><title>Resources</title>
<para>For more information on Quantum and the other
network-related projects, see the Quantum page on the
OpenStack wiki (<link
xlink:href="http://wiki.openstack.org/Quantum"
>wiki.openstack.org/Quantum</link>). </para>
<para>For information about programming against the
Quantum API, see the <link
xlink:href="http://docs.openstack.org/incubation/openstack-network/developer/quantum-api-1.0/content/"
><citetitle>Quantum API
Guide</citetitle></link>.</para>
<para>We welcome feedback, comments, and bug reports at
<link
xlink:href="http://bugs.launchpad.net/Quantum"
>bugs.launchpad.net/Quantum</link>. </para></section>
<?hard-pagebreak?>
</chapter>
<chapter xml:id="Overview-d1e369">
<title>Overview</title>
<para>
This section describes the high-level concepts and components of a Quantum deployment.
</para>
<section xml:id="WhatIsQuantum">
<title>What is Quantum?</title>
<para>Quantum is a "virtual network service" that aims to
provide a powerful API to define the network
connectivity between devices from other OpenStack
services. The Quantum service has an API that presents
a logical abstraction for describing network
connectivity. The service relies on a Quantum plugin
to manage virtual and/or physical switches within the
cloud data center to make sure those devices forward
packets according to the behavior defined in the
logical API model. This notion of a plugin is similar
to how Nova can use different types of hypervisors to
implement the same virtual server API. </para>
<para>
The Quantum API utilizes the following logical abstractions:
</para>
<itemizedlist>
<listitem> <para> Network: An isolated L2 segment, analogous to a
single physical L2 switching device with an
arbitrary number of ports. </para> </listitem>
<listitem> <para> Port: Provide a connection point to a Quantum network.
Ports can also be configured to apply various network
security, QoS, monitoring, etc. policies.
Such policies are currently exposed by API extensions.
</para> </listitem>
<listitem> <para> Attachment: Identifier of an interface device to
be ''plugged in'' to a Quantum port, such as a vNIC from Nova.
</para> </listitem>
</itemizedlist>
<para>
For a detailed description of the Quantum API abstractions and their attributes,
please see the Quantum API Guide.
</para>
</section>
<section xml:id="Architecture">
<title> Quantum Architecture </title>
<para>
This section describes the high-level components of a Quantum deployment.
</para>
<section xml:id="SwitchInfrastructure">
<title>Switching Infrastructure</title>
<para>
At its core, Quantum controls the network connectivity seen by other OpenStack resources
like Nova vNICs by managing the switching infrastructure
within the cloud data center. Exactly which switches need to be managed depends on the
plugin in use. For example, a plugin may manage only the vswitch running on
compute server, or it may manage both the vswitch and adjacent physical switches.
</para>
</section>
<section xml:id="QuantumAwareServices">
<title>Quantum-Aware OpenStack Services</title>
<para>
A Quantum-aware OpenStack service (e.g., Nova) must inform
Quantum about individual interface devices (e.g., Nova vNICs) that can be plugged into
Quantum networks. This interaction enables a Quantum plugin to associate a port on
a managed virtual/physical switch with a particular interface device identifier (and
thus, ultimately with a port on a Quantum network).
</para>
</section>
<section xml:id="QuantumService">
<title>Quantum Service</title>
<para> The Quantum Service is a python process that runs
the Quantum API web server and is responsible for
loading a Quantum plugin and passing each API call
to the Quantum plugin for processing. This process
is commonly run on a ''controller'' host along
with other OpenStack services (e.g., nova-api,
nova-scheduler), but can also be run stand-alone. </para>
</section>
<section xml:id="QuantumPlugin">
<title>Quantum Plugin</title>
<para>
The role of the Quantum plugin is to translate logical network modifications received from the
Quantum Service API and map them to specific operations on the switching infrastructure.
A plugin may be open source or proprietary, and may be specific to a single type of switching
infrastructure, or work across switches of many different types/vendors.
Plugins are able to expose advanced capabilities beyond L2 connectivity using API extensions.
</para>
</section>
</section>
</chapter>
<chapter xml:id="Installation-d1e436">
<title>Quantum Setup</title>
<para>
This chapter covers how to install the Quantum Service and get it up and running.
</para>
<section xml:id="SeletingAHost-d1e444">
<title>Selecting a Host</title>
<para>
The Quantum Service is a python process, similar to other OpenStack
projects like OpenStack Nova. If your deployment uses a ''controller host''
to run centralize OpenStack Nova components, you can deploy Quantum
on that same host. However, Quantum is entirely standalone and can be
deployed on its own server as well.
</para>
<para>
If you are building a host from scratch to use for Quantum, we recommend using a
recent versions of
Ubuntu (11.10 or newer) or Red Hat Enterprise Linux (version 6.x) as these are the
best-tested platforms.
</para>
</section>
<section xml:id="GettingQuantum-d1e445">
<title>Installing Quantum</title>
<para>This section describes the different options for installing Quantum. Regardless
of how it is installed, a Quantum installation provides two executables:<itemizedlist>
<listitem>
<para>quantum-server : a daemon that implements the Quantum virtual network
service. If running from packages, an init script should be installed (e.g.,
/etc/init.d/quantum-server) for starting/stopping the service and logs
are sent to /var/log/quantum/quantum-server.log . </para>
</listitem>
<listitem>
<para>quantum : a CLI utility for manually driving the Quantum API (note: in
most common use cases, the Quantum API is primarily driven by another
service, for example OpenStack Nova, and this CLI is used only for
simple testing or troubleshooting).</para>
</listitem>
</itemizedlist></para>
<para>Quantum has two configuration files quantum.conf and plugins.ini . The location
of these files, referred to as $QUANTUM_CONF_DIR in text below, depends on the
installation option chosen and is described below. </para>
<section xml:id="Package-Install-d1e445">
<title>Installing from Packages</title>
<para>As with other OpenStack components such as Nova, Glance, etc., the preferred
mechanism for getting Quantum is installing it via packages that are compatible
with your Linux platform. A list of Linux distributions that package Quantum is
available at: <link xlink:href="http://wiki.openstack.org/QuantumPackages">
http://wiki.openstack.org/QuantumPackages</link>. </para>
<para>After installing from packages, $QUANTUM_CONF_DIR is /etc/quantum. </para>
</section>
<section xml:id="Source-Install-d1e445">
<title>Installing from Source</title>
<note><para>The instructions below will work only for releases Essex-4 and beyond. </para> </note>
<para>If you cannot install Quantum from distribution packages, you can download the
both the python-quantumclient-&lt;version&gt;.tar.gz
and quantum-&lt;version&gt;.tar.gz files from
<link xlink:href="https://launchpad.net/quantum/+download">https://launchpad.net/quantum/+download</link>.
</para>
<note><para> The Quantum server code currently depends on code in python-quantumclient,
so the client code must always be downloaded and installed. </para></note>
<para> First, install python setup tools. For example, on Ubuntu: </para>
<literallayout class="monospaced">sudo apt-get install python-setuptools python-dev libxslt1-dev</literallayout>
<para> Then install the client and server packages using setup tools. For example, on Ubuntu:</para>
<literallayout class="monospaced">tar xzf python-quantumclient-&lt;version&gt;.tar.gz
tar xzf quantum-&lt;version&gt;.tar.gz
cd python-quantumclient-&lt;version&gt;
sudo python setup.py install
cd ..
cd quantum-&lt;version&gt;
sudo python setup.py install</literallayout>
<para>After the install, the executables "quantum-server" and "quantum" should be in
your path, just as if you had installed from packages. </para>
<para>Run setup.py with the "-h" option to see other install options. </para>
<para>After installing from source, quantum-server
will not automatically find a config file unless
it is specified as a command-line parameter to the
deamon, for example:</para>
<literallayout class="monospaced">quantum-server quantum-&lt;version&gt;/etc/quantum.conf</literallayout>
<para> If you wish to run quantum-server with no argument, you can copy the quantum
config directory in your source tarball to /etc/quantum . For example:
file to /etc/quantum, for example: </para>
<literallayout class="monospaced">sudo mkdir /etc/quantum
sudo cp quantum-&lt;version&gt;/etc/* /etc/quantum</literallayout>
</section>
<section xml:id="Source-Run-dle445">
<title>No Installation (Running from Source)</title>
<note><para>Running from source with no installation is primarily useful for developers and
is usually not relevant to users.
</para></note>
<para> You only need to download the main quantum-&lt;version&gt;.tar.gz file
from <link xlink:href="https://launchpad.net/quantum/+download">
https://launchpad.net/quantum/+download</link>,
as the python-quantumclient code will be installed as a dependency.</para>
<para> First, install dependencies. For example, on Ubuntu: </para>
<literallayout class="monospaced">sudo apt-get install python-setuptools python-pip python-virtualenv git gcc python-dev libxslt1-dev</literallayout>
<para> Next, untar the code and install dependencies using pip. On Ubuntu: </para>
<literallayout class="monospaced">tar xzf quantum-&lt;version&gt;.tar.gz
cd quantum-&lt;version&gt;
sudo pip install -r tools/pip-requires</literallayout>
<para>Then, from within the Quantum source directory, you can
run the unit tests to confirm that the dependencies are correctly installed:</para>
<literallayout class="monospaced">./run_tests.sh -N</literallayout>
<para>All tests should print a green 'OK'. The end of the test output may print a
few pep8 errors depending on your version of pep8 installed. These can be safely
ignored. </para>
<para>When running from source, be sure source that your PYTHONPATH environment
variable includes the root directory of the Quantum source tree. The
quantum-server binary will be run from the local bin/ directory within the
source, and the quantum CLI client will be installed as part of the pip install. </para>
<para>When running from source, $QUANTUM_CONF_DIR is the etc/ directory within the
Quantum source directory. For example, from the top of the Quantum source directory, run:</para>
<literallayout class="monospaced">bin/quantum-server</literallayout>
</section>
</section>
<section xml:id="SelectingPlugin-d1e445">
<title>Selecting a Plugin</title>
<para>The plugin used by the Quantum Service is configured using the plugins.ini found
in $QUANTUM_CONF_DIR. By default, Quantum is configured to use a ''FakePlugin'' that
will let you make API calls, but does not actually manage any switches. To change to
another plugin, edit the following line in the plugins.ini file to point to your
plugin of choice: </para>
<literallayout class="monospaced">provider = quantum.plugins.SamplePlugin.FakePlugin </literallayout>
<para>Quantum plugins can be distributed with the main Quantum binaries or distributed
separately. </para>
<para>The plugin should include its own documentation indicating plugin-specific
dependencies, installation procedures, plugin-specific configuration files, and the
''provider'' value that should be specified in the main plugins.ini configuration
file. </para>
<para>The documentation for the plugins shipped with Quantum are located in:</para>
<itemizedlist spacing="compact">
<listitem> <para> Open vSwitch: <link xlink:href="http://openvswitch.org/openstack/documentation/"
>http://www.openvswitch.org/openstack/documentation</link>
</para> </listitem>
<listitem> <para> Cisco: quantum/plugins/cisco/README and <link xlink:href="http://wiki.openstack.org/cisco-quantum"
>http://wiki.openstack.org/cisco-quantum</link>
</para> </listitem>
<listitem> <para> Linux Bridge: quantum/plugins/linuxbridge/README and
<link xlink:href="http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin"
>http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin</link>
</para> </listitem>
<listitem> <para> Nicira NVP: quantum/plugins/nicira/nicira_nvp_plugin/README and
<link xlink:href="http://www.nicira.com/support">
http://www.nicira.com/support </link>.
</para> </listitem>
<listitem> <para> Ryu: quantum/plugins/ryu/README and
<link xlink:href="http://www.osrg.net/ryu/using_with_openstack.html">
http://www.osrg.net/ryu/using_with_openstack.html </link>.
</para> </listitem>
<listitem> <para> NEC OpenFlow: quantum/plugins/nec/README and
<link xlink:href="http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin">
http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin</link>.
</para> </listitem>
</itemizedlist>
</section>
<section xml:id="Running-d1e447">
<title>Running the Service</title>
<para>If installed from packages, the recommend approach is to use the init script: </para>
<literallayout class="monospaced">/etc/init.d/quantum-server start</literallayout>
<para>If installed or running from source, the service can also be invoked directly:</para>
<literallayout class="monospaced">quantum-server</literallayout>
<para>A successful start of the Quantum service with default settings will have output
that ends with a line similar to. If running from an init script, this output will be
in the file /var/log/quantum/quantum-server.log .</para>
<literallayout class="monospaced">DEBUG [eventlet.wsgi.server] (2094) wsgi starting up on http://0.0.0.0:9696/ </literallayout>
<para>By default the service uses TCP port 9696 and listens on all IP addresses. To edit
this and other Quantum Service settings, edit quantum.conf in the Quantum
configuration directory. Editing this file can also be used to enable any extensions
supported by the plugin. See your plugin documentation for more details. </para>
<para>To use a non-standard location for quantum.conf, run quantum-server directly and
provide it as an argument when running the server: </para>
<literallayout class="monospaced">quantum-server /path/to/quantum.conf</literallayout>
</section>
<section xml:id="Validation-d1e447">
<title>Validating the Setup</title>
<para>You can use the basic Quantum API client CLI to validate your
setup. While still running the Quantum service, run the following command from the
same host to confirm that the client can communicate with Quantum service API
running your plugin: </para>
<literallayout class="monospaced">quantum create_net quantum-fake-tenant net1 </literallayout>
<para>
This command creates a Quantum network named 'net1' for a non-existent tenant named 'quantum-fake-tenant'.
The resulting output should resemble:
</para>
<literallayout class="monospaced">Created a new Virtual Network with ID: 0a649eca-3764-417c-91a7-eb51291d4bb9
for Tenant: quantum-fake-tenant </literallayout>
<para>
This validation confirms that the Quantum service is able to communicate with the Quantum
plugin and that the Quantum plugin is able to perform basic API operations. It does not
test whether the Quantum plugin is correctly communicating with your switch infrastructure.
See your plugin documentation for additional validation steps.
</para>
<para>
To experiment more with basic Quantum API commands, invoke the CLI utility with
no arguments to see all available commands:
</para>
<literallayout class="monospaced">list_nets &lt;tenant-id&gt; [filterspec ...]
create_net &lt;tenant-id&gt; &lt;net-name&gt;
unplug_iface &lt;tenant-id&gt; &lt;net-id&gt; &lt;port-id&gt;
plug_iface &lt;tenant-id&gt; &lt;net-id&gt; &lt;port-id&gt; &lt;iface-id&gt;
update_port &lt;tenant-id&gt; &lt;net-id&gt; &lt;port-id&gt; &lt;params&gt;
show_port_detail &lt;tenant-id&gt; &lt;net-id&gt; &lt;port-id&gt;
show_net &lt;tenant-id&gt; &lt;net-id&gt;
delete_port &lt;tenant-id&gt; &lt;net-id&gt; &lt;port-id&gt;
delete_net &lt;tenant-id&gt; &lt;net-id&gt;
list_nets_detail &lt;tenant-id&gt; [filterspec ...]
show_net_detail &lt;tenant-id&gt; &lt;net-id&gt;
show_iface &lt;tenant-id&gt; &lt;net-id&gt; &lt;port-id&gt;
update_net &lt;tenant-id&gt; &lt;net-id&gt; &lt;new-name&gt;
show_port &lt;tenant-id&gt; &lt;net-id&gt; &lt;port-id&gt;
list_ports_detail &lt;tenant-id&gt; &lt;net-id&gt; [filterspec ...]
create_port &lt;tenant-id&gt; &lt;net-id&gt;
list_ports &lt;tenant-id&gt; &lt;net-id&gt; [filterspec ...]</literallayout>
<para> Invoking the CLI utility with no arguments displays additional command-line
options to, for example, specify an alternate Quantum server IP address or port. </para>
</section>
<?hard-pagebreak?>
</chapter>
<chapter xml:id="QuantumManager-d1e450">
<title>Using Quantum with Nova Compute</title>
<para>
This chapter covers how to run the OpenStack Nova compute service
such that Nova uses Quantum (rather than its internal L2 networking logic)
to implement networks. In this configuration,
nova-manage calls to create/delete networks are proxied to Quantum, and Nova itself
automatically creates/deletes Quantum ports for each vNIC when a virtual server is
created or destroyed. The result is that Quantum can be used with Nova without any need
for administrators or tenants to directly contact the Quantum API.
</para>
<section xml:id="EnablingQuantumManager-d1e453">
<title>Running nova-network with Quantum Manager</title>
<para>Within Nova, the nova-network process manages VM network connectivity and related
network capabilities (e.g., IP Address management, DHCP, L3 + NAT forwarding, VPN).
Nova supports plugging in different implementation of ''managers'' for this network
service, and Quantum takes advantage of this by creating a standard Quantum Manager
that communicates with Quantum to allow Nova and Quantum to integrate. </para>
<para>To enable the Quantum Manager, your nova-network service must specify the
following flag: </para>
<literallayout class="monospaced">network_manager=nova.network.quantum.manager.QuantumManager </literallayout>
<para>Nova defaults to connecting to Quantum on localhost using the standard port. The
"quantum_connection_host" and "quantum_connection_port" flags can override these
defaults. </para>
<para>With Quantum Manager, you can run only one instance of the nova-network process at a time.
In particular, this means that a "multi_host" configuration where nova-network runs on each
compute host is not supported.
A common configuration is to run nova-network on a "nova controller" host along with
nova-schedule, and have an active-passive high-availability strategy that restarts nova-network
on another host if the main controller host fails.
</para>
</section>
<section xml:id="Vifplugging-d1e453">
<title>Quantum Compatible Vif-Plugging in Nova</title>
<para>
As described in the Architecture
section, a service like Nova must be made aware of Quantum such that
a Quantum Plugin can associate an attachment-id passed in via the Quantum
API with a port on a vswitch or physical switch managed by the plugin.
</para>
<para> In Nova, this is done by specifying that the nova-compute service use a type of
''vif-plugging'' that is compatible with your Quantum plugin. A Quantum plugin's
documentation should specify the nova-compute options it requires for vif-plugging.
Usually this will include setting the vif-driver option for your virt-layer (e.g.,
''libvirt_vif_driver'' or ''xenapi_vif_driver'') to point to a vif-driver class that
is specified in your plugin documentation. Depending on the vif-driver selected, the
plugin documentation may require that additional configuration options are set as
well (e.g., ''libvirt_vif_type''). </para>
</section>
<section xml:id="Using-dle455">
<title> Defining VM Network Connectivity </title>
<para>
With Nova, the network manager is responsible for much more than
simply creating L2 connectivity. Among other things, the network
manager is responsible for:
</para>
<itemizedlist spacing="compact">
<listitem> <para>Defining vNICs when a VM is first created. </para> </listitem>
<listitem>
<para>Attaching VM vNICs to an L2 network. </para>
</listitem>
<listitem>
<para>Assigning each VM vNIC a fixed IP address from a subnet associated with
its L2 network. </para>
</listitem>
<listitem>
<para>Optionally providing a "gateway router" to connect private L2 networks to
a public network using NAT.</para>
</listitem>
</itemizedlist>
<para>By default, the Quantum Manager determines the set of vNICs and fixed IPs for a VM
based on networks statically created by the cloud administrator using nova-manage
(see below for instructions on creating such networks). </para>
<para>For each vNIC created, the Quantum Manager will create a port on the Quantum
network and attach the vNIC. If the VM is later terminated, Quantum Manager will
destroy the associated Quantum port. </para>
<section xml:id="Net-Create-dle455">
<title>Creating/Deleting Networks</title>
<note><para> When creating networks, nova-manage must be run on the host that nova-network is running on.
This is different from how network creation works for other network managers. When invoking
nova-manage, make sure it picks up a config file that specifies
network_manager=nova.network.quantum.manager.QuantumManager </para></note>
<note><para> The content in this section is specific to how Quantum integrates with Nova in the Essex (2012.1)
release.
In future releases, networks will be created by calling the Quantum API directly. </para></note>
<note><para> Networks created using other Nova network managers are not compatible with Quantum. When using
Quantum with nova, you must start with a fresh Nova database to make sure that no previous networks
created using other network managers exist. </para></note>
<para>To create a network using Quantum Manager, run: </para>
<literallayout class="monospaced">nova-manage network create --label=public --fixed_range_v4=8.8.8.0/24</literallayout>
<para>When this command is invoked, the Quantum Manager will contact the Quantum Service
to create a corresponding Quantum network, and likewise will create an IPAM
subnet using the specified fixed range. </para>
<para>By default, networks are "global" in the sense that they are shared by all tenants
(i.e. projects in Nova). To create a tenant-specific network, specify the
"--project_id" argument when creating the network. For example: </para>
<literallayout class="monospaced">nova-manage network create --label=tenant2-private --fixed_range_v4=10.0.0.0/24 --project_id=10daaef1-b481-42a6-8653-7a42e982e409</literallayout>
<para>This project_id should be the tenant UUID from keystone. To view all keystone tenant UUIDs,
run the following command as a keystone admin user:</para>
<literallayout class="monospaced">keystone tenant-list</literallayout>
<para>When a new VM is created, it is given a vNIC for each global network, as well as a
vNIC for each network owned by the tenant associated with the VM. This lets
users create hybrid scenarios where a VM has a vNIC both on a shared public
network and on a private tenant-specific network. </para>
<para>Networks are deleted by specifying their UUID (specifying their IP range is not sufficient):</para>
<literallayout class="monospaced">nova-manage network delete --uuid 174d677f-7d15-4d7f-9d93-43feaae25d4d</literallayout>
<note><para>Quantum networks can only be created or deleted via nova-manage.
None of the "nova-manage network modify"
commands should be used when Quantum Manager is enabled.</para> </note>
</section>
<section xml:id="Net-Priorities-dle455">
<title>Network Priorities</title>
<para>To provide a mechanism for ordering multiple vNICs on a VM, Quantum Manager has a
notion of an integer ''priority'' for each network. When a VM has multiple
vNICs, the vNICs are added in ascending priority order (i.e., 0 is highest
priority). The priority of a network can be specified at network creation.
Consider a deployment where all VMs should have two vNICs: the first (e.g.,
eth0) connected to the shared public network and a second (e.g., eth1) connected
to a private tenant network. </para>
<para>To do this, first create the shared network: </para>
<literallayout class="monospaced">nova-manage network create --label=public --fixed_range_v4=8.8.8.0/24 --priority=0 </literallayout>
<para>Then, for each with tenant with UUID X, create a private network: </para>
<literallayout class="monospaced">nova-manage network create --label=tenantX-private --fixed_range_v4=10.0.0.0/24 --project_id=X --priority=1 </literallayout>
<note><para>To allow the CIDR address range for different networks to overlap, you must be using Melange
for IP Address Management (see: Using Melange IPAM below). </para></note>
<para>If a network is created with no ''priority'', the network has priority 0. Networks
should be created such that a VM is never associated with multiple networks of
the same priority, as the order of vNICs will be undefined. </para>
</section>
<section xml:id="Net-Gateways-dle455">
<title>Network Gateway Routers and Floating IPs</title>
<para>Each Quantum network can have a gateway router attached. Similar to
a nova-network deployment with VLANManager, this gateway router functionality provide
VMs on private networks with access to a public network. This gateway provides SNAT
to a public network, as well as ''floating IPs''.
</para>
<para>With Quantum Manager, a NAT gateway will be attached
to each network if the Nova configuration
specifies a valid "L3 driver". Nova defaults to
specifying the 'nova.network.l3.LinuxNetL3'
driver, which corresponds to the same L3 + NAT
implementation used by the nova-network process
configured to use VlanManager. In this model, a
"network controller" host has two NICs and acts as
a NAT gateway between an "internal" network with
compute hosts and an "external" network (e.g.,
used for Internet access). Quantum allows a model
where nova-network is deployed in an
"active-backup" high-availability model, but does
not support the "multi_host" mode where
nova-network runs actively on each compute host. </para>
<para> Specifying a Null L3 driver will mean no gateway devices are
connected to any Quantum networks:</para>
<literallayout class="monospaced">l3_lib=nova.network.l3.NullL3</literallayout>
<para>Similar to the VlanManager, the gateway implemented by the Quantum Manager
also performs the rewriting of HTTP requests destined to the Metadata server IP
address (169.254.169.254) to instead reach the IP address of Nova's meta-data
service.</para>
<para> Floating IPs should be configured using the standard Nova commands for floating IPs.
See: <link xlink:href="http://docs.openstack.org/diablo/openstack-compute/admin/content/associating-public-ip.html">Nova Administration Manual on Floating IPs</link>.</para>
</section>
<section xml:id="Existing-Net-dle454">
<title> Leveraging Existing Quantum Networks </title>
<para> It is also possible to use nova-manage to create a network that refers to an
existing Quantum network. The ''uuid'' flag passes an existing Quantum Network
UUID to nova-manage, meaning that Quantum Manager does not need to contact the
Quantum service to create a network. Instead the Quantum Manager will just
create a corresponding IPAM subnet, and then create and delete ports on the network
when VMs are created/deleted. For example: </para>
<literallayout class="monospaced">nova-manage network create --label=public --fixed_range_v4=8.8.8.0/24 --priority=0 --uuid=0a649eca-3764-417c-91a7-eb51291d4bb9 </literallayout>
</section>
<section xml:id="specifying-vm-network-connectivity-on-boot">
<title> Specifying VM Network Connectivity on Boot </title>
<para>Quantum Manager already supports more flexible vNIC-to-network associations
using the 'os-create-server-ext' extension. The Quantum Manager supports the
network association portion of this extension, but ignores any IP address data
in the request. </para>
<para>This extension can be invoked using the nova client utilities --nic option. A virtual
server will get a vNIC for each --nic is specified. For example, to connect to two networks
with UUIDs of 99b1d65e-34ae-4658-8387-ce97245ec4b4 and d6b7c997-d76d-4131-90a0-fc3408f921a4, use
a command like:</para>
<literallayout class="monospaced">nova boot --image ed8b2a37-5535-4a5f-a615-443513036d71 --flavor 1 --nic net-id=99b1d65e-34ae-4658-8387-ce97245ec4b4 --nic net-id=d6b7c997-d76d-4131-90a0-fc3408f921a4 test-vm1 </literallayout>
<para>The vNICs in the VM will appear in the order specified (e.g., eth0 is connected to the first network, eth1
connected to the second). A VM will only be connected to networks that are either global networks or
networks owned by that tenant. An API request to connect to any other network will fail with a
networkNotFound error.</para>
</section>
</section>
<section xml:id="IPAM-dle454">
<title> IP Address Management (IPAM) and DHCP</title>
<para>Nova is responsible for IP Address Management (IPAM), assigning each VM vNIC a
fixed IP address from a subnet associated with its L2 network. </para>
<para>By default, the Quantum Manager uses the existing IPAM database tables within Nova
for managing fixed-ip assignments for VMs. Using this default is recommended for
basic use.</para>
<section xml:id="enabling-nova-dhcp"><title>Enabling Nova DHCP</title><para>Quantum Manager can leverage the same dnsmasq DHCP mechanism supported by other Nova Network
Managers. DHCP is not enabled by default. It can be enabled system-wide with
the following configuration option:</para>
<literallayout class="monospaced">quantum_use_dhcp=True</literallayout>
</section>
<section xml:id="Melange-dle454">
<title>Using Melange IPAM</title>
<para>Quantum Manager also has experimental support for using the new standalone IPAM service from the <link
xlink:href="http://launchpad.net/melange"> Melange Project </link>. Melange
provides expert users with more flexibility in terms of managing how IP addresses
are assigned to VMs or other devices on the network. </para>
<para>Using Melange requires downloading the Melange code (it is a separate project from
both Quantum and Nova) and running the Melange service. To tell Nova to use Melange
IPAM instead of the default, set the following configuration option:</para>
<literallayout class="monospaced">quantum_ipam_lib=nova.network.quantum.melange_ipam_lib</literallayout>
<para>Nova defaults to connecting to Melange on localhost using the standard port. The
"melange_host" and "melange_port" options can override these defaults. </para>
<note> <para> Using Melange is incompatible with using Floating IPs. </para> </note>
<note><para>DHCP is not supported when Melange is used as the IPAM library.
</para></note>
<note><para>
In releases beyond Essex, Melange will be folded into the Quantum project, likely as part of a v2.0
Quantum API. Thus, using Melange as a stand-alone service will not be supported in future releases.
</para></note>
</section>
<section xml:id="Limits-dle455">
<title> Quantum Manager Limitations </title>
<itemizedlist spacing="compact">
<listitem>
<para>Multi-host nova-network HA is not supported (i.e., running nova-network on
each compute node for HA purposes). </para>
</listitem>
<listitem><para>CloudPipe VPNs do not work when using Quantum Manager.
Nova is developing an alternative to CloudPipe for Essex
that should be compatible with Quantum Manager.</para>
</listitem>
<listitem><para>Horizon cannot be used to create/delete networks, or view networks and ports. There was an
initial version of Quantum + Horizon integration, but this was not
compatible with the Quantum Manager in Essex, and was removed as a result.
Likewise, Horizon does not support specifying multiple vNIC on a virtual
server, or indicating what networks those vNICs should be attached to. </para>
<para> If networks where created using nova-manage, you may
use Horizon to create/destroy virtual servers, which will then be attached to all
"global" and project-specific networks, as described above.
</para>
<para>In Folsom Horizon will fully support Quantum.</para>
</listitem>
</itemizedlist>
</section>
</section>
</chapter>
<chapter xml:id="ch_quantum-keystone-authn-authz">
<title> Quantum Keystone Authentication and Authorization</title>
<para>Requests to the Quantum API can be authenticated with the OpenStack Keystone
identity service using a token-based authentication protocol. This is optional, and
is only needed for production deployments that expose the Quantum API directly to tenants.
Deployments where tenants only contact the Nova API, and Nova communicates with Quantum
using the Quantum Manager (see above), do not require Quantum to use Keystone.</para>
<para>Keystone integration is disabled by default, as Quantum does not yet provide
authorization, meaning that NOTHING IS DONE with existing Keystone identities by
Quantum, so for the time being this portion of the document is purely experimental.</para>
<section xml:id="configuring-keystone-with-quantum">
<title>Configuring Keystone with Quantum</title>
<para>There are three steps to configuring Keystone with Quantum:</para>
<para>1.Running the Keystone Service</para>
<para>The Keystone identity service is a requirement. It must be installed, although
not necessarily on the same machine where Quantum is running; both Keystone's admin
API and service API should be running. </para>
<para>2.Enabling Authentication and Authorization within Quantum</para>
<para>Authentication and Authorization middleware should be enabled in the Quantum
pipeline. To this aim, uncomment the following line in quantum.conf: </para>
<literallayout class="monospaced">pipeline = authtoken extensions quantumapiapp_v1_0</literallayout>
<para>3. Configuring Quantum to Connect to Keystone</para>
<para>The final step concerns configuring access to Keystone. The correct values of the following attributes
must be specified in the [filter:authtoken] section of quantum.conf: </para>
<literallayout class="monospaced">paste.filter_factory = keystone.middleware.auth_token:filter_factory
auth_host = 127.0.0.1
auth_port = 35357
auth_protocol = http
auth_uri = http://127.0.0.1:5000/
</literallayout>
<para>4. Setup Keystone Admin Credentials</para>
<para>In order to validate authentication tokens, Quantum uses Keystone's administrative
API. It therefore requires credentials for an administrative user, which can be
specified in Quantum's configuration file (quantum.conf) Either username and
password, or an authentication token for an administrative user can be specified in
the configuration file: </para>
<itemizedlist spacing="compact"><listitem><para>admin_token: Keystone token for administrative access</para></listitem>
<listitem><para>admin_user: Keystone user with administrative rights</para></listitem>
<listitem><para>admin_password: Password for the user specified with admin_user</para></listitem>
<listitem><para>admin_tenant_name: Tenant for admin_user</para></listitem> </itemizedlist>
<para>For example, using password:</para>
<literallayout class="monospaced">admin_tenant_name = service
admin_user = nova
admin_password = sp </literallayout>
<para>Or using a token:</para>
<literallayout class="monospaced">admin_token = 9a82c95a-99e9-4c3a-b5ee-199f6ba7ff04</literallayout>
<note><para>admin_token and admin_user/password are exclusive. If both are specified,
admin_token has priority.</para></note>
</section>
<section xml:id="client-auth-requirements">
<title>Client Authentication Requirements</title>
<para>A user should first authenticate with Keystone, supplying user credentials; the
Keystone service will return an authentication token, together with information
concerning token expirations and endpoint where that token can be used. </para>
<para> The authentication token must be included in every request for the Quantum API,
in the 'X_AUTH_TOKEN' header. Quantum will look for the authentication token in this
header, and validate it with the Keystone service. </para>
</section>
</chapter>
</book>

18
doc/src/docbkx/openstack-object-storage-admin/bk-objectstorage-adminguide.xml
View File

@ -5,8 +5,8 @@
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:html="http://www.w3.org/1999/xhtml"
version="5.0"
xml:id="openstack-object-storage-admin-manual">
<?rax pdf.url="../os-objectstorage-adminguide-trunk.pdf"?>
xml:id="openstack-object-storage-admin-manual-folsom">
<?rax pdf.url="../os-objectstorage-adminguide-folsom.pdf"?>
<title>OpenStack Object Storage Administration Manual</title>
<info>
<author>
@ -24,9 +24,9 @@
<year>2012</year>
<holder>OpenStack LLC</holder>
</copyright>
<releaseinfo>trunk</releaseinfo>
<releaseinfo>Folsom, 1.4.8</releaseinfo>
<productname>OpenStack Object Storage</productname>
<pubdate>2012-08-21</pubdate>
<pubdate>2012-11-09</pubdate>
<legalnotice role="apache2">
<annotation>
<remark>Copyright details are filled in by the template.</remark>
@ -38,6 +38,16 @@
managing, and understanding the software that runs OpenStack Object Storage. </para>
</abstract>
<revhistory>
<revision>
<date>2012-11-09</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Folsom release of this document.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2012-08-21</date>
<revdescription>

37
www/folsom/index.html
View File

@ -80,7 +80,7 @@
<div class="container">
<div class="span-12">
<h3 class="subhead"><a href="http://docs.openstack.org/">Documentation</a> > Install </h3>
<h3 class="subhead"><a href="http://docs.openstack.org/">Documentation</a> </h3>
</div>
<div class="searchArea span-10 last">
<div id="cse" style="width: 100%;">
@ -118,12 +118,37 @@
</script>
</div>
</div>
<div class="container">
<div class="span-12">
<p>Coming soon - when packages are stable enough to install from and we feel the list of doc bugs
is manageable, this page will be populated with links to released Folsom documentation.
</p>
<h2><a href="http://openstack.org/software/start/">Getting Started</a>
</h2>
<p>Get up and running quickly with <a href="http://devstack.org">DevStack</a>, <a href="http://trystack.org">TryStack</a>, or all-in-one installation guides.
</p>
<h2><a href="/install/">Installing OpenStack</a>
</h2>
<p>Installation and deployment guides for production-sized systems.
</p>
<h2><a href="/run/">Running OpenStack</a>
</h2>
<p>Operational and administration documentation for OpenStack cloud service providers.
</p>
<h2><a href="/developer/">Developing OpenStack</a>
</h2>
<p>Python developer documentation, continuous integration documentation, and language bindings documentation for OpenStack projects.
</p>
</div>
<div class="span-12 last">
<h2><a href="/cli/quick-start/content/index.html">Command Line Interfaces (CLI)</a>
</h2>
<p>The CLI documentation for nova, swift, glance, quantum, and keystone.
</p>
<h2><a href="/api/">API</a>
</h2>
<p>Documentation on the RESTful APIs provided by OpenStack services.
</p>
<h2><a href="/glossary/content/glossary.html">Glossary</a>
</h2>
<p>A list of terms and their definitions.</p>
</div>
</div>
<div class="container">
<div id="footer">

8
www/index.html
View File

@ -125,12 +125,12 @@
<div class="dropDown">
<div>
<li class="link"><a href="/trunk/" title="Go to the &quot;Current release&quot; page">Current (Folsom)</a></li>
<li class="link"><a href="/trunk/" title="Go to the &quot;Current release&quot; page">Current (master branch)</a></li>
<li class="link"><a href="/folsom/" title="Go to the &quot;Current release&quot; page">Folsom</a></li>
<li class="link"><a href="/essex/" title="Go to the &quot;Essex&quot; page">Essex</a></li>
<li class="link"><a href="/diablo/" title="Go to the &quot;Diablo&quot; page">Diablo</a></li>
<li class="link"><a href="/incubation/" title="Go to the &quot;Incubation&quot; page">Incubation</a></li>
</div>

41
www/install/index.html
View File

@ -120,36 +120,25 @@
</div>
<div class="container">
<div class="span-12">
<h2><a href="http://docs.openstack.org/essex/openstack-compute/install/apt/content/">Install and Deploy Guide for Ubuntu 12.04 (Essex)
</a>
</h2>
<p>Contains walkthrough installation with production considerations for Compute, Image, Volumes, Object Storage and Identity services plus Dashboard.
</p>
<h2><a href="http://docs.openstack.org/essex/openstack-compute/install/yum/content/">Install and Deploy Guide for Red Hat Enterprise Linux, CentOS 6.x, or Fedora 17 (Essex)</a>
</h2>
<p>Walks through an installation using packages available through Fedora 17 as well as on RHEL and derivatives through the EPEL repository.
<h2><a href="http://docs.openstack.org/trunk/openstack-compute/install/apt/content/">Install and Deploy Guide for Ubuntu 12.04 (Folsom)
</a>
</h2>
<p>Contains walkthrough installation with production considerations for Compute, Image, Volumes, Object Storage and Identity services plus Dashboard.
</p>
<h2><a href="http://docs.openstack.org/trunk/openstack-compute/install/yum/content/">Install and Deploy Guide for Red Hat Enterprise Linux, CentOS 6.x, or Fedora 17 (Folsom)</a>
</h2>
<p>Walks through an installation using packages available through Fedora 17 as well as on RHEL and derivatives through the EPEL repository.
</p>
<h2><a href="http://docs.openstack.org/trunk/openstack-network/admin/content/ch_install.html">Quantum Installation</a>
</h2>
<p>Installation instructions for OpenStack Networking from Ubuntu or Fedora packages.
</p>
<p>The corresponding project names are nova, cinder, glance, swift, and keystone.
</p>
</div>
<div class="span-12 last">
<h2><a href="http://docs.openstack.org/trunk/openstack-compute/install/apt/content/">Install and Deploy Guide for Ubuntu 12.04 (Folsom)
</a>
</h2>
<p>Contains walkthrough installation with production considerations for Compute, Image, Volumes, Object Storage and Identity services plus Dashboard.
</p>
<h2><a href="http://docs.openstack.org/trunk/openstack-compute/install/yum/content/">Install and Deploy Guide for Red Hat Enterprise Linux, CentOS 6.x, or Fedora 17 (Folsom)</a>
</h2>
<p>Walks through an installation using packages available through Fedora 17 as well as on RHEL and derivatives through the EPEL repository.
</p>
<h2><a href="http://docs.openstack.org/trunk/openstack-network/admin/content/ch_install.html">Quantum Installation</a>
</h2>
<p>Installation instructions for OpenStack Networking from Ubuntu or Fedora packages.
</p>
</div>
<div class="container">
<div id="footer">