openstack/openstack-manuals
Code Issues Proposed changes

Merge "Applied Doc conventions in Admin-guide-cloud-2"

Browse Source
This commit is contained in:
Jenkins 2013-11-25 23:38:17 +00:00 committed by Gerrit Code Review
commit c8d9ed8001
4 changed files with 24 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
doc/admin-guide-cloud/section_multi_backend.xml
View File

@ -35,7 +35,7 @@
</note> </note>
<para>The options for a configuration group must be defined in <para>The options for a configuration group must be defined in
the group (or default options are used). All the standard the group (or default options are used). All the standard
Cinder configuration options Block Storage configuration options
(<literal>volume_group</literal>, (<literal>volume_group</literal>,
<literal>volume_driver</literal>, and so on) might be <literal>volume_driver</literal>, and so on) might be
used in a configuration group. Configuration values in the used in a configuration group. Configuration values in the
@ -69,7 +69,7 @@ volume_backend_name=LVM_iSCSI_b</programlisting>
<literal>lvmdriver-3</literal> back-end.</para> <literal>lvmdriver-3</literal> back-end.</para>
</simplesect> </simplesect>
<simplesect> <simplesect>
<title>Configure Cinder scheduler multi back-end</title> <title>Configure Block Storage scheduler multi back-end</title>
<para>You must enable the <option>filter_scheduler</option> <para>You must enable the <option>filter_scheduler</option>
option to use multi back-end. Filter scheduler acts in two option to use multi back-end. Filter scheduler acts in two
steps:</para> steps:</para>
@ -100,7 +100,7 @@ volume_backend_name=LVM_iSCSI_b</programlisting>
<filename>cinder.conf</filename> configuration <filename>cinder.conf</filename> configuration
file:</para> file:</para>
<programlisting language="ini">scheduler_driver=cinder.scheduler.filter_scheduler.FilterScheduler</programlisting> <programlisting language="ini">scheduler_driver=cinder.scheduler.filter_scheduler.FilterScheduler</programlisting>
<para>While the Cinder Scheduler defaults to <para>While the Block Storage Scheduler defaults to
<option>filter_scheduler</option> in Grizzly, this <option>filter_scheduler</option> in Grizzly, this
setting is not required.</para> setting is not required.</para>
</note> </note>
@ -109,7 +109,7 @@ volume_backend_name=LVM_iSCSI_b</programlisting>
<simplesect> <simplesect>
<title>Volume type</title> <title>Volume type</title>
<para>Before using it, a volume type has to be declared to <para>Before using it, a volume type has to be declared to
Cinder. This can be done by the following command:</para> Block Storage. This can be done by the following command:</para>
<screen><prompt>$</prompt> <userinput>cinder --os-username admin --os-tenant-name admin type-create lvm</userinput></screen> <screen><prompt>$</prompt> <userinput>cinder --os-username admin --os-tenant-name admin type-create lvm</userinput></screen>
<para>Then, an extra-specification have to be created to link <para>Then, an extra-specification have to be created to link
the volume type to a back-end name. Run this the volume type to a back-end name. Run this
@ -133,7 +133,7 @@ volume_backend_name=LVM_iSCSI_b</programlisting>
<note> <note>
<para>If a volume type points to a <para>If a volume type points to a
<literal>volume_backend_name</literal> that does <literal>volume_backend_name</literal> that does
not exist in the Cinder configuration, the not exist in the Block Storage configuration, the
<literal>filter_scheduler</literal> returns an <literal>filter_scheduler</literal> returns an
error that it cannot find a valid host with the error that it cannot find a valid host with the
suitable back-end.</para> suitable back-end.</para>

20
doc/admin-guide-cloud/section_networking_adv_features.xml
View File

@ -1732,8 +1732,8 @@
<emphasis>router</emphasis> resources.</para> <emphasis>router</emphasis> resources.</para>
<para>The back-end is polled periodically, and the <para>The back-end is polled periodically, and the
status for every resource is retrieved; then the status for every resource is retrieved; then the
status in the Neutron database is updated only for status in the Networking database is updated only
the resources for which a status change occurred. for the resources for which a status change occurred.
As operational status is now retrieved As operational status is now retrieved
asynchronously, performance for asynchronously, performance for
<literal>GET</literal> operations is <literal>GET</literal> operations is
@ -1848,11 +1848,11 @@
</tr> </tr>
</tbody> </tbody>
</table> </table>
<para>When running multiple Neutron server instances, <para>When running multiple OpenStack Networking server
the status synchronization task should not run on instances, the status synchronization task should
every node; doing so sends unnecessary traffic to not run on every node; doing so sends unnecessary
the NVP back-end and performs unnecessary DB traffic to the NVP back-end and performs unnecessary
operations. Set the DB operations. Set the
<option>state_sync_interval</option> <option>state_sync_interval</option>
configuration option to a non-zero value configuration option to a non-zero value
exclusively on a node designated for back-end exclusively on a node designated for back-end
@ -1960,9 +1960,9 @@
xml:id="section_bigswitch_routerrule_walkthrough"> xml:id="section_bigswitch_routerrule_walkthrough">
<title>Big Switch router rules operations</title> <title>Big Switch router rules operations</title>
<para>Router rules are configured with a router <para>Router rules are configured with a router
update operation in Neutron. The update update operation in OpenStack Networking. The
overrides any previous rules so all rules must update overrides any previous rules so all
be provided at the same time.</para> rules must be provided at the same time.</para>
<para>Update a router with rules to permit traffic <para>Update a router with rules to permit traffic
by default but block traffic from external by default but block traffic from external
networks to the 10.10.10.0/24 subnet:</para> networks to the 10.10.10.0/24 subnet:</para>

4
doc/admin-guide-cloud/section_object-storage-monitoring.xml
View File

@ -174,8 +174,8 @@
currently reports 124 metrics across 15 Object Storage currently reports 124 metrics across 15 Object Storage
daemons and the tempauth middleware. Details of the daemons and the tempauth middleware. Details of the
metrics tracked are in the <link metrics tracked are in the <link
xlink:href="http://swift.openstack.org/admin_guide.html" xlink:href="http://docs.openstack.org/developer/swift/admin_guide.html"
>Swift Administration Guide</link>.</para> >Administrator's Guide</link>.</para>
<para>The sending of metrics is integrated with the logging <para>The sending of metrics is integrated with the logging
framework. To enable, configure framework. To enable, configure
<code>log_statsd_host</code> in the relevant config <code>log_statsd_host</code> in the relevant config

14
doc/admin-guide-cloud/section_ts_cinder_config.xml
View File

@ -8,7 +8,7 @@
configuration</title> configuration</title>
<para>This section helps you solve some basic and common errors <para>This section helps you solve some basic and common errors
that you might encounter during setup and configuration of the that you might encounter during setup and configuration of the
Cinder Block Storage Service. The focus here is on failed Block Storage Service. The focus here is on failed
creation of volumes. The most important thing to know is where creation of volumes. The most important thing to know is where
to look in case of a failure.</para> to look in case of a failure.</para>
<para>Two log files are especially helpful for solving volume <para>Two log files are especially helpful for solving volume
@ -20,7 +20,7 @@
issues. If you send a request to create a volume and it fails, issues. If you send a request to create a volume and it fails,
review the <systemitem class="service" review the <systemitem class="service"
>cinder-api</systemitem> log to determine whether the request >cinder-api</systemitem> log to determine whether the request
made it to the Cinder service. If the request is logged made it to the Block Storage service. If the request is logged
and you see no errors or trace-backs, check the and you see no errors or trace-backs, check the
<systemitem class="service">cinder-volume</systemitem> log <systemitem class="service">cinder-volume</systemitem> log
for errors or trace-backs.</para> for errors or trace-backs.</para>
@ -106,15 +106,15 @@
<listitem> <listitem>
<para>Issues with <literal>state_path</literal> and <para>Issues with <literal>state_path</literal> and
<literal>volumes_dir</literal> settings.</para> <literal>volumes_dir</literal> settings.</para>
<para>Cinder uses <command>tgtd</command> as the default <para>The OpenStack Block Storage uses <command>tgtd</command>
iscsi helper and implements persistent targets. This as the default iscsi helper and implements persistent targets.
means that in the case of a tgt restart or even a node This means that in the case of a tgt restart or even a
reboot your existing volumes on that node will be node reboot your existing volumes on that node will be
restored automatically with their original IQN.</para> restored automatically with their original IQN.</para>
<para>In order to make this possible the iSCSI target <para>In order to make this possible the iSCSI target
information needs to be stored in a file on creation information needs to be stored in a file on creation
that can be queried in case of restart of the tgt that can be queried in case of restart of the tgt
daemon. By default, Cinder uses a daemon. By default, Block Storage uses a
<literal>state_path</literal> variable, which if <literal>state_path</literal> variable, which if
installing with Yum or APT should be set to installing with Yum or APT should be set to
<filename>/var/lib/cinder/</filename>. The next <filename>/var/lib/cinder/</filename>. The next