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>
<para>The options for a configuration group must be defined in
the group (or default options are used). All the standard
Cinder configuration options
Block Storage configuration options
(<literal>volume_group</literal>,
<literal>volume_driver</literal>, and so on) might be
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>
</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>
option to use multi back-end. Filter scheduler acts in two
steps:</para>
@ -100,7 +100,7 @@ volume_backend_name=LVM_iSCSI_b</programlisting>
<filename>cinder.conf</filename> configuration
file:</para>
<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
setting is not required.</para>
</note>
@ -109,7 +109,7 @@ volume_backend_name=LVM_iSCSI_b</programlisting>
<simplesect>
<title>Volume type</title>
<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>
<para>Then, an extra-specification have to be created to link
the volume type to a back-end name. Run this
@ -133,7 +133,7 @@ volume_backend_name=LVM_iSCSI_b</programlisting>
<note>
<para>If a volume type points to a
<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
error that it cannot find a valid host with the
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>
<para>The back-end is polled periodically, and the
status for every resource is retrieved; then the
status in the Neutron database is updated only for
the resources for which a status change occurred.
status in the Networking database is updated only
for the resources for which a status change occurred.
As operational status is now retrieved
asynchronously, performance for
<literal>GET</literal> operations is
@ -1848,11 +1848,11 @@
</tr>
</tbody>
</table>
<para>When running multiple Neutron server instances,
the status synchronization task should not run on
every node; doing so sends unnecessary traffic to
the NVP back-end and performs unnecessary DB
operations. Set the
<para>When running multiple OpenStack Networking server
instances, the status synchronization task should
not run on every node; doing so sends unnecessary
traffic to the NVP back-end and performs unnecessary
DB operations. Set the
<option>state_sync_interval</option>
configuration option to a non-zero value
exclusively on a node designated for back-end
@ -1960,9 +1960,9 @@
xml:id="section_bigswitch_routerrule_walkthrough">
<title>Big Switch router rules operations</title>
<para>Router rules are configured with a router
update operation in Neutron. The update
overrides any previous rules so all rules must
be provided at the same time.</para>
update operation in OpenStack Networking. The
update overrides any previous rules so all
rules must be provided at the same time.</para>
<para>Update a router with rules to permit traffic
by default but block traffic from external
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
daemons and the tempauth middleware. Details of the
metrics tracked are in the <link
xlink:href="http://swift.openstack.org/admin_guide.html"
>Swift Administration Guide</link>.</para>
xlink:href="http://docs.openstack.org/developer/swift/admin_guide.html"
>Administrator's Guide</link>.</para>
<para>The sending of metrics is integrated with the logging
framework. To enable, configure
<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>
<para>This section helps you solve some basic and common errors
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
to look in case of a failure.</para>
<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,
review the <systemitem class="service"
>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
<systemitem class="service">cinder-volume</systemitem> log
for errors or trace-backs.</para>
@ -106,15 +106,15 @@
<listitem>
<para>Issues with <literal>state_path</literal> and
<literal>volumes_dir</literal> settings.</para>
<para>Cinder uses <command>tgtd</command> as the default
iscsi helper and implements persistent targets. This
means that in the case of a tgt restart or even a node
reboot your existing volumes on that node will be
<para>The OpenStack Block Storage uses <command>tgtd</command>
as the default iscsi helper and implements persistent targets.
This means that in the case of a tgt restart or even a
node reboot your existing volumes on that node will be
restored automatically with their original IQN.</para>
<para>In order to make this possible the iSCSI target
information needs to be stored in a file on creation
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
installing with Yum or APT should be set to
<filename>/var/lib/cinder/</filename>. The next