Merge "Restructured Compute chapter in Cloud Admin Guide"
This commit is contained in:
@@ -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"/>
|
||||||
|
@@ -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>
|
||||||
|
@@ -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>
|
||||||
|
Reference in New Issue
Block a user