Remove duplicate text from Cinder Troubleshooting

Both section_ts_cinder_config.xml and
section_block_storage_troubleshooting.xml contained the same initial
paragraphs but differences in the rest.

The extra table and text from section_block_storage_troubleshooting.xml has been
moved to section_ts_cinder_config.xml.

section_block_storage_troubleshooting.xml is now obsolete.

Also, fix some typos.

Change-Id: Ife61dbc2bcb9f3a6fa78a8147fee6cfb2e3dfb7f
This commit is contained in:
Andreas Jaeger
2013-10-24 21:11:29 +02:00
parent 3abf45963f
commit 81a023e8a1
3 changed files with 77 additions and 94 deletions

View File

@@ -118,9 +118,8 @@
</section>
<section xml:id="troubleshooting-cinder-install">
<title>Troubleshooting your installation</title>
<para>This section contains a few useful tips for troubleshoting
your Block Storage installation</para>
<xi:include href="section_block_storage_troubleshooting.xml"/>
<para>This section contains a few useful tips for troubleshooting
your Block Storage installation.</para>
<xi:include href="section_ts_cinder_config.xml"/>
<xi:include href="section_ts_multipath_warn.xml"/>
<xi:include href="section_ts_vol_attach_miss_sg_scan.xml"/>

View File

@@ -1,90 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<section xml:id="section_block_storage_troubleshooting" xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0">
<title xml:id="block_storage_troubleshooting">Troubleshooting OpenStack Block Storage</title>
<section xml:id="ts-general-issues">
<title>General Troubleshooting Guidelines</title>
<para>There are two log files that are especially helpful for solving volume creation
failures, the <systemitem class="service">cinder-api</systemitem> log and the
<systemitem class="service">cinder-volume</systemitem> log. The <systemitem
class="service">cinder-api</systemitem> log is useful for determining if you have
endpoint or connectivity issues. If you send a request to create a volume and it fails,
it's a good idea to look in the <systemitem class="service">cinder-api</systemitem> log
first and see if the request even made it to the Cinder service. If the request is
logged and there are no errors or trace-backs, then you can check the <systemitem
class="service">cinder-volume</systemitem> log for errors or trace-backs.</para>
<para>The following entries in the <filename>cinder.openstack.common.log</filename> file can
be used to assist in troubleshooting your block storage configuration.</para>
<para>
<programlisting language="ini">
# Print debugging output (set logging level to DEBUG instead
# of default WARNING level). (boolean value)
#debug=false
# Print more verbose output (set logging level to INFO instead
# of default WARNING level). (boolean value)
#verbose=false
# Log output to standard error (boolean value)
#use_stderr=true
# Default file mode used when creating log files (string
# value)
#logfile_mode=0644
# format string to use for log messages with context (string
# value)
#logging_context_format_string=%(asctime)s.%(msecs)03d %(levelname)s %(name)s [%(request_id)s %(user)s %(tenant)s] %(instance)s%(message)s
# format string to use for log mes #logging_default_format_string=%(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [-] %(instance)s%(message)s
# data to append to log format when level is DEBUG (string
# value)
#logging_debug_format_suffix=%(funcName)s %(pathname)s:%(lineno)d
# prefix each line of exception output with this format
# (string value)
#logging_exception_prefix=%(asctime)s.%(msecs)03d %(process)d TRACE %(name)s %(instance)s
# list of logger=LEVEL pairs (list value)
#default_log_levels=amqplib=WARN,sqlalchemy=WARN,boto=WARN,suds=INFO,keystone=INFO,eventlet.wsgi.server=WARNsages without context
# (string value)
# If an instance is passed with the log message, format it
# like this (string value)
#instance_format="[instance: %(uuid)s]"
# If an instance UUID is passed with the log message, format
# it like this (string value)
# A logging.Formatter log message format string which may use
# any of the available logging.LogRecord attributes. Default:
# %(default)s (string value)
#log_format=%(asctime)s %(levelname)8s [%(name)s] %(message)s
# Format string for %%(asctime)s in log records. Default:
# %(default)s (string value)
#log_date_format=%Y-%m-%d %H:%M:%S
# (Optional) Name of log file to output to. If not set,
# logging will go to stdout. (string value)
#log_file=&lt;None>
# (Optional) The directory to keep log files in (will be
# prepended to --log-file) (string value)
#log_dir=&lt;None>
#instance_uuid_format="[instance: %(uuid)s]"
# If this option is specified, the logging configuration file
# specified is used and overrides any other logging options
# specified. Please see the Python logging module
# documentation for details on logging configuration files.
# (string value) # Use syslog for logging. (boolean value)
#use_syslog=false
# syslog facility to receive log lines (string value)
#syslog_log_facility=LOG_USER
#log_config=&lt;None></programlisting>
</para>
</section>
</section>

View File

@@ -22,12 +22,86 @@
>cinder-api</systemitem> log.</para>
</note>
</para>
<para>The following entries in the <filename>cinder.openstack.common.log</filename> file can
be used to assist in troubleshooting your block storage configuration.</para>
<para>
<programlisting language="ini">
# Print debugging output (set logging level to DEBUG instead
# of default WARNING level). (boolean value)
#debug=false
# Print more verbose output (set logging level to INFO instead
# of default WARNING level). (boolean value)
#verbose=false
# Log output to standard error (boolean value)
#use_stderr=true
# Default file mode used when creating log files (string
# value)
#logfile_mode=0644
# format string to use for log messages with context (string
# value)
#logging_context_format_string=%(asctime)s.%(msecs)03d %(levelname)s %(name)s [%(request_id)s %(user)s %(tenant)s] %(instance)s%(message)s
# format string to use for log mes #logging_default_format_string=%(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [-] %(instance)s%(message)s
# data to append to log format when level is DEBUG (string
# value)
#logging_debug_format_suffix=%(funcName)s %(pathname)s:%(lineno)d
# prefix each line of exception output with this format
# (string value)
#logging_exception_prefix=%(asctime)s.%(msecs)03d %(process)d TRACE %(name)s %(instance)s
# list of logger=LEVEL pairs (list value)
#default_log_levels=amqplib=WARN,sqlalchemy=WARN,boto=WARN,suds=INFO,keystone=INFO,eventlet.wsgi.server=WARNsages without context
# (string value)
# If an instance is passed with the log message, format it
# like this (string value)
#instance_format="[instance: %(uuid)s]"
# If an instance UUID is passed with the log message, format
# it like this (string value)
# A logging.Formatter log message format string which may use
# any of the available logging.LogRecord attributes. Default:
# %(default)s (string value)
#log_format=%(asctime)s %(levelname)8s [%(name)s] %(message)s
# Format string for %%(asctime)s in log records. Default:
# %(default)s (string value)
#log_date_format=%Y-%m-%d %H:%M:%S
# (Optional) Name of log file to output to. If not set,
# logging will go to stdout. (string value)
#log_file=&lt;None>
# (Optional) The directory to keep log files in (will be
# prepended to --log-file) (string value)
#log_dir=&lt;None>
#instance_uuid_format="[instance: %(uuid)s]"
# If this option is specified, the logging configuration file
# specified is used and overrides any other logging options
# specified. Please see the Python logging module
# documentation for details on logging configuration files.
# (string value) # Use syslog for logging. (boolean value)
#use_syslog=false
# syslog facility to receive log lines (string value)
#syslog_log_facility=LOG_USER
#log_config=&lt;None></programlisting>
</para>
<para>Here are some common issues discovered during configuration, and some suggested solutions
.</para>
<para>
<itemizedlist>
<listitem>
<para>Isusues with <literal>state_path</literal> and <literal>volumes_dir</literal>
<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