Merge "Restructured Compute chapter in Cloud Admin Guide"

This commit is contained in:
Jenkins
2014-04-29 15:00:28 +00:00
committed by Gerrit Code Review
3 changed files with 476 additions and 478 deletions

View File

@@ -66,7 +66,6 @@
controller using AMQP (advanced message queueing protocol). To avoid blocking a controller using AMQP (advanced message queueing protocol). To avoid blocking a
component while waiting for a response, Compute uses asynchronous calls, with a callback component while waiting for a response, Compute uses asynchronous calls, with a callback
that is triggered when a response is received.</para> that is triggered when a response is received.</para>
</section>
<section xml:id="section_hypervisors"> <section xml:id="section_hypervisors">
<title>Hypervisors</title> <title>Hypervisors</title>
<para xlink:href="https://www.docker.io/">Compute controls hypervisors through an API <para xlink:href="https://www.docker.io/">Compute controls hypervisors through an API
@@ -182,8 +181,6 @@
would normally expect to enter a tenant ID.</para> would normally expect to enter a tenant ID.</para>
</note> </note>
</section> </section>
<xi:include href="compute/section_compute-images-instances.xml"/>
<xi:include href="../common/section_compute_config-firewalls.xml"/>
<section xml:id="section_storage-and-openstack-compute"> <section xml:id="section_storage-and-openstack-compute">
<title>Block storage</title> <title>Block storage</title>
<para>OpenStack provides two classes of block storage: <para>OpenStack provides two classes of block storage:
@@ -371,7 +368,6 @@
</listitem> </listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>
<para>Virtual hardware templates are called <para>Virtual hardware templates are called
<literal>flavors</literal>. The default installation <literal>flavors</literal>. The default installation
provides five flavors. By default, these are configurable provides five flavors. By default, these are configurable
@@ -394,81 +390,96 @@
+----+-----------+-----------+------+-----------+------+-------+-------------+ +----+-----------+-----------+------+-----------+------+-------+-------------+
</computeroutput></screen> </computeroutput></screen>
</section> </section>
<xi:include href="../common/section_cli_nova_customize_flavors.xml"/> <section xml:id="section_compute-service-arch">
<section xml:id="admin-password-injection"> <title>Compute service architecture</title>
<?dbhtml stop-chunking?> <para>The following basic categories describe the service architecture and what's going
<title>Admin password injection</title> on within the cloud controller.</para>
<para>You can configure Compute to generate a random administrator (root) password and
inject that password into the instance. If this feature is enabled, a user can
<command>ssh</command> to an instance without an <command>ssh</command> keypair. The
random password appears in the output of the <command>nova boot</command> command. You
can also view and set the <literal>admin</literal> password from the dashboard.</para>
<simplesect> <simplesect>
<title>Dashboard</title> <title>API server</title>
<para>The dashboard is configured by default to display the <literal>admin</literal> <para>At the heart of the cloud framework is an API server. This API server makes
password and allow the user to modify it.</para> command and control of the hypervisor, storage, and networking programmatically
<para>If you do not want to support password injection, we available to users.</para>
recommend disabling the password fields by editing <para>The API endpoints are basic HTTP web services
your Dashboard <filename>local_settings</filename> which handle authentication, authorization, and
file (file location will vary by Linux distribution, basic command and control functions using various
on Fedora/RHEL/CentOS: <filename> API interfaces under the Amazon, Rackspace, and
/etc/openstack-dashboard/local_settings</filename>, related models. This enables API compatibility
on Ubuntu and Debian: with multiple existing tool sets created for
<filename>/etc/openstack-dashboard/local_settings.py</filename> interaction with offerings from other vendors.
and on openSUSE and SUSE Linux Enterprise Server: This broad compatibility prevents vendor
<filename>/srv/www/openstack-dashboard/openstack_dashboard/local/local_settings.py</filename>) lock-in.</para>
<programlisting language="ini">OPENSTACK_HYPERVISOR_FEATURE = {
...
'can_set_password': False,
}</programlisting></para>
</simplesect> </simplesect>
<simplesect> <simplesect>
<title>Libvirt-based hypervisors (KVM, QEMU, LXC)</title> <title>Message queue</title>
<para>For hypervisors such as KVM that use the libvirt backend, <literal>admin</literal> <para>A messaging queue brokers the interaction
password injection is disabled by default. To enable it, set the following option in between compute nodes (processing), the networking
<filename>/etc/nova/nova.conf</filename>:</para> controllers (software which controls network
<para> infrastructure), API endpoints, the scheduler
<programlisting language="ini">[libvirt] (determines which physical hardware to allocate to
inject_password=true</programlisting> a virtual resource), and similar components.
</para> Communication to and from the cloud controller is
<para>When enabled, Compute will modify the password of by HTTP requests through multiple API
the root account by editing the endpoints.</para>
<filename>/etc/shadow</filename> file inside of <para>A typical message passing event begins with the API server receiving a request
the virtual machine instance.</para> from a user. The API server authenticates the user and ensures that the user is
<note> permitted to issue the subject command. The availability of objects implicated in
<para>Users can only ssh to the instance by using the the request is evaluated and, if available, the request is routed to the queuing
admin password if:</para> engine for the relevant workers. Workers continually listen to the queue based on
their role, and occasionally their type host name. When an applicable work request
arrives on the queue, the worker takes assignment of the task and begins its
execution. Upon completion, a response is dispatched to the queue which is received
by the API server and relayed to the originating user. Database entries are queried,
added, or removed as necessary throughout the process.</para>
</simplesect>
<simplesect>
<title>Compute worker</title>
<para>Compute workers manage computing instances on
host machines. The API dispatches commands to
compute workers to complete these tasks:</para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para>The virtual machine image is a Linux <para>Run instances</para>
distribution</para>
</listitem> </listitem>
<listitem> <listitem>
<para>The virtual machine has been configured to allow users to <para>Terminate instances</para>
<command>ssh</command> as the root user. This is not the case for </listitem>
<link xlink:href="http://cloud-images.ubuntu.com/">Ubuntu cloud <listitem>
images</link>, which disallow <command>ssh</command> to the root <para>Reboot instances</para>
account by default.</para> </listitem>
<listitem>
<para>Attach volumes</para>
</listitem>
<listitem>
<para>Detach volumes</para>
</listitem>
<listitem>
<para>Get console output</para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
</note>
</simplesect> </simplesect>
<simplesect> <simplesect>
<title>XenAPI (XenServer/XCP)</title> <title>Network Controller</title>
<para>Compute uses the XenAPI agent to inject passwords into guests when using the <para>The Network Controller manages the networking
XenAPI hypervisor backend. The virtual-machine image must be configured with the resources on host machines. The API server
agent for password injection to work.</para> dispatches commands through the message queue,
</simplesect> which are subsequently processed by Network
<simplesect> Controllers. Specific operations include:</para>
<title>Windows images (all hypervisors)</title> <itemizedlist>
<para>To support the <literal>admin</literal> password for Windows virtual machines, you <listitem>
must configure the Windows image to retrieve the <literal>admin</literal> password <para>Allocate fixed IP addresses</para>
on boot by installing an agent such as <link </listitem>
xlink:href="https://github.com/cloudbase/cloudbase-init" <listitem>
>cloudbase-init</link>.</para> <para>Configuring VLANs for projects</para>
</listitem>
<listitem>
<para>Configuring networks for compute
nodes</para>
</listitem>
</itemizedlist>
</simplesect> </simplesect>
</section> </section>
<xi:include href="../common/section_cli_nova_volumes.xml"/> </section>
<xi:include href="compute/section_compute-images-instances.xml"/>
<xi:include href="compute/section_compute-networking-nova.xml"/> <xi:include href="compute/section_compute-networking-nova.xml"/>
<xi:include href="compute/section_compute-system-admin.xml"/> <xi:include href="compute/section_compute-system-admin.xml"/>
<xi:include href="../common/section_support-compute.xml"/> <xi:include href="../common/section_support-compute.xml"/>

View File

@@ -83,94 +83,6 @@
</listitem> </listitem>
</itemizedlist> </itemizedlist>
</para> </para>
<section xml:id="section_compute-service-arch">
<title>Compute service architecture</title>
<para>The following basic categories describe the service architecture and what's going
on within the cloud controller.</para>
<simplesect>
<title>API server</title>
<para>At the heart of the cloud framework is an API server. This API server makes
command and control of the hypervisor, storage, and networking programmatically
available to users.</para>
<para>The API endpoints are basic HTTP web services
which handle authentication, authorization, and
basic command and control functions using various
API interfaces under the Amazon, Rackspace, and
related models. This enables API compatibility
with multiple existing tool sets created for
interaction with offerings from other vendors.
This broad compatibility prevents vendor
lock-in.</para>
</simplesect>
<simplesect>
<title>Message queue</title>
<para>A messaging queue brokers the interaction
between compute nodes (processing), the networking
controllers (software which controls network
infrastructure), API endpoints, the scheduler
(determines which physical hardware to allocate to
a virtual resource), and similar components.
Communication to and from the cloud controller is
by HTTP requests through multiple API
endpoints.</para>
<para>A typical message passing event begins with the API server receiving a request
from a user. The API server authenticates the user and ensures that the user is
permitted to issue the subject command. The availability of objects implicated in
the request is evaluated and, if available, the request is routed to the queuing
engine for the relevant workers. Workers continually listen to the queue based on
their role, and occasionally their type host name. When an applicable work request
arrives on the queue, the worker takes assignment of the task and begins its
execution. Upon completion, a response is dispatched to the queue which is received
by the API server and relayed to the originating user. Database entries are queried,
added, or removed as necessary throughout the process.</para>
</simplesect>
<simplesect>
<title>Compute worker</title>
<para>Compute workers manage computing instances on
host machines. The API dispatches commands to
compute workers to complete these tasks:</para>
<itemizedlist>
<listitem>
<para>Run instances</para>
</listitem>
<listitem>
<para>Terminate instances</para>
</listitem>
<listitem>
<para>Reboot instances</para>
</listitem>
<listitem>
<para>Attach volumes</para>
</listitem>
<listitem>
<para>Detach volumes</para>
</listitem>
<listitem>
<para>Get console output</para>
</listitem>
</itemizedlist>
</simplesect>
<simplesect>
<title>Network Controller</title>
<para>The Network Controller manages the networking
resources on host machines. The API server
dispatches commands through the message queue,
which are subsequently processed by Network
Controllers. Specific operations include:</para>
<itemizedlist>
<listitem>
<para>Allocate fixed IP addresses</para>
</listitem>
<listitem>
<para>Configuring VLANs for projects</para>
</listitem>
<listitem>
<para>Configuring networks for compute
nodes</para>
</listitem>
</itemizedlist>
</simplesect>
</section>
<section xml:id="section_manage-compute-users"> <section xml:id="section_manage-compute-users">
<title>Manage Compute users</title> <title>Manage Compute users</title>
<para>Access to the Euca2ools (ec2) API is controlled by <para>Access to the Euca2ools (ec2) API is controlled by
@@ -181,6 +93,82 @@
commands on behalf of the user.</para> commands on behalf of the user.</para>
<para>To begin using Compute, you must create a user with <para>To begin using Compute, you must create a user with
the Identity Service.</para> the Identity Service.</para>
</section>
<xi:include href="../../common/section_cli_nova_volumes.xml"/>
<xi:include href="../../common/section_cli_nova_customize_flavors.xml"/>
<xi:include href="../../common/section_compute_config-firewalls.xml"/>
<section xml:id="admin-password-injection">
<?dbhtml stop-chunking?>
<title>Inject administrator password</title>
<para>You can configure Compute to generate a random administrator (root) password and
inject that password into the instance. If this feature is enabled, a user can
<command>ssh</command> to an instance without an <command>ssh</command> keypair. The
random password appears in the output of the <command>nova boot</command> command. You
can also view and set the <literal>admin</literal> password from the dashboard.</para>
<simplesect>
<title>Dashboard</title>
<para>The dashboard is configured by default to display the <literal>admin</literal>
password and allow the user to modify it.</para>
<para>If you do not want to support password injection, we
recommend disabling the password fields by editing
your Dashboard <filename>local_settings</filename>
file (file location will vary by Linux distribution,
on Fedora/RHEL/CentOS: <filename>
/etc/openstack-dashboard/local_settings</filename>,
on Ubuntu and Debian:
<filename>/etc/openstack-dashboard/local_settings.py</filename>
and on openSUSE and SUSE Linux Enterprise Server:
<filename>/srv/www/openstack-dashboard/openstack_dashboard/local/local_settings.py</filename>)
<programlisting language="ini">OPENSTACK_HYPERVISOR_FEATURE = {
...
'can_set_password': False,
}</programlisting></para>
</simplesect>
<simplesect>
<title>Libvirt-based hypervisors (KVM, QEMU, LXC)</title>
<para>For hypervisors such as KVM that use the libvirt backend, <literal>admin</literal>
password injection is disabled by default. To enable it, set the following option in
<filename>/etc/nova/nova.conf</filename>:</para>
<para>
<programlisting language="ini">[libvirt]
inject_password=true</programlisting>
</para>
<para>When enabled, Compute will modify the password of
the root account by editing the
<filename>/etc/shadow</filename> file inside of
the virtual machine instance.</para>
<note>
<para>Users can only ssh to the instance by using the
admin password if:</para>
<itemizedlist>
<listitem>
<para>The virtual machine image is a Linux
distribution</para>
</listitem>
<listitem>
<para>The virtual machine has been configured to allow users to
<command>ssh</command> as the root user. This is not the case for
<link xlink:href="http://cloud-images.ubuntu.com/">Ubuntu cloud
images</link>, which disallow <command>ssh</command> to the root
account by default.</para>
</listitem>
</itemizedlist>
</note>
</simplesect>
<simplesect>
<title>XenAPI (XenServer/XCP)</title>
<para>Compute uses the XenAPI agent to inject passwords into guests when using the
XenAPI hypervisor backend. The virtual-machine image must be configured with the
agent for password injection to work.</para>
</simplesect>
<simplesect>
<title>Windows images (all hypervisors)</title>
<para>To support the <literal>admin</literal> password for Windows virtual machines, you
must configure the Windows image to retrieve the <literal>admin</literal> password
on boot by installing an agent such as <link
xlink:href="https://github.com/cloudbase/cloudbase-init"
>cloudbase-init</link>.</para>
</simplesect>
</section> </section>
<section xml:id="section_manage-the-cloud"> <section xml:id="section_manage-the-cloud">
<title>Manage the cloud</title> <title>Manage the cloud</title>
@@ -250,16 +238,15 @@
</para> </para>
</step> </step>
</procedure> </procedure>
<simplesect> <section xml:id="section_euca2ools">
<title>Use the euca2ools commands</title> <title>Use the euca2ools commands</title>
<para>For a command-line interface to EC2 API calls, use the <para>For a command-line interface to EC2 API calls, use the
<command>euca2ools</command> command-line tool. See <link <command>euca2ools</command> command-line tool. See <link
xlink:href="http://open.eucalyptus.com/wiki/Euca2oolsGuide_v1.3" xlink:href="http://open.eucalyptus.com/wiki/Euca2oolsGuide_v1.3"
>http://open.eucalyptus.com/wiki/Euca2oolsGuide_v1.3</link></para> >http://open.eucalyptus.com/wiki/Euca2oolsGuide_v1.3</link></para>
</simplesect>
</section> </section>
<xi:include <xi:include href="../../common/section_cli_nova_usage_statistics.xml"/>
href="../../common/section_cli_nova_usage_statistics.xml"/> </section>
<section xml:id="section_manage-logs"> <section xml:id="section_manage-logs">
<title>Manage logs</title> <title>Manage logs</title>
<simplesect> <simplesect>

View File

@@ -5,7 +5,7 @@
xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0" version="5.0"
xml:id="nova_cli_volumes"> xml:id="nova_cli_volumes">
<title>Volumes</title> <title>Manage Volumes</title>
<para>Depending on the setup of your cloud provider, they may give you an endpoint to use to <para>Depending on the setup of your cloud provider, they may give you an endpoint to use to
manage volumes, or there may be an extension under the covers. In either case, you can use the manage volumes, or there may be an extension under the covers. In either case, you can use the
<command>nova</command> CLI to manage volumes:</para> <command>nova</command> CLI to manage volumes:</para>