openstack
/
openstack-manuals
Code Issues Proposed changes
openstack-manuals/doc/src/docbkx/openstack-compute-admin/computeinstall.xml

1755 lines
70 KiB
XML
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.0" xml:id="ch_installing-openstack-compute"
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/2000/svg"
xmlns:ns4="http://www.w3.org/1998/Math/MathML"
xmlns:ns3="http://www.w3.org/1999/xhtml"
xmlns:ns="http://docbook.org/ns/docbook">
<title>Installing OpenStack Compute</title>
<para>The OpenStack system has several key projects that are separate
installations but can work together depending on your cloud needs: OpenStack
Compute, OpenStack Object Storage, and OpenStack Image Service. You can
install any of these projects separately and then configure them either as
standalone or connected entities. </para>
<xi:include href="../openstack-install/compute-sys-requirements.xml"/>
<section xml:id="example-installation-architecture">
<title>Example Installation Architectures</title>
<para>OpenStack Compute uses a shared-nothing, messaging-based
architecture. While very flexible, the fact that you can install each
nova- service on an independent server means there are many possible
methods for installing OpenStack Compute. Here are the types of
installation architectures:</para>
<itemizedlist>
<listitem>
<para>Single node: Only one server runs all nova- services and also
drives all the virtual instances. Use this configuration only for
trying out OpenStack Compute, or for development purposes.</para>
</listitem>
<listitem>
<para>Two nodes: A cloud controller node runs the nova- services
except for <command>nova-compute</command>, and a compute node runs
<command>nova-compute</command>. A client computer is likely needed to
bundle images and interfacing to the servers, but a client is not
required. Use this configuration for proof of concepts or development
environments.</para>
</listitem>
<listitem>
<para>Multiple nodes: You can add more compute nodes to the two node
installation by simply installing <command>nova-compute</command> on
an additional server and copying a <filename>nova.conf</filename> file
to the added node. This would result in a multiple node installation.
You can also add a volume controller and a network controller as
additional nodes in a more complex multiple node installation. A
minimum of 4 nodes is best for running multiple virtual instances that
require a lot of processing power.</para>
</listitem>
</itemizedlist>
<para>This is an illustration of one possible multiple server installation
of OpenStack Compute; virtual server networking in the cluster may
vary.</para>
<para><inlinemediaobject>
<imageobject>
<imagedata fileref="figures/NOVA_install_arch.png" scale="80"/>
</imageobject>
</inlinemediaobject></para>
<para>An alternative architecture would be to add more messaging servers
if you notice a lot of back up in the messaging queue causing performance
problems. In that case you would add an additional RabbitMQ server in
addition to or instead of scaling up the database server. Your
installation can run any nova- service on any server as long as the
<filename>nova.conf</filename> is configured to point to the RabbitMQ
server and the server can send messages to the server.</para>
<para>Multiple installation architectures are possible, here is another
example illustration.</para>
<para><inlinemediaobject>
<imageobject>
<imagedata fileref="figures/NOVA_compute_nodes.png" scale="40"/>
</imageobject>
</inlinemediaobject></para>
</section>
<section xml:id="service-architecture">
<title>Service Architecture</title>
<para>Because Compute has multiple services and many configurations are
possible, here is a diagram showing the overall service architecture and
communication systems between the services.</para>
<para><inlinemediaobject>
<imageobject>
<imagedata fileref="figures/NOVA_ARCH.png" scale="80"/>
</imageobject>
</inlinemediaobject></para>
</section>
<section xml:id="installing-openstack-compute-on-ubuntu">
<title>Installing on Ubuntu</title>
<para>How you go about installing OpenStack Compute depends on your goals
for the installation. You can use an ISO image, you can use a scripted
installation, and you can manually install with a step-by-step
installation.</para>
<section xml:id="iso-ubuntu-installation">
<title>ISO Distribution Installation</title>
<para>You can download and use an ISO image that is based on a Ubuntu
Linux Server 10.04 LTS distribution containing only the components
needed to run OpenStack Compute. See <link
xlink:href="http://sourceforge.net/projects/stackops/files/">http://sourceforge.net/projects/stackops/files/</link>
for download files and information, license information, and a
<filename>README</filename> file. For documentation on the StackOps
distro, see <link
xlink:href="http://docs.stackops.org">http://docs.stackops.org</link>.
For free support, go to <link
xlink:href="http://getsatisfaction.com/stackops">http://getsatisfaction.com/stackops</link>.</para>
</section>
<section xml:id="scripted-ubuntu-installation">
<title>Scripted Installation</title>
<para>You can download a script for a standalone install for
proof-of-concept, learning, or for development purposes for Ubuntu 11.04
at <link
xlink:href="http://devstack.org">https://devstack.org</link>.</para>
<orderedlist>
<listitem>
<para>Install Ubuntu 11.04 (Natty):</para>
<para>In order to correctly install all the dependencies, we assume
a specific version of Ubuntu to make it as easy as possible.
OpenStack works on other flavors of Linux (and some folks even run
it on Windows!) We recommend using a minimal install of Ubuntu
server in a VM if this is your first time.</para>
</listitem>
<listitem>
<para>Download DevStack:</para>
<screen><prompt>$</prompt> <userinput>git clone git://github.com/openstack-dev/devstack.git</userinput></screen>
<para>The devstack repo contains a script that installs OpenStack
Compute, the Image Service and the Identity Service and offers
templates for configuration files plus data scripts.</para>
</listitem>
<listitem>
<para>Start the install:</para>
<screen><prompt>$</prompt> <userinput>cd devstack; ./stack.sh</userinput></screen>
<para>It takes a few minutes, we recommend <link
xlink:href="http://devstack.org/stack.sh.html">reading the
well-documented script</link> while it is building to learn more
about what is going on.</para>
</listitem>
</orderedlist>
</section>
<section xml:id="manual-ubuntu-installation">
<title>Manual Installation on Ubuntu</title>
<para>The manual installation involves installing from packages on
Ubuntu 11.10 or 11.04 as a user with root (or sudo) permission. The
<link
xlink:href="http://docs.openstack.org/diablo/openstack-compute/starter/content/">OpenStack
Starter Guide</link> provides instructions for a manual installation
using the packages shipped with Ubuntu 11.10. The <link
xlink:href="http://docs.openstack.org/diablo/openstack-compute/install/content/">OpenStack
Install and Deploy Manual</link> provides instructions for installing
using packages provided by OpenStack community members. Refer to those
manuals for detailed instructions by going to <link
xlink:href="http://docs.openstack.org">http://docs.openstack.org</link>
and clicking the links next to the manual title.</para>
</section>
</section>
<section xml:id="installing-openstack-compute-on-rhel6">
<title>Installing on Fedora or Red Hat Enterprise Linux 6</title>
<para>The Fedora project provides OpenStack packages in Fedora 16 and
later. Fedora also provides packages for RHEL6 via the EPEL (Extra
Packages for Enterprise Linux) 6 repository. If you would like to install
OpenStack on RHEL6, see this page for more information on enabling the use
of EPEL: <link
xlink:href="http://fedoraproject.org/wiki/EPEL">http://fedoraproject.org/wiki/EPEL</link>.</para>
<para>Detailed instructions for installing OpenStack Compute on Fedora or
RHEL6 can be found on the Fedora wiki. See these pages for more
information:</para>
<variablelist>
<varlistentry>
<term><link
xlink:href="https://fedoraproject.org/wiki/Getting_started_with_OpenStack_on_Fedora_17">Getting
Started with OpenStack on Fedora 17</link></term>
<listitem>
<para>The Essex release is in Fedora 17. This page discusses the
installation of Essex on Fedora 17. Once EPEL 6 has been updated to
include Essex, these instructions should be used if installing on
RHEL 6. The main difference between the Fedora 17 instructions and
what must be done on RHEL 6 is that RHEL 6 does not use systemd, so
the <command>systemctl</command> commands will have to substituted
with the RHEL 6 equivalent.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link
xlink:href="https://fedoraproject.org/wiki/Getting_started_with_OpenStack_Nova">Getting
Started with OpenStack Nova</link></term>
<listitem>
<para>This page was originally written as instructions for getting
started with OpenStack on Fedora 16, which includes the Diablo
release. At the time of writing, While EPEL 6 still includes Diablo,
these instructions should be used if installing on RHEL 6.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="configuring-openstack-compute-basics">
<title>Post-Installation Configuration for OpenStack Compute</title>
<para>Configuring your Compute installation involves
<command>nova-manage</command> commands plus editing the
<filename>nova.conf</filename> file to ensure the correct flags are set.
This section contains the basics for a simple multi-node installation, but
Compute can be configured many ways. You can find networking options and
hypervisor options described in separate chapters, and you will read about
additional configuration information in a separate chapter as well.</para>
<section xml:id="setting-flags-in-nova-conf-file">
<title>Setting Flags in the <filename>nova.conf</filename> File</title>
<para>The configuration file <filename>nova.conf</filename> is installed
in <filename>/etc/nova</filename> by default. You only need to do these
steps when installing manually. The scripted installation above does
this configuration during the installation. A default set of options are
already configured in <filename>nova.conf</filename> when you install
manually. The defaults are as follows:</para>
<programlisting>
--daemonize=1
--dhcpbridge_flagfile=/etc/nova/nova.conf
--dhcpbridge=/bin/nova-dhcpbridge
--logdir=/var/log/nova
--state_path=/var/lib/nova
</programlisting>
<para>Starting with the default file, you must define the following
required items in <filename>/etc/nova/nova.conf</filename>. The flag
variables are described below. You can place comments in the
<filename>nova.conf</filename> file by entering a new line with a
<literal>#</literal> sign at the beginning of the line. To see a listing
of all possible flag settings, see the output of running
<command>/bin/nova-api --help</command>.</para>
<table rules="all">
<caption>Description of <filename>nova.conf</filename> flags (not
comprehensive)</caption>
<thead>
<tr>
<td>Flag</td>
<td>Description</td>
</tr>
</thead>
<tbody>
<tr>
<td><literal>--sql_connection</literal></td>
<td>SQL Alchemy connect string (reference); Location of OpenStack
Compute SQL database</td>
</tr>
<tr>
<td><literal>--s3_host</literal></td>
<td>IP address; Location where OpenStack Compute is hosting the
objectstore service, which will contain the virtual machine images
and buckets</td>
</tr>
<tr>
<td><literal>--rabbit_host</literal></td>
<td>IP address; Location of RabbitMQ server</td>
</tr>
<tr>
<td><literal>--verbose</literal></td>
<td>Set to <literal>1</literal> to turn on; Optional but helpful
during initial setup</td>
</tr>
<tr>
<td><literal>--network_manager</literal></td>
<td><para>Configures how your controller will communicate with
additional OpenStack Compute nodes and virtual machines.
Options:</para><itemizedlist>
<listitem>
<para>
<literal>nova.network.manager.FlatManager</literal>
</para>
<para>Simple, non-VLAN networking</para>
</listitem>
<listitem>
<para>
<literal>nova.network.manager.FlatDHCPManager</literal>
</para>
<para>Flat networking with DHCP</para>
</listitem>
<listitem>
<para>
<literal>nova.network.manager.VlanManager</literal>
</para>
<para>VLAN networking with DHCP; This is the Default if no
network manager is defined here in nova.conf.</para>
</listitem>
</itemizedlist></td>
</tr>
<tr>
<td><literal>--fixed_range</literal></td>
<td>IP address/range; Network prefix for the IP network that all
the projects for future VM guests reside on. Example:
<literal>192.168.0.0/12</literal></td>
</tr>
<tr>
<td><literal>--ec2_host</literal></td>
<td>IP address; Indicates where the <command>nova-api</command>
service is installed.</td>
</tr>
<tr>
<td><literal>--ec2_url</literal></td>
<td>Url; Indicates the service for EC2 requests.</td>
</tr>
<tr>
<td><literal>--osapi_host</literal></td>
<td>IP address; Indicates where the <command>nova-api</command>
service is installed.</td>
</tr>
<tr>
<td><literal>--network_size</literal></td>
<td>Number value; Number of addresses in each private subnet.</td>
</tr>
<tr>
<td><literal>--glance_api_servers</literal></td>
<td>IP and port; Address for Image Service.</td>
</tr>
<tr>
<td><literal>--use_deprecated_auth</literal></td>
<td>If this flag is present, the Cactus method of authentication
is used with the novarc file containing credentials.</td>
</tr>
</tbody>
</table>
<para>Here is a simple example <filename>nova.conf</filename> file for a
small private cloud, with all the cloud controller services, database
server, and messaging server on the same server.</para>
<programlisting>
--dhcpbridge_flagfile=/etc/nova/nova.conf
--dhcpbridge=/bin/nova-dhcpbridge
--logdir=/var/log/nova
--state_path=/var/lib/nova
--verbose
--use_deprecated_auth
--ec2_host=184.106.239.134
--ec2_url=http://184.106.239.134:8773/services/Cloud
--osapi_host=http://184.106.239.134
--s3_host=184.106.239.134
--rabbit_host=184.106.239.134
--fixed_range=192.168.0.0/16
--network_size=8
--glance_api_servers=184.106.239.134:9292
--routing_source_ip=184.106.239.134
--sql_connection=mysql://nova:notnova@184.106.239.134/nova
</programlisting>
<para>Create a “nova” group, so you can set permissions on the
configuration file:</para>
<screen><prompt>$</prompt> <userinput>sudo addgroup nova</userinput></screen>
<para>The <filename>nova.config</filename> file should have its owner
set to <literal>root:nova</literal>, and mode set to
<literal>0640</literal>, since the file contains your MySQL server’s
username and password. You also want to ensure that the
<literal>nova</literal> user belongs to the <literal>nova</literal>
group.</para>
<screen><prompt>$</prompt> <userinput>sudo usermod -g nova nova</userinput>
<prompt>$</prompt> <userinput>chown -R root:nova /etc/nova</userinput>
<prompt>$</prompt> <userinput>chmod 640 /etc/nova/nova.conf</userinput>
</screen>
</section>
<section xml:id="setting-up-openstack-compute-environment-on-the-compute-node">
<title>Setting Up OpenStack Compute Environment on the Compute
Node</title>
<para>These are the commands you run to ensure the database schema is
current, and then set up a user and project, if you are using built-in
auth with the <literal>--use_deprecated_auth</literal> flag rather than
the Identity Service:</para>
<screen><prompt>$</prompt> <userinput>nova-manage db sync</userinput>
<prompt>$</prompt> <userinput>nova-manage user admin <replaceable>&lt;user_name&gt;</replaceable></userinput>
<prompt>$</prompt> <userinput>nova-manage project create <replaceable>&lt;project_name&gt; &lt;user_name&gt;</replaceable></userinput>
<prompt>$</prompt> <userinput>nova-manage network create <replaceable>&lt;network-label&gt; &lt;project-network&gt; &lt;number-of-networks-in-project&gt; &lt;addresses-in-each-network&gt;</replaceable></userinput>
</screen>
<para>Here is an example of what this looks like with real values
entered:</para>
<screen><prompt>$</prompt> <userinput>nova-manage db sync</userinput>
<prompt>$</prompt> <userinput>nova-manage user admin dub</userinput>
<prompt>$</prompt> <userinput>nova-manage project create dubproject dub</userinput>
<prompt>$</prompt> <userinput>nova-manage network create novanet 192.168.0.0/24 1 256</userinput></screen>
<para>For this example, the number of IPs is <literal>/24</literal>
since that falls inside the <literal>/16</literal> range that was set in
<literal>fixed-range</literal> in <filename>nova.conf</filename>.
Currently, there can only be one network, and this set up would use the
max IPs available in a <literal>/24</literal>. You can choose values
that let you use any valid amount that you would like.</para>
<para>The nova-manage service assumes that the first IP address is your
network (like 192.168.0.0), that the 2nd IP is your gateway
(192.168.0.1), and that the broadcast is the very last IP in the range
you defined (192.168.0.255). If this is not the case you will need to
manually edit the sql db <literal>networks</literal> table.</para>
<para>When you run the <command>nova-manage network create</command>
command, entries are made in the <literal>networks</literal> and
<literal>fixed_ips</literal> tables. However, one of the networks listed
in the <literal>networks</literal> table needs to be marked as bridge in
order for the code to know that a bridge exists. The network in the Nova
networks table is marked as bridged automatically for Flat
Manager.</para>
</section>
<section xml:id="creating-certifications">
<title>Creating Credentials</title>
<para>Generate the credentials as a zip file. These are the certs you
will use to launch instances, bundle images, and all the other assorted
API functions.</para>
<screen><prompt>#</prompt> <userinput>mkdir –p /root/creds</userinput>
<prompt>#</prompt> <userinput>nova-manage project zipfile <replaceable>$NOVA_PROJECT $NOVA_PROJECT_USER</replaceable> /root/creds/novacreds.zip</userinput></screen>
<para>If you are using one of the Flat modes for networking, you may see
a Warning message "<literal>No vpn data for project
<replaceable>&lt;project_name&gt;</replaceable></literal>" which you can
safely ignore.</para>
<para>Unzip them in your home directory, and add them to your
environment.</para>
<screen><prompt>#</prompt> <userinput>unzip /root/creds/novacreds.zip -d /root/creds/</userinput>
<prompt>#</prompt> <userinput>cat /root/creds/novarc &gt;&gt; ~/.bashrc</userinput>
<prompt>#</prompt> <userinput>source ~/.bashrc</userinput></screen>
<para>If you already have Nova credentials present in your environment,
you can use a script included with Glance the Image Service,
<filename>tools/nova_to_os_env.sh</filename>, to create Glance-style
credentials. This script adds <literal>OS_AUTH</literal> credentials to
the environment which are used by the Image Service to enable private
images when the Identity Service is configured as the authentication
system for Compute and the Image Service.</para>
</section>
<section xml:id="enabling-access-to-vms-on-the-compute-node">
<title>Enabling Access to VMs on the Compute Node</title>
<para>One of the most commonly missed configuration areas is not
allowing the proper access to VMs. Use the
<command>euca-authorize</command> command to enable access. Below, you
will find the commands to allow <command>ping</command> and
<command>ssh</command> to your VMs :</para>
<note>
<para>These commands need to be run as root only if the credentials
used to interact with <command>nova-api</command> have been put under
<filename>/root/.bashrc</filename>. If the EC2 credentials have been
put into another user's <filename>.bashrc</filename> file, then, it is
necessary to run these commands as the user.</para>
</note>
<screen><prompt>$</prompt> <userinput>nova  secgroup-add-rule default icmp - 1 -1 0.0.0.0/0</userinput>
<prompt>$</prompt> <userinput>nova  secgroup-add-rule default tcp 22 22 0.0.0.0/0</userinput></screen>
<para>Another common issue is you cannot ping or SSH to your instances
after issuing the <command>euca-authorize</command> commands. Something
to look at is the amount of <command>dnsmasq</command> processes that
are running. If you have a running instance, check to see that TWO
<command>dnsmasq</command> processes are running. If not, perform the
following:</para>
<screen><prompt>$</prompt> <userinput>sudo killall dnsmasq</userinput>
<prompt>$</prompt> <userinput>sudo service nova-network restart</userinput></screen>
<para>If you get the <literal>instance not found</literal> message while
performing the restart, that means the service was not previously
running. You simply need to start it instead of restarting it : </para>
<screen><prompt>$</prompt> <userinput>sudo service nova-network start</userinput></screen>
</section>
<section xml:id="configuring-multiple-compute-nodes">
<title>Configuring Multiple Compute Nodes</title>
<para>If your goal is to split your VM load across more than one server,
you can connect an additional <command>nova-compute</command> node to a
cloud controller node. This configuring can be reproduced on multiple
compute servers to start building a true multi-node OpenStack Compute
cluster.</para>
<para>To build out and scale the Compute platform, you spread out
services amongst many servers. While there are additional ways to
accomplish the build-out, this section describes adding compute nodes,
and the service we are scaling out is called
<command>nova-compute</command>.</para>
<para>For a multi-node install you only make changes to
<filename>nova.conf</filename> and copy it to additional compute nodes.
Ensure each <filename>nova.conf</filename> file points to the correct IP
addresses for the respective services. Customize the
<filename>nova.conf</filename> example below to match your environment.
The <literal><replaceable>CC_ADDR</replaceable></literal> is the Cloud
Controller IP Address.</para>
<programlisting>--dhcpbridge_flagfile=/etc/nova/nova.conf
--dhcpbridge=/usr/bin/nova-dhcpbridge
--flat_network_bridge=br100
--logdir=/var/log/nova
--state_path=/var/lib/nova
--verbose
--sql_connection=mysql://root:nova@<replaceable>CC_ADDR</replaceable>/nova
--s3_host=<replaceable>CC_ADDR</replaceable>
--rabbit_host=<replaceable>CC_ADDR</replaceable>
--ec2_api=<replaceable>CC_ADDR</replaceable>
--ec2_url=http://CC_ADDR:8773/services/Cloud
--network_manager=nova.network.manager.FlatManager
--fixed_range= network/CIDR
--network_size=number of addresses</programlisting>
<para>By default, Nova sets the bridge device based on the setting in
<literal>--flat_network_bridge</literal>. Now you can edit
<filename>/etc/network/interfaces</filename> with the following
template, updated with your IP information.</para>
<programlisting># The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto br100
iface br100 inet static
bridge_ports eth0
bridge_stp off
bridge_maxwait 0
bridge_fd 0
address <replaceable>xxx.xxx.xxx.xxx</replaceable>
netmask <replaceable>xxx.xxx.xxx.xxx</replaceable>
network <replaceable>xxx.xxx.xxx.xxx</replaceable>
broadcast <replaceable>xxx.xxx.xxx.xxx</replaceable>
gateway <replaceable>xxx.xxx.xxx.xxx</replaceable>
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers <replaceable>xxx.xxx.xxx.xxx</replaceable>
</programlisting>
<para>Restart networking:</para>
<screen><prompt>$</prompt> <userinput>sudo service networking restart</userinput></screen>
<para>With <filename>nova.conf</filename> updated and networking set,
configuration is nearly complete. First, bounce the relevant services to
take the latest updates:</para>
<screen><prompt>$</prompt> <userinput>sudo service libvirtd restart</userinput>
$ <userinput>sudo service nova-compute restart</userinput></screen>
<para>To avoid issues with KVM and permissions with Nova, run the
following commands to ensure we have VM's that are running
optimally:</para>
<screen><prompt>#</prompt> <userinput>chgrp kvm /dev/kvm</userinput>
<prompt>#</prompt> <userinput>chmod g+rwx /dev/kvm</userinput></screen>
<para>If you want to use the 10.04 Ubuntu Enterprise Cloud images that
are readily available at
http://uec-images.ubuntu.com/releases/10.04/release/, you may run into
delays with booting. Any server that does not have
<command>nova-api</command> running on it needs this iptables entry so
that UEC images can get metadata info. On compute nodes, configure the
iptables with this next step:</para>
<screen><prompt>#</prompt> <userinput>iptables -t nat -A PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination <replaceable>$NOVA_API_IP</replaceable>:8773</userinput></screen>
<para>Lastly, confirm that your compute node is talking to your cloud
controller. From the cloud controller, run this database query:</para>
<screen><prompt>$</prompt> <userinput>mysql -u<replaceable>$MYSQL_USER</replaceable> -p<replaceable>$MYSQL_PASS</replaceable> nova -e 'select * from services;'</userinput></screen>
<para>In return, you should see something similar to this:</para>
<screen><computeroutput>+---------------------+---------------------+------------+---------+----+----------+----------------+-----------+--------------+----------+-------------------+
| created_at | updated_at | deleted_at | deleted | id | host | binary | topic | report_count | disabled | availability_zone |
+---------------------+---------------------+------------+---------+----+----------+----------------+-----------+--------------+----------+-------------------+
| 2011-01-28 22:52:46 | 2011-02-03 06:55:48 | NULL | 0 | 1 | osdemo02 | nova-network | network | 46064 | 0 | nova |
| 2011-01-28 22:52:48 | 2011-02-03 06:55:57 | NULL | 0 | 2 | osdemo02 | nova-compute | compute | 46056 | 0 | nova |
| 2011-01-28 22:52:52 | 2011-02-03 06:55:50 | NULL | 0 | 3 | osdemo02 | nova-scheduler | scheduler | 46065 | 0 | nova |
| 2011-01-29 23:49:29 | 2011-02-03 06:54:26 | NULL | 0 | 4 | osdemo01 | nova-compute | compute | 37050 | 0 | nova |
| 2011-01-30 23:42:24 | 2011-02-03 06:55:44 | NULL | 0 | 9 | osdemo04 | nova-compute | compute | 28484 | 0 | nova |
| 2011-01-30 21:27:28 | 2011-02-03 06:54:23 | NULL | 0 | 8 | osdemo05 | nova-compute | compute | 29284 | 0 | nova |
+---------------------+---------------------+------------+---------+----+----------+----------------+-----------+--------------+----------+-------------------+</computeroutput> </screen>
<para>You can see that <literal>osdemo0{1,2,4,5}</literal> are all
running <command>nova-compute</command>. When you start spinning up
instances, they will allocate on any node that is running
<command>nova-compute</command> from this list.</para>
</section>
<section xml:id="determining-version-of-compute">
<title>Determining the Version of Compute</title>
<para>You can find the version of the installation by using the
<command>nova-manage</command> command:</para>
<screen><prompt>$</prompt> <userinput>nova-manage version list</userinput></screen>
</section>
<section xml:id="migrating-from-cactus-to-diablo">
<title>Migrating from Cactus to Diablo</title>
<para>If you have an installation already installed and running, is is
possible to run smoothly an uprade from Cactus Stable (2011.2) to Diablo
Stable (2011.3), without losing any of your running instances, but also
keep the current network, volumes, and images available.</para>
<para>In order to update, we will start by updating the Image
Service(<emphasis role="bold">Glance</emphasis>), then update the
Compute Service (<emphasis role="bold">Nova</emphasis>). We will finally
make sure the client-tools (euca2ools and novaclient) are properly
integrated.</para>
<para>For Nova, Glance and euca2ools, we will use the PPA repositories,
while we will use the latest version of novaclient from Github, due to
important updates.</para>
<note>
<para>That upgrade guide does not integrate Keystone. If you want to
integrate Keystone, please read the section "Installing the Identity
Service"</para>
</note>
<para/>
<simplesect>
<title>A- Glance upgrade</title>
<para>In order to update Glance, we will start by stopping all running
services : <literallayout class="monospaced">glance-control all stop</literallayout>Make
sure the services are stopped, you can check by running ps :
<literallayout class="monospaced">ps axl |grep glance</literallayout>If
the commands doesn't output any Glance process, it means you can
continue ; otherwise, simply kill the PID's.</para>
<para>While the Cactus release of Glance uses one glance.conf file
(usually located at "/etc/glance/glance.conf"), the Diablo release
brings up new configuration files. (Look into them, they are pretty
self-explanatory).</para>
<orderedlist>
<listitem>
<para><emphasis role="bold">Update the
repositories</emphasis></para>
<para>The first thing to do is to update the packages. Update your
"/etc/apt/sources.list", or create a
"/etc/apt/sources.list.d/openstack_diablo.list file :
<programlisting>
deb http://ppa.launchpad.net/openstack-release/2011.<emphasis role="bold">3</emphasis>/ubuntu maverick main
deb-src http://ppa.launchpad.net/openstack-release/2011.<emphasis role="bold">3</emphasis>/ubuntu maverick main
</programlisting>If you are running Ubuntu Lucid,
point to Lucid, otherwise to another version (Maverick, or Natty).
You can now update the repository : <literallayout
class="monospaced">aptitude update
aptitude upgrade</literallayout></para>
<para>You could encounter the message "<emphasis role="italic">The
following signatures couldn't be verified because the public key
is not available: NO_PUBKEY XXXXXXXXXXXX</emphasis>", simply run :
<programlisting>
gpg --keyserver pgpkeys.mit.edu --recv-key XXXXXXXXXXXX
gpg -a --export XXXXXXXXXXXX | sudo apt-key add -
(Where XXXXXXXXXXXX is the key)
</programlisting>Then re-run the two steps, which
should work proceed without error. The package system should
propose you to upgrade you Glance installation to the Diablo one,
accept the upgrade, and you will have successfully performed the
package upgrade. In the next step, we will reconfigure the
service.</para>
<para/>
</listitem>
<listitem>
<para><emphasis role="bold">Update Glance configuration
files</emphasis></para>
<para>You need now to update the configuration files. The main
file you will need to update is <literallayout class="monospaced">etc/glance/glance-registry.conf</literallayout>In
that one you will specify the database backend. If you used a
MySQL backend under Cactus ; replace the <literallayout
class="monospaced">sql_connection</literallayout> with the entry
you have into the /etc/glance/glance.conf.</para>
<para>Here is how the configuration files should look like
:</para>
<literallayout class="monospaced">glance-api.conf</literallayout>
<programlisting>
[DEFAULT]
# Show more verbose log output (sets INFO log level output)
verbose = True
# Show debugging output in logs (sets DEBUG log level output)
debug = False
# Which backend store should Glance use by default is not specified
# in a request to add a new image to Glance? Default: 'file'
# Available choices are 'file', 'swift', and 's3'
default_store = file
# Address to bind the API server
bind_host = 0.0.0.0
# Port the bind the API server to
bind_port = 9292
# Address to find the registry server
registry_host = 0.0.0.0
# Port the registry server is listening on
registry_port = 9191
# Log to this file. Make sure you do not set the same log
# file for both the API and registry servers!
log_file = /var/log/glance/api.log
# Send logs to syslog (/dev/log) instead of to file specified by `log_file`
use_syslog = False
# ============ Notification System Options =====================
# Notifications can be sent when images are create, updated or deleted.
# There are three methods of sending notifications, logging (via the
# log_file directive), rabbit (via a rabbitmq queue) or noop (no
# notifications sent, the default)
notifier_strategy = noop
# Configuration options if sending notifications via rabbitmq (these are
# the defaults)
rabbit_host = localhost
rabbit_port = 5672
rabbit_use_ssl = false
rabbit_userid = guest
rabbit_password = guest
rabbit_virtual_host = /
rabbit_notification_topic = glance_notifications
# ============ Filesystem Store Options ========================
# Directory that the Filesystem backend store
# writes image data to
filesystem_store_datadir = /var/lib/glance/images/
# ============ Swift Store Options =============================
# Address where the Swift authentication service lives
swift_store_auth_address = 127.0.0.1:8080/v1.0/
# User to authenticate against the Swift authentication service
swift_store_user = jdoe
# Auth key for the user authenticating against the
# Swift authentication service
swift_store_key = a86850deb2742ec3cb41518e26aa2d89
# Container within the account that the account should use
# for storing images in Swift
swift_store_container = glance
# Do we create the container if it does not exist?
swift_store_create_container_on_put = False
# What size, in MB, should Glance start chunking image files
# and do a large object manifest in Swift? By default, this is
# the maximum object size in Swift, which is 5GB
swift_store_large_object_size = 5120
# When doing a large object manifest, what size, in MB, should
# Glance write chunks to Swift? This amount of data is written
# to a temporary disk buffer during the process of chunking
# the image file, and the default is 200MB
swift_store_large_object_chunk_size = 200
# Whether to use ServiceNET to communicate with the Swift storage servers.
# (If you aren't RACKSPACE, leave this False!)
#
# To use ServiceNET for authentication, prefix hostname of
# `swift_store_auth_address` with 'snet-'.
# Ex. https://example.com/v1.0/ -&gt; https://snet-example.com/v1.0/
swift_enable_snet = False
# ============ S3 Store Options =============================
# Address where the S3 authentication service lives
s3_store_host = 127.0.0.1:8080/v1.0/
# User to authenticate against the S3 authentication service
s3_store_access_key = &lt;20-char AWS access key&gt;
# Auth key for the user authenticating against the
# S3 authentication service
s3_store_secret_key = &lt;40-char AWS secret key&gt;
# Container within the account that the account should use
# for storing images in S3. Note that S3 has a flat namespace,
# so you need a unique bucket name for your glance images. An
# easy way to do this is append your AWS access key to "glance".
# S3 buckets in AWS *must* be lowercased, so remember to lowercase
# your AWS access key if you use it in your bucket name below!
s3_store_bucket = &lt;lowercased 20-char aws access key&gt;glance
# Do we create the bucket if it does not exist?
s3_store_create_bucket_on_put = False
# ============ Image Cache Options ========================
image_cache_enabled = False
# Directory that the Image Cache writes data to
# Make sure this is also set in glance-pruner.conf
image_cache_datadir = /var/lib/glance/image-cache/
# Number of seconds after which we should consider an incomplete image to be
# stalled and eligible for reaping
image_cache_stall_timeout = 86400
# ============ Delayed Delete Options =============================
# Turn on/off delayed delete
delayed_delete = False
[pipeline:glance-api]
pipeline = versionnegotiation context apiv1app
# NOTE: use the following pipeline for keystone
# pipeline = versionnegotiation authtoken context apiv1app
# To enable Image Cache Management API replace pipeline with below:
# pipeline = versionnegotiation context imagecache apiv1app
# NOTE: use the following pipeline for keystone auth (with caching)
# pipeline = versionnegotiation authtoken context imagecache apiv1app
[pipeline:versions]
pipeline = versionsapp
[app:versionsapp]
paste.app_factory = glance.api.versions:app_factory
[app:apiv1app]
paste.app_factory = glance.api.v1:app_factory
[filter:versionnegotiation]
paste.filter_factory = glance.api.middleware.version_negotiation:filter_factory
[filter:imagecache]
paste.filter_factory = glance.api.middleware.image_cache:filter_factory
[filter:context]
paste.filter_factory = glance.common.context:filter_factory
[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
service_protocol = http
service_host = 127.0.0.1
service_port = 5000
auth_host = 127.0.0.1
auth_port = 5001
auth_protocol = http
auth_uri = http://127.0.0.1:5000/
admin_token = 999888777666
</programlisting>
<literallayout class="monospaced">glance-registry.conf</literallayout>
<programlisting>
[DEFAULT]
# Show more verbose log output (sets INFO log level output)
verbose = True
# Show debugging output in logs (sets DEBUG log level output)
debug = False
# Address to bind the registry server
bind_host = 0.0.0.0
# Port the bind the registry server to
bind_port = 9191
# Log to this file. Make sure you do not set the same log
# file for both the API and registry servers!
log_file = /var/log/glance/registry.log
# Send logs to syslog (/dev/log) instead of to file specified by `log_file`
use_syslog = False
# SQLAlchemy connection string for the reference implementation
# registry server. Any valid SQLAlchemy connection string is fine.
# See: http://www.sqlalchemy.org/docs/05/reference/sqlalchemy/connections.html#sqlalchemy.create_engine
#sql_connection = sqlite:////var/lib/glance/glance.sqlite
sql_connection = mysql://glance_user:glance_pass@glance_host/glance
# Period in seconds after which SQLAlchemy should reestablish its connection
# to the database.
#
# MySQL uses a default `wait_timeout` of 8 hours, after which it will drop
# idle connections. This can result in 'MySQL Gone Away' exceptions. If you
# notice this, you can lower this value to ensure that SQLAlchemy reconnects
# before MySQL can drop the connection.
sql_idle_timeout = 3600
# Limit the api to return `param_limit_max` items in a call to a container. If
# a larger `limit` query param is provided, it will be reduced to this value.
api_limit_max = 1000
# If a `limit` query param is not provided in an api request, it will
# default to `limit_param_default`
limit_param_default = 25
[pipeline:glance-registry]
pipeline = context registryapp
# NOTE: use the following pipeline for keystone
# pipeline = authtoken keystone_shim context registryapp
[app:registryapp]
paste.app_factory = glance.registry.server:app_factory
[filter:context]
context_class = glance.registry.context.RequestContext
paste.filter_factory = glance.common.context:filter_factory
[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
service_protocol = http
service_host = 127.0.0.1
service_port = 5000
auth_host = 127.0.0.1
auth_port = 5001
auth_protocol = http
auth_uri = http://127.0.0.1:5000/
admin_token = 999888777666
[filter:keystone_shim]
paste.filter_factory = keystone.middleware.glance_auth_token:filter_factory
</programlisting>
</listitem>
<listitem>
<para><emphasis role="bold">Fire up Glance</emphasis></para>
<para>You should now be able to start glance (glance-control runs
bothh glance-api and glance-registry services : <literallayout
class="monospaced">glance-controll all start</literallayout> You
can now make sure the new version of Glance is running :
<literallayout class="monospaced">
ps axl |grep glance
</literallayout>But also make sure you are running
the Diablo version : <literallayout class="monospaced">glance --version
which should output :
glance 2011.3 </literallayout> If you do not see the two
process running, an error occured somewhere. You can check for
errors by running :</para>
<para><literallayout class="monospaced"> glance-api /etc/glance/glance-api.conf and :
glance-registry /etc/glance/glance-registry.conf</literallayout> You are now
ready to upgrade the database scheme.</para>
<para/>
</listitem>
<listitem>
<para><emphasis role="bold">Update Glance
database</emphasis></para>
<para>Before running any upgrade, make sure you backup the
database. If you have a MySQL backend : <literallayout
class="monospaced">
mysqldump -u $glance_user -p$glance_password glance &gt; glance_backup.sql
</literallayout>If you use the default backend, SQLite,
simply copy the database's file. You are now ready to update the
database scheme. In order to update the Glance service, just run :
<literallayout class="monospaced"> glance-manage db_sync </literallayout></para>
</listitem>
<listitem>
<para><emphasis role="bold">Validation test</emphasis></para>
<para>In order to make sure Glance has been properly updated,
simply run : <literallayout class="monospaced">glance index</literallayout>
which should display your registered images : <programlisting>
ID Name Disk Format Container Format Size
---------------- ------------------------------ -------------------- -------------------- --------------
94 Debian 6.0.3 amd64 raw bare 1067778048
</programlisting></para>
</listitem>
</orderedlist>
</simplesect>
<simplesect>
<title>B- Nova upgrade</title>
<para>In order to successfully go through the upgrade process, it is
advised to follow the exact order of the process' steps. By doing so,
you make sure you don't miss any mandatory step.</para>
<orderedlist>
<listitem>
<para><emphasis role="bold">Update the
repositoiries</emphasis></para>
<para>Update your "/etc/apt/sources.list", or create a
"/etc/apt/sources.list.d/openstack_diablo.list file :
<programlisting>
deb http://ppa.launchpad.net/openstack-release/2011.<emphasis role="bold">3</emphasis>/ubuntu maverick main
deb-src http://ppa.launchpad.net/openstack-release/2011.<emphasis role="bold">3</emphasis>/ubuntu maverick main
</programlisting>If you are running Ubuntu Lucid,
point to Lucid, otherwise to another version (Maverick, or Natty).
You can now update the repository (do not upgrade the packages at
the moment) : <literallayout class="monospaced">aptitude update</literallayout></para>
</listitem>
<listitem>
<para><emphasis role="bold">Stop all nova
services</emphasis></para>
<para>By stopping all nova services, that would make our instances
unreachables (for instance, stopping the nova-network service will
make all the routing rules flushed) ; but they won't neither be
terminated, nor deleted.</para>
<itemizedlist>
<listitem>
<para>We first stop nova services</para>
<para><literallayout>cd /etc/init.d &amp;&amp; for i in $(ls nova-*); do service $i stop; done</literallayout></para>
</listitem>
<listitem>
<para>We stop rabbitmq; used by nova-scheduler</para>
<para><literallayout class="monospaced">service rabbitmq-server stop</literallayout></para>
</listitem>
<listitem>
<para>We finally killl dnsmasq, used by nova-network</para>
<para><literallayout class="monospaced">killall dnsmasq</literallayout></para>
</listitem>
</itemizedlist>
<para>You can make sure not any services used by nova are still
running via :</para>
<para><literallayout class="monospaced">ps axl | grep nova</literallayout>
that should not output any service, if so, simply kill the
PIDs</para>
<para/>
</listitem>
<listitem>
<para><emphasis role="bold">MySQL pre-requisites</emphasis></para>
<para>Before running the upgrade, make sure the following tables
don't already exist (They could, if you ran tests, or by mistake
an upgrade) : <simplelist>
<member>block_device_mapping</member>
<member>snapshots</member>
<member>provider_fw_rules</member>
<member>instance_type_extra_specs</member>
<member>virtual_interfaces</member>
<member>volume_types</member>
<member>volume_type_extra_specs</member>
<member>volume_metadata;</member>
<member>virtual_storage_arrays</member>
</simplelist> If so, you can safely remove them; since they are
not used at all by Cactus (2011.2) :</para>
<para><programlisting>
drop table block_device_mapping;
drop table snapshots;
drop table provider_fw_rules;
drop table instance_type_extra_specs;
drop table virtual_interfaces;
drop table volume_types;
drop table volume_type_extra_specs;
drop table volume_metadata;
drop table virtual_storage_arrays;
</programlisting></para>
<para/>
</listitem>
<listitem>
<para><emphasis role="bold">Upgrade nova
packages</emphasis></para>
<para>You can now perform an upgrade : <literallayout
class="monospaced">aptitude upgrade</literallayout> During the
upgrade process, you would see : <programlisting>
Configuration file '/etc/nova/nova.conf'
==&gt; Modified (by you or by a script) since installation.
==&gt; Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** /etc/nova/nova.conf (Y/I/N/O/D/Z) [default=N] ?
</programlisting> Type "N" or validate in order to keep your current
configuration file. We will manually update in order to use some
of new Diablo settings.</para>
<para/>
</listitem>
<listitem>
<para><emphasis role="bold">Update the configuration
files</emphasis></para>
<para>Diablo introduces several new files :</para>
<para>api-paste.ini, which contains all api-related
settings</para>
<para>nova-compute.conf, a configuration file dedicated to the
compte-node settings.</para>
<para>Here are the settings you would add into nova.conf :</para>
<programlisting>
--multi_host=T
--api_paste_config=/etc/nova/api-paste.ini
</programlisting>
<para>and that one if you plan to integrate Keystone to your
environment, with euca2ools :</para>
<programlisting>
--keystone_ec2_url=http://$NOVA-API-IP.11:5000/v2.0/ec2tokens
</programlisting>
<para>Here is how the files should look like :</para>
<literallayout class="monospaced">nova.conf</literallayout>
<programlisting>
--dhcpbridge_flagfile=/etc/nova/nova.conf
--dhcpbridge=/usr/bin/nova-dhcpbridge
--logdir=/var/log/nova
--state_path=/var/lib/nova
--lock_path=/var/lock/nova
--flagfile=/etc/nova/nova-compute.conf
--force_dhcp_release=True
--verbose
--daemonize=1
--s3_host=172.16.40.11
--rabbit_host=172.16.40.11
--cc_host=172.16.40.11
--keystone_ec2_url=http://172.16.40.11:5000/v2.0/ec2tokens
--ec2_url=http://172.16.40.11:8773/services/Cloud
--ec2_host=172.16.40.11
--ec2_dmz_host=172.16.40.11
--ec2_port=8773
--fixed_range=192.168.0.0/12
--FAKE_subdomain=ec2
--routing_source_ip=10.0.10.14
--sql_connection=mysql://nova:nova-pass@172.16.40.11/nova
--glance_api_servers=172.16.40.13:9292
--image_service=nova.image.glance.GlanceImageService
--image_decryption_dir=/var/lib/nova/tmp
--network_manager=nova.network.manager.VlanManager
--public_interface=eth0
--vlan_interface=eth0
--iscsi_ip_prefix=172.16.40.12
--vnc_enabled
--multi_host=T
--debug
--api_paste_config=/etc/nova/api-paste.ini
</programlisting>
<para><literallayout class="monospaced">api-paste.ini</literallayout></para>
<programlisting>
#######
# EC2 #
#######
[composite:ec2]
use = egg:Paste#urlmap
/: ec2versions
/services/Cloud: ec2cloud
/services/Admin: ec2admin
/latest: ec2metadata
/2007-01-19: ec2metadata
/2007-03-01: ec2metadata
/2007-08-29: ec2metadata
/2007-10-10: ec2metadata
/2007-12-15: ec2metadata
/2008-02-01: ec2metadata
/2008-09-01: ec2metadata
/2009-04-04: ec2metadata
/1.0: ec2metadata
[pipeline:ec2cloud]
# pipeline = logrequest ec2noauth cloudrequest authorizer ec2executor
# NOTE(vish): use the following pipeline for deprecated auth
pipeline = logrequest authenticate cloudrequest authorizer ec2executor
[pipeline:ec2admin]
# pipeline = logrequest ec2noauth adminrequest authorizer ec2executor
# NOTE(vish): use the following pipeline for deprecated auth
pipeline = logrequest authenticate adminrequest authorizer ec2executor
[pipeline:ec2metadata]
pipeline = logrequest ec2md
[pipeline:ec2versions]
pipeline = logrequest ec2ver
[filter:logrequest]
paste.filter_factory = nova.api.ec2:RequestLogging.factory
[filter:ec2lockout]
paste.filter_factory = nova.api.ec2:Lockout.factory
[filter:ec2noauth]
paste.filter_factory = nova.api.ec2:NoAuth.factory
[filter:authenticate]
paste.filter_factory = nova.api.ec2:Authenticate.factory
[filter:cloudrequest]
controller = nova.api.ec2.cloud.CloudController
paste.filter_factory = nova.api.ec2:Requestify.factory
[filter:adminrequest]
controller = nova.api.ec2.admin.AdminController
paste.filter_factory = nova.api.ec2:Requestify.factory
[filter:authorizer]
paste.filter_factory = nova.api.ec2:Authorizer.factory
[app:ec2executor]
paste.app_factory = nova.api.ec2:Executor.factory
[app:ec2ver]
paste.app_factory = nova.api.ec2:Versions.factory
[app:ec2md]
paste.app_factory = nova.api.ec2.metadatarequesthandler:MetadataRequestHandler.factory
#############
# Openstack #
#############
[composite:osapi]
use = egg:Paste#urlmap
/: osversions
/v1.0: openstackapi10
/v1.1: openstackapi11
[pipeline:openstackapi10]
# pipeline = faultwrap noauth ratelimit osapiapp10
# NOTE(vish): use the following pipeline for deprecated auth
pipeline = faultwrap auth ratelimit osapiapp10
[pipeline:openstackapi11]
# pipeline = faultwrap noauth ratelimit extensions osapiapp11
# NOTE(vish): use the following pipeline for deprecated auth
pipeline = faultwrap auth ratelimit extensions osapiapp11
[filter:faultwrap]
paste.filter_factory = nova.api.openstack:FaultWrapper.factory
[filter:auth]
paste.filter_factory = nova.api.openstack.auth:AuthMiddleware.factory
[filter:noauth]
paste.filter_factory = nova.api.openstack.auth:NoAuthMiddleware.factory
[filter:ratelimit]
paste.filter_factory = nova.api.openstack.limits:RateLimitingMiddleware.factory
[filter:extensions]
paste.filter_factory = nova.api.openstack.extensions:ExtensionMiddleware.factory
[app:osapiapp10]
paste.app_factory = nova.api.openstack:APIRouterV10.factory
[app:osapiapp11]
paste.app_factory = nova.api.openstack:APIRouterV11.factory
[pipeline:osversions]
pipeline = faultwrap osversionapp
[app:osversionapp]
paste.app_factory = nova.api.openstack.versions:Versions.factory
##########
# Shared #
##########
[filter:keystonecontext]
paste.filter_factory = keystone.middleware.nova_keystone_context:NovaKeystoneContext.factory
[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
service_protocol = http
service_host = 127.0.0.1
service_port = 5000
auth_host = 127.0.0.1
auth_port = 5001
auth_protocol = http
auth_uri = http://127.0.0.1:5000/
admin_token = 999888777666
</programlisting>
</listitem>
<listitem>
<para><emphasis role="bold">Database update</emphasis></para>
<para>You are now ready to upgrade the database, by running :
<literallayout class="monospaced">nova-manage db sync</literallayout></para>
<para>You will also need to update the field "bridge_interface"
for your network into your database, and make sure that field
contains the inteface used for the brige (in our case eth1) :
<programlisting>
created_at: 2011-06-08 07:45:23
updated_at: 2011-06-08 07:46:06
deleted_at: NULL
deleted: 0
id: 9
injected: NULL
cidr: 192.168.2.0/24
netmask: 255.255.255.0
bridge: br100
gateway: 192.168.2.1
broadcast: 192.168.2.255
dns1: NULL
vlan: 100
vpn_public_address: 172.16.40.11
vpn_public_port: 1000
vpn_private_address: 192.168.2.2
dhcp_start: 192.168.2.3
project_id: myproject
host: nova-cc1
cidr_v6: NULL
gateway_v6: NULL
label: NULL
netmask_v6: NULL
bridge_interface: eth1
multi_host: 0
dns2: NULL
uuid: 852fa14
</programlisting>Without the update of that field,
nova-network won't start since it won't be able to create the
bridges per network.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Restart the services</emphasis></para>
<para>After the database upgrade, services can be restarted
:</para>
<itemizedlist>
<listitem>
<para>Rabbitmq-server <literallayout class="monospaced">service rabbitmq-server start</literallayout></para>
</listitem>
<listitem>
<para>Nova services <literallayout class="monospaced">cd /etc/init.d &amp;&amp; for i $(ls nova-*); do service $i start; done</literallayout>
You can check the version you are running : <literallayout
class="monospaced">nova-manage version</literallayout>Should
ouput : <literallayout class="monospaced">2011.3 </literallayout></para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para><emphasis role="bold">Validation test</emphasis></para>
<para>The first thing to check is all the services are all running
:</para>
<literallayout class="monospaced">ps axl | grep nova</literallayout>
<para>should output all the services running. If some services are
missing, check their appropriate log files (e.g
/var/log/nova/nova-api.log). You would then use nova-manage :
<literallayout class="monospaced">nova-manage service list</literallayout></para>
<para>If all the services are up, you can now validate the
migration by : <simplelist>
<member>Launching a new instance</member>
<member>Terminate a running instance</member>
<member>Attach a floating IP to an "old" and a "new"
instance</member>
</simplelist></para>
</listitem>
</orderedlist>
</simplesect>
<simplesect>
<title>C- Client tools upgrade</title>
<para>In this part we will see how to make sure our management tools
will be correctly integrated to the new environment's version :
<simplelist>
<member><link
xlink:href="http://nova.openstack.org/2011.2/runnova/euca2ools.html?highlight=euca2ools">euca2ools</link></member>
<member><link
xlink:href="https://github.com/rackspace/python-novaclient">novaclient</link></member>
</simplelist></para>
<orderedlist>
<listitem>
<para><emphasis role="bold">euca2ools</emphasis></para>
<para>The euca2ools settings do not change from the client side
:</para>
<programlisting>
# Euca2ools
export NOVA_KEY_DIR=/root/creds/
export EC2_ACCESS_KEY="EC2KEY:USER"
export EC2_SECRET_KEY="SECRET_KEY"
export EC2_URL="http://$NOVA-API-IP:8773/services/Cloud"
export S3_URL="http://$NOVA-API-IP:3333"
export EC2_USER_ID=42 # nova does not use user id, but bundling requires it
export EC2_PRIVATE_KEY=${NOVA_KEY_DIR}/pk.pem
export EC2_CERT=${NOVA_KEY_DIR}/cert.pem
export NOVA_CERT=${NOVA_KEY_DIR}/cacert.pem
export EUCALYPTUS_CERT=${NOVA_CERT} # euca-bundle-image seems to require this set
alias ec2-bundle-image="ec2-bundle-image --cert ${EC2_CERT} --privatekey ${EC2_PRIVATE_KEY} --user 42 --ec2cert ${NOVA_CERT}"
alias ec2-upload-bundle="ec2-upload-bundle -a ${EC2_ACCESS_KEY} -s ${EC2_SECRET_KEY} --url ${S3_URL} --ec2cert ${NOVA_CERT}"
</programlisting>
<para>On server-side, there are also not any changes to make,
since we don't use keystone. Here are some commands you should be
able to run : <literallayout class="monospaced">
euca-describe-instances
euca-describe-adresses
euca-terminate-instance $instance_id
euca-create-volume -s 5 -z $zone
euca-attach-volume -i $instance_id -d $device $volume_name
euca-associate-address -i $instance_id $address
</literallayout> If all these commands work
flawlessly, it means the tools in properly integrated.</para>
<para/>
</listitem>
<listitem>
<para><emphasis role="bold">python-novaclient</emphasis></para>
<para>This tool requires a recent version on order to use all the
service the OSAPI offers (floating-ip support, volumes support,
etc..). In order to upgrade it : <literallayout
class="monospaced">git clone https://github.com/rackspace/python-novaclient.git &amp;&amp; cd python-novaclient
python setup.py build
python setup.py install
</literallayout> Make sure you have the correct
settings into your .bashrc (or any source-able file) :
<programlisting>
# Python-novaclient
export NOVA_API_KEY="SECRET_KEY"
export NOVA_PROJECT_ID="PROJECT-NAME"
export NOVA_USERNAME="USER"
export NOVA_URL="http://$NOVA-API-IP:8774/v1.1"
export NOVA_VERSION=1.1
</programlisting> He are some nova commands you
should be able to run : <literallayout class="monospaced">
nova list
nova image-show
nova boot $flavor_id --image $image_id --key_name $key_name $instance_name
nova volume-create --display_name $name $size
</literallayout> Again, if the commands run without
any error, the tools is then properly integrated.</para>
</listitem>
</orderedlist>
</simplesect>
<simplesect>
<title>D- Known issues</title>
<para><itemizedlist>
<listitem>
<para>UnicodeEncodeError: 'ascii' codec can't encode character
u'\xe9' in position 11: ordinal not in range(128)</para>
<para>This error could be found into nova-network.log. It is due
to libvirt which doesn't know how to deal with encoded
characters. That will happen if the locale of your system
differs from "C" or "POSIX".</para>
<para>In order to resolve that issue, while the system is
running, you will have to do : <literallayout
class="monospaced">sudo nova -c "export LANG C" &amp;&amp; export LANG=C</literallayout>That
changes the locale for the running user, and for the nova user.
In order to make these changes permanent, you will need to edit
the default locale file : (/etc/default/locale) : <literallayout
class="monospaced">LANG="C"</literallayout>Note that you will
need to reboot the server in order to validate the changes you
just made to the file, hence our previous command (which
directly fixes the locale issue).</para>
</listitem>
</itemizedlist></para>
</simplesect>
<simplesect>
<title>D- Why is Keystone not integrated ?</title>
<para>Keystone introduces a new identity management, instead of having
users into nova's database, they are now fully relegated to Keystone.
While nova deals with "users as IDs" (eg : the project name is the
project id), Keystones makes a difference between a name and an ID. ;
thus, the integration breaks a running Cactus cloud. Since we were
looking for a smooth integration on a running platform, Keystone has
not been integrated.</para>
<para>If you want to integrate Keystone, here are the steps you would
follow :</para>
<orderedlist>
<listitem>
<para><emphasis role="bold">Export the current
project</emphasis></para>
<para>The first thing to do is export all credentials-related
settings from nova :</para>
<literallayout class="monospaced">nova-manage shell export --filename=nova_export.txt</literallayout>
<para>The created file contains keystone commands (via
keystone-manage tool) ; you can import simply import the settings
with a loop :</para>
<literallayout class="monospaced">while read line; do $line; done &lt; nova_export.txt</literallayout>
</listitem>
<listitem>
<para><emphasis role="bold">Enable the pipelines</emphasis></para>
<para>Pipelines are like "communication links" between components.
In our case we need to enable pipelines from all the components to
Keystone.</para>
<itemizedlist>
<listitem>
<para><emphasis>Glance Pipeline</emphasis> <literallayout
class="monospaced">glance-api.conf</literallayout>
<programlisting>
[pipeline:glance-api]
pipeline = versionnegotiation authtoken context apiv1app
# To enable Image Cache Management API replace pipeline with below:
# pipeline = versionnegotiation context imagecache apiv1app
# NOTE: use the following pipeline for keystone auth (with caching)
pipeline = versionnegotiation authtoken context imagecache apiv1app
[...]
# Keystone
[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
service_protocol = http
service_host = 127.0.0.1
service_port = 5000
auth_host = 127.0.0.1
auth_port = 5001
auth_protocol = http
auth_uri = http://127.0.0.1:5000/
admin_token = 999888777666
</programlisting> <literallayout
class="monospaced">glance-registry.conf</literallayout>
<programlisting>
[pipeline:glance-registry]
# pipeline = context registryapp
# NOTE: use the following pipeline for keystone
pipeline = authtoken keystone_shim context registryapp
[...]
# Keystone
[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
service_protocol = http
service_host = 127.0.0.1
service_port = 5000
auth_host = 127.0.0.1
auth_port = 5001
auth_protocol = http
auth_uri = http://127.0.0.1:5000/
admin_token = 999888777666
[filter:keystone_shim]
paste.filter_factory = keystone.middleware.glance_auth_token:filter_factory
</programlisting></para>
</listitem>
<listitem>
<para><emphasis> Nova Pipeline </emphasis> <literallayout
class="monospaced">nova.conf</literallayout> <programlisting>
--keystone_ec2_url=http://$KEYSTONE-IP:5000/v2.0/ec2tokens
</programlisting></para>
<literallayout class="monospaced">api-paste.ini</literallayout>
<programlisting>
# EC2 API
[pipeline:ec2cloud]
pipeline = logrequest totoken authtoken keystonecontext cloudrequest authorizer ec2executor
# NOTE(vish): use the following pipeline for deprecated auth
# pipeline = logrequest authenticate cloudrequest authorizer ec2executor
[pipeline:ec2admin]
pipeline = logrequest totoken authtoken keystonecontext adminrequest authorizer ec2executor
# NOTE(vish): use the following pipeline for deprecated auth
# pipeline = logrequest authenticate adminrequest authorizer ec2executor
# OSAPI
[pipeline:openstackapi10]
pipeline = faultwrap authtoken keystonecontext ratelimit osapiapp10
# NOTE(vish): use the following pipeline for deprecated auth
# pipeline = faultwrap auth ratelimit osapiapp10
[pipeline:openstackapi11]
pipeline = faultwrap authtoken keystonecontext ratelimit extensions osapiapp11
# NOTE(vish): use the following pipeline for deprecated auth
# pipeline = faultwrap auth ratelimit extensions osapiapp11
##########
# Shared #
##########
[filter:keystonecontext]
paste.filter_factory = keystone.middleware.nova_keystone_context:NovaKeystoneContext.factory
[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
service_protocol = http
service_host = 127.0.0.1
service_port = 5000
auth_host = 127.0.0.1
auth_port = 5001
auth_protocol = http
auth_uri = http://127.0.0.1:5000/
admin_token = 999888777666
</programlisting>
</listitem>
<listitem>
<para><emphasis>euca2ools</emphasis> <literallayout
class="monospaced">.bashrc</literallayout> <programlisting>
# Euca2ools
[...]
export EC2_URL="http://$NOVA-API-IP:8773/services/Cloud"
[...]
</programlisting></para>
</listitem>
<listitem>
<para><emphasis>novaclient</emphasis> <literallayout
class="monospaced">novaclient</literallayout> <programlisting>
# Novaclient
[...]
export NOVA_URL=http://$KEYSTONe-IP:5000/v.20/
export NOVA_REGION_NAME="$REGION"
[...]
</programlisting></para>
</listitem>
</itemizedlist>
</listitem>
</orderedlist>
</simplesect>
</section>
</section>
</chapter>
View Git Blame Copy Permalink