Fix doc bugs -
bug 1034021 trailing off sentence in overview bug 1034772 included typo bug 1034462 scheduler typo bug 1017691 change in name of root wrap config option Change-Id: Ia7ecf12f39771c49915b927ea3f0de89c9f28327
This commit is contained in:
annegentle
parent
0746d130d1
commit
916c3383b7
|
|
@ -1,3 +1,4 @@
|
|||
.DS_Store
|
||||
target/
|
||||
*.xpr
|
||||
.bak
|
||||
|
|
|
|||
|
|
@ -297,7 +297,7 @@ xml:id="ch_getting-started-with-openstack">
|
|||
<listitem>
|
||||
<para>A database (configurable to which one). As it relies
|
||||
mostly on the other services for data, it stores very
|
||||
little data of it's own.</para>
|
||||
little data of its own.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
|
@ -384,7 +384,7 @@ xml:id="ch_getting-started-with-openstack">
|
|||
</itemizedlist>
|
||||
|
||||
|
||||
<para>During the last two releases, Nova has augmented it's
|
||||
<para>During the last two releases, Nova has augmented its
|
||||
console services. Console services allow end users to access
|
||||
their virtual instance's console through a proxy. This
|
||||
involves a pair of new daemons (nova-console and
|
||||
|
|
@ -480,10 +480,12 @@ xml:id="ch_getting-started-with-openstack">
|
|||
availability through the cluster. Other periodic processes
|
||||
include auditors, updaters and reapers.</para>
|
||||
|
||||
<para>As you can see from the diagram, Glance serves a central
|
||||
role to the overall IaaS picture. It accepts API requests for
|
||||
images (or image metadata) from end users or Nova components
|
||||
and can store it's disk files in</para>
|
||||
<para>As you can see from the diagram in the Conceptual
|
||||
Architecture section, Glance serves a central role to the
|
||||
overall IaaS picture. It accepts API requests for images (or
|
||||
image metadata) from end users or Nova components and can
|
||||
store its disk files in the object storage service,
|
||||
Swift.</para>
|
||||
</section>
|
||||
<section xml:id="overview-identity-arch">
|
||||
<title>Identity</title>
|
||||
|
|
|
|||
|
|
@ -81,31 +81,35 @@ servicing the request (<literal>ComputeFilter</literal>).</para>
|
|||
</figure>
|
||||
</para>
|
||||
|
||||
<para>The <literal>scheduler_available_filters</literal> configuration option
|
||||
in <filename>nova.conf</filename> provides the Compute service with the
|
||||
list of the filters that will be used by the scheduler. The default setting
|
||||
specifies all of the filter that are incldued with the Compute service:
|
||||
<programlisting>
|
||||
<para>The <literal>scheduler_available_filters</literal>
|
||||
configuration option in <filename>nova.conf</filename>
|
||||
provides the Compute service with the list of the filters
|
||||
that will be used by the scheduler. The default setting
|
||||
specifies all of the filter that are included with the
|
||||
Compute service:
|
||||
<programlisting>
|
||||
scheduler_available_filters=nova.scheduler.filters.standard_filters
|
||||
</programlisting>
|
||||
This configuration option can be specified multiple times. For example,
|
||||
if you implemented your own custom filter in Python called
|
||||
<literal>myfilter.MyFilter</literal> and you wanted to use both the
|
||||
built-in filters and your custom filter, your <filename>nova.conf</filename>
|
||||
file would contain:
|
||||
<programlisting>
|
||||
This configuration option can be specified multiple times.
|
||||
For example, if you implemented your own custom filter in
|
||||
Python called <literal>myfilter.MyFilter</literal> and you
|
||||
wanted to use both the built-in filters and your custom
|
||||
filter, your <filename>nova.conf</filename> file would
|
||||
contain:
|
||||
<programlisting>
|
||||
scheduler_available_filters=nova.scheduler.filters.standard_filters
|
||||
scheduler_available_filters=myfilter.MyFilter
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>The <literal>scheduler_default_filters</literal> configuration option
|
||||
in <filename>nova.conf</filename> defines the list of filters
|
||||
that will be applied by the <command>nova-scheduler</command> service.
|
||||
As mentioned above, the default filtes are:
|
||||
<programlisting>
|
||||
</para>
|
||||
<para>The <literal>scheduler_default_filters</literal>
|
||||
configuration option in <filename>nova.conf</filename>
|
||||
defines the list of filters that will be applied by the
|
||||
<command>nova-scheduler</command> service. As
|
||||
mentioned above, the default filters are:
|
||||
<programlisting>
|
||||
scheduler_default_filters=AvailabilityZoneFilter,RamFilter,ComputeFilter
|
||||
</programlisting>
|
||||
</para>
|
||||
</para>
|
||||
<para>The available filters are described below.</para>
|
||||
|
||||
<section xml:id="allhostsfilter">
|
||||
|
|
@ -118,10 +122,9 @@ scheduler_default_filters=AvailabilityZoneFilter,RamFilter,ComputeFilter
|
|||
<title>
|
||||
AvailabilityZoneFilter
|
||||
</title>
|
||||
<para>
|
||||
Filters hosts by availabilty zone. This filter must be enabled for
|
||||
the scheduler to respect availability zones in requests.
|
||||
</para>
|
||||
<para> Filters hosts by availability zone. This filter must be
|
||||
enabled for the scheduler to respect availability
|
||||
zones in requests. </para>
|
||||
</section>
|
||||
|
||||
<section xml:id="computefilter">
|
||||
|
|
@ -178,19 +181,21 @@ scheduler_default_filters=AvailabilityZoneFilter,RamFilter,ComputeFilter
|
|||
|
||||
<section xml:id="differenthostfilter">
|
||||
<title>DifferentHostFilter</title>
|
||||
<para>Schedule the instance on a different host from a
|
||||
set of instances. To take advantage of this filter, the requester
|
||||
must pass a scheduler hint, using <literal>different_host</literal>
|
||||
as the keyand a list of instance uuids as the value. This
|
||||
filter is the opposite of the <literal>SameHostFilter</literal>.
|
||||
Using the
|
||||
<command>nova</command> command-line tool, use the <literal>--hint</literal>
|
||||
flag. For example:
|
||||
<screen>
|
||||
<para>Schedule the instance on a different host from a set
|
||||
of instances. To take advantage of this filter, the
|
||||
requester must pass a scheduler hint, using
|
||||
<literal>different_host</literal> as the key and a
|
||||
list of instance uuids as the value. This filter is
|
||||
the opposite of the <literal>SameHostFilter</literal>.
|
||||
Using the <command>nova</command> command-line tool,
|
||||
use the <literal>--hint</literal> flag. For example:
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>nova boot --image cedef40a-ed67-4d10-800e-17455edce175 --flavor 1 --hint different_host=[a0cf03a5-d921-4877-bb5c-86d26cf818e1,8c19174f-4220-44f0-824a-cd1eeef10287] server-1</userinput>
|
||||
</screen>
|
||||
With the API, use the <literal>os:scheduler_hints</literal> key. For example:
|
||||
<programlisting language="json">
|
||||
With the API, use the
|
||||
<literal>os:scheduler_hints</literal> key. For
|
||||
example:
|
||||
<programlisting language="json">
|
||||
{
|
||||
'server': {
|
||||
'name': 'server-1',
|
||||
|
|
@ -258,17 +263,20 @@ ram_allocation_ratio=1.5
|
|||
|
||||
<section xml:id="samehostfilter">
|
||||
<title>SameHostFilter</title>
|
||||
<para>Schedule the instance on the same host as another instance
|
||||
in a set of of instances. To take advantage of this filter, the
|
||||
requester must pass a scheduler hint, using <literal>same_host</literal>
|
||||
as the key and a list of instance uuids as the value. This
|
||||
filter is the opposite of the <literal>DifferentHostFilter</literal>. Using the
|
||||
<command>nova</command> command-line tool, use the <literal>--hint</literal>
|
||||
flag:
|
||||
<screen>
|
||||
<para>Schedule the instance on the same host as another
|
||||
instance in a set of instances. To take advantage of
|
||||
this filter, the requester must pass a scheduler hint,
|
||||
using <literal>same_host</literal> as the key and a
|
||||
list of instance uuids as the value. This filter is
|
||||
the opposite of the
|
||||
<literal>DifferentHostFilter</literal>. Using the
|
||||
<command>nova</command> command-line tool, use the
|
||||
<literal>--hint</literal> flag:
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>nova boot --image cedef40a-ed67-4d10-800e-17455edce175 --flavor 1 --hint same_host=[a0cf03a5-d921-4877-bb5c-86d26cf818e1,8c19174f-4220-44f0-824a-cd1eeef10287] server-1</userinput></screen>
|
||||
With the API, use the <literal>os:scheduler_hints</literal> key:
|
||||
<programlisting>
|
||||
With the API, use the
|
||||
<literal>os:scheduler_hints</literal> key:
|
||||
<programlisting>
|
||||
{
|
||||
'server': {
|
||||
'name': 'server-1',
|
||||
|
|
@ -428,7 +436,7 @@ compute_fill_first_cost_fn_weight=-1.0
|
|||
configuration option.</para>
|
||||
</section>
|
||||
<section xml:id="simple">
|
||||
<title>Simple Scheulder</title>
|
||||
<title>Simple Scheduler</title>
|
||||
<para>The Simple Scheduler (<literal>nova.scheduler.simple.SimpleScheduler</literal>)
|
||||
implements a naive scheduler that tries to find the least loaded host
|
||||
(i.e., implements a "spread-first" algorithm). It can schedule requests
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@
|
|||
<title>Details of rootwrap.conf</title>
|
||||
<para>The <filename>rootwrap.conf</filename> file is used to influence how nova-rootwrap works.
|
||||
Since it's in the trusted security path, it needs to be owned and writeable only by the root user.
|
||||
Its location is specified both in the sudoers entry and in the <filename>nova.conf</filename> configuration file with the root_helper= entry.
|
||||
Its location is specified both in the sudoers entry and in the <filename>nova.conf</filename> configuration file with the rootwrap_config= entry.
|
||||
</para>
|
||||
<para>It uses an INI file format with the following sections and parameters: </para>
|
||||
<table rules= "all" frame= "border" xml:id= "rootwrap-conf" width= "100%">
|
||||
|
|
|
|||
|
|
@ -509,7 +509,7 @@
|
|||
it is left untouched. </para></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para> root_helper=sudo nova-rootwrap
|
||||
<td><para> rootwrap_config=sudo nova-rootwrap
|
||||
/etc/nova/rootwrap.conf</para></td>
|
||||
<td><para> (StrOpt) Command prefix to use for running
|
||||
commands as root. Note that the configuration
|
||||
|
|
|
|||
Loading…
Reference in New Issue