Merge pull request #45887 from bluikko/patch-3

doc: replace spaces with underscores in config option names

Reviewed-by: Anthony D'Atri <anthony.datri@gmail.com>
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>

doc/rados/api/librados-intro.rst

@@ -205,10 +205,10 @@ app must supply a monitor address, a username and an authentication key
 RADOS provides a number of ways for you to set the required values. For
 the monitor and encryption key settings, an easy way to handle them is to ensure
 that your Ceph configuration file contains a ``keyring`` path to a keyring file
-and at least one monitor address (e.g., ``mon host``). For example::
+and at least one monitor address (e.g., ``mon_host``). For example::
 
 	[global]
-	mon host = 192.168.1.1
+	mon_host = 192.168.1.1
 	keyring = /etc/ceph/ceph.client.admin.keyring
 
 Once you create the handle, you can read a Ceph configuration file to configure

doc/rados/api/python.rst

@@ -114,7 +114,7 @@ configuration file example uses the ``client.admin`` keyring.
 
 	[global]
 	# ... elided configuration
-	keyring=/path/to/keyring/ceph.client.admin.keyring
+	keyring = /path/to/keyring/ceph.client.admin.keyring
 
 
 Manage Pools

doc/rados/configuration/demo-ceph.conf

@@ -1,6 +1,6 @@
 [global]
 fsid = {cluster-id}
-mon_initial_ members = {hostname}[, {hostname}]
+mon_initial_members = {hostname}[, {hostname}]
 mon_host = {ip-address}[, {ip-address}]
 
 #All clusters have a front-side public network.
@@ -19,13 +19,13 @@ auth_client_required = cephx
 #and placement groups.
 osd_journal_size = {n}
 osd_pool_default_size = {n}  # Write an object n times.
-osd_pool_default_min size = {n} # Allow writing n copy in a degraded state.
-osd_pool_default_pg num = {n}
-osd_pool_default_pgp num = {n}
+osd_pool_default_min_size = {n} # Allow writing n copy in a degraded state.
+osd_pool_default_pg_num = {n}
+osd_pool_default_pgp_num = {n}
 
 #Choose a reasonable crush leaf type.
 #0 for a 1-node cluster.
 #1 for a multi node cluster in a single rack
 #2 for a multi node, multi chassis cluster with multiple hosts in a chassis
 #3 for a multi node cluster with hosts across racks, etc.
-osd_crush_chooseleaf_type = {n}
+osd_crush_chooseleaf_type = {n}

doc/rados/configuration/filestore-config-ref.rst

@@ -5,7 +5,7 @@
 The Filestore back end is no longer the default when creating new OSDs,
 though Filestore OSDs are still supported.
 
-``filestore debug omap check``
+``filestore_debug_omap_check``
 
 :Description: Debugging check on synchronization. Expensive. For debugging only.
 :Type: Boolean

doc/rados/configuration/mon-config-ref.rst

@@ -207,13 +207,13 @@ these under ``[mon]`` or under the entry for a specific monitor.
 .. code-block:: ini
 
 	[global]
-		mon host = 10.0.0.2,10.0.0.3,10.0.0.4
+		mon_host = 10.0.0.2,10.0.0.3,10.0.0.4
 
 .. code-block:: ini
 
 	[mon.a]
 		host = hostname1
-		mon addr = 10.0.0.10:6789
+		mon_addr = 10.0.0.10:6789
 
 See the `Network Configuration Reference`_ for details.
 

doc/rados/configuration/network-config-ref.rst

@@ -257,8 +257,8 @@ configuration option.  For example,
 .. code-block:: ini
 
 	[osd.0]
-		public addr = {host-public-ip-address}
-		cluster addr = {host-cluster-ip-address}
+		public_addr = {host-public-ip-address}
+		cluster_addr = {host-cluster-ip-address}
 
 .. topic:: One NIC OSD in a Two Network Cluster
 

doc/rados/configuration/pool-pg.conf

@@ -5,10 +5,10 @@
 	# copies--reset the default values as shown in 'osd_pool_default_size'.
 	# If you want to allow Ceph to accept an I/O operation to a degraded PG,
 	# set 'osd_pool_default_min_size' to a number less than the
-	# 'osd pool default size' value.
+	# 'osd_pool_default_size' value.
 
 	osd_pool_default_size = 3  # Write an object 3 times.
-	osd_pool_default_min size = 2 # Accept an I/O operation to a PG that has two copies of an object.
+	osd_pool_default_min_size = 2 # Accept an I/O operation to a PG that has two copies of an object.
 
 	# Ensure you have a realistic number of placement groups. We recommend
 	# approximately 100 per OSD. E.g., total number of OSDs multiplied by 100

doc/rados/operations/crush-map.rst

@@ -896,7 +896,7 @@ To make this warning go away, you have two options:
 2. You can make the warning go away without making any changes to CRUSH by
    adding the following option to your ceph.conf ``[mon]`` section::
 
-      mon warn on legacy crush tunables = false
+      mon_warn_on_legacy_crush_tunables = false
 
    For the change to take effect, you will need to restart the monitors, or
    apply the option to running monitors with::

doc/rados/operations/monitoring-osd-pg.rst

@@ -24,7 +24,7 @@ Monitoring OSDs
 An OSD's status is either in the cluster (``in``) or out of the cluster
 (``out``); and, it is either up and running (``up``), or it is down and not
 running (``down``). If an OSD is ``up``, it may be either ``in`` the cluster
-(you can read and write data) or it is ``out`` of the cluster.  If it was
+(you can read and write data) or it is ``out`` of the cluster. If it was
 ``in`` the cluster and recently moved ``out`` of the cluster, Ceph will migrate
 placement groups to other OSDs. If an OSD is ``out`` of the cluster, CRUSH will
 not assign placement groups to the OSD. If an OSD is ``down``, it should also be
@@ -53,7 +53,7 @@ not assign placement groups to the OSD. If an OSD is ``down``, it should also be
 If you execute a command such as ``ceph health``, ``ceph -s`` or ``ceph -w``,
 you may notice that the cluster does not always echo back ``HEALTH OK``. Don't
 panic. With respect to OSDs, you should expect that the cluster will **NOT**
-echo   ``HEALTH OK`` in a few expected circumstances:
+echo ``HEALTH OK`` in a few expected circumstances:
 
 #. You haven't started the cluster yet (it won't respond).
 #. You have just started or restarted the cluster and it's not ready yet,
@@ -143,7 +143,7 @@ group, execute::
 	ceph pg map {pg-num}
 
 The result should tell you the osdmap epoch (eNNN), the placement group number
-({pg-num}),  the OSDs in the Up Set (up[]), and the OSDs in the acting set
+({pg-num}), the OSDs in the Up Set (up[]), and the OSDs in the acting set
 (acting[]). ::
 
 	osdmap eNNN pg {raw-pg-num} ({pg-num}) -> up [0,1,2] acting [0,1,2]
@@ -157,7 +157,7 @@ Peering
 =======
 
 Before you can write data to a placement group, it must be in an ``active``
-state, and it  **should** be in a ``clean`` state. For Ceph to determine the
+state, and it **should** be in a ``clean`` state. For Ceph to determine the
 current state of a placement group, the primary OSD of the placement group
 (i.e., the first OSD in the acting set), peers with the secondary and tertiary
 OSDs to establish agreement on the current state of the placement group
@@ -171,14 +171,14 @@ OSDs to establish agreement on the current state of the placement group
            +---------+     +---------+     +-------+
                 |               |              |
                 |  Request To   |              |
-                |     Peer      |              |             
+                |     Peer      |              |
                 |-------------->|              |
                 |<--------------|              |
                 |    Peering                   |
                 |                              |
                 |         Request To           |
                 |            Peer              | 
-                |----------------------------->|  
+                |----------------------------->|
                 |<-----------------------------|
                 |          Peering             |
 
@@ -267,7 +267,7 @@ Creating
 --------
 
 When you create a pool, it will create the number of placement groups you
-specified.  Ceph will echo ``creating`` when it is creating one or more
+specified. Ceph will echo ``creating`` when it is creating one or more
 placement groups. Once they are created, the OSDs that are part of a placement
 group's Acting Set will peer. Once peering is complete, the placement group
 status should be ``active+clean``, which means a Ceph client can begin writing
@@ -308,7 +308,7 @@ Active
 
 Once Ceph completes the peering process, a placement group may become
 ``active``. The ``active`` state means that the data in the placement group is
-generally  available in the primary placement group and the replicas for read
+generally available in the primary placement group and the replicas for read
 and write operations. 
 
 
@@ -339,7 +339,7 @@ still write a new object to a ``degraded`` placement group if it is ``active``.
 If an OSD is ``down`` and the ``degraded`` condition persists, Ceph may mark the
 ``down`` OSD as ``out`` of the cluster and remap the data from the ``down`` OSD
 to another OSD. The time between being marked ``down`` and being marked ``out``
-is controlled by ``mon osd down out interval``, which is set to ``600`` seconds
+is controlled by ``mon_osd_down_out_interval``, which is set to ``600`` seconds
 by default.
 
 A placement group can also be ``degraded``, because Ceph cannot find one or more
@@ -361,19 +361,19 @@ state.
 Recovery is not always trivial, because a hardware failure might cause a
 cascading failure of multiple OSDs. For example, a network switch for a rack or
 cabinet may fail, which can cause the OSDs of a number of host machines to fall
-behind the current state  of the cluster. Each one of the OSDs must recover once
+behind the current state of the cluster. Each one of the OSDs must recover once
 the fault is resolved.
 
 Ceph provides a number of settings to balance the resource contention between
 new service requests and the need to recover data objects and restore the
-placement groups to the current state. The ``osd recovery delay start`` setting
+placement groups to the current state. The ``osd_recovery_delay_start`` setting
 allows an OSD to restart, re-peer and even process some replay requests before
-starting the recovery process.  The ``osd
-recovery thread timeout`` sets a thread timeout, because multiple OSDs may fail,
-restart and re-peer at staggered rates. The ``osd recovery max active`` setting
-limits the  number of recovery requests an OSD will entertain simultaneously to
-prevent the OSD from failing to serve . The ``osd recovery max chunk`` setting
-limits the size of the recovered data chunks to prevent network congestion.
+starting the recovery process. The ``osd_recovery_thread_timeout`` sets a thread
+timeout, because multiple OSDs may fail, restart and re-peer at staggered rates.
+The ``osd_recovery_max_active`` setting limits the number of recovery requests
+an OSD will entertain simultaneously to prevent the OSD from failing to serve.
+The ``osd_recovery_max_chunk`` setting limits the size of the recovered data
+chunks to prevent network congestion.
 
 
 Back Filling
@@ -383,7 +383,7 @@ When a new OSD joins the cluster, CRUSH will reassign placement groups from OSDs
 in the cluster to the newly added OSD. Forcing the new OSD to accept the
 reassigned placement groups immediately can put excessive load on the new OSD.
 Back filling the OSD with the placement groups allows this process to begin in
-the background.  Once backfilling is complete, the new OSD will begin serving
+the background. Once backfilling is complete, the new OSD will begin serving
 requests when it is ready.
 
 During the backfill operations, you may see one of several states:
@@ -393,20 +393,20 @@ and, ``backfill_toofull`` indicates that a backfill operation was requested,
 but couldn't be completed due to insufficient storage capacity. When a 
 placement group cannot be backfilled, it may be considered ``incomplete``.
 
-The ``backfill_toofull`` state may be transient.  It is possible that as PGs
-are moved around, space may become available.  The ``backfill_toofull`` is
+The ``backfill_toofull`` state may be transient. It is possible that as PGs
+are moved around, space may become available. The ``backfill_toofull`` is
 similar to ``backfill_wait`` in that as soon as conditions change
 backfill can proceed.
 
 Ceph provides a number of settings to manage the load spike associated with
 reassigning placement groups to an OSD (especially a new OSD). By default,
 ``osd_max_backfills`` sets the maximum number of concurrent backfills to and from
-an OSD to 1. The ``backfill full ratio`` enables an OSD to refuse a
+an OSD to 1. The ``backfill_full_ratio`` enables an OSD to refuse a
 backfill request if the OSD is approaching its full ratio (90%, by default) and
 change with ``ceph osd set-backfillfull-ratio`` command.
-If an OSD refuses a backfill request, the ``osd backfill retry interval``
+If an OSD refuses a backfill request, the ``osd_backfill_retry_interval``
 enables an OSD to retry the request (after 30 seconds, by default). OSDs can
-also set ``osd backfill scan min`` and ``osd backfill scan max`` to manage scan
+also set ``osd_backfill_scan_min`` and ``osd_backfill_scan_max`` to manage scan
 intervals (64 and 512, by default).
 
 
@@ -416,7 +416,7 @@ Remapped
 When the Acting Set that services a placement group changes, the data migrates
 from the old acting set to the new acting set. It may take some time for a new
 primary OSD to service requests. So it may ask the old primary to continue to
-service requests until the placement group migration is complete. Once  data
+service requests until the placement group migration is complete. Once data
 migration completes, the mapping uses the primary OSD of the new acting set.
 
 
@@ -427,7 +427,7 @@ While Ceph uses heartbeats to ensure that hosts and daemons are running, the
 ``ceph-osd`` daemons may also get into a ``stuck`` state where they are not
 reporting statistics in a timely manner (e.g., a temporary network fault). By
 default, OSD daemons report their placement group, up through, boot and failure
-statistics every half second (i.e., ``0.5``),  which is more frequent than the
+statistics every half second (i.e., ``0.5``), which is more frequent than the
 heartbeat thresholds. If the **Primary OSD** of a placement group's acting set
 fails to report to the monitor or if other OSDs have reported the primary OSD
 ``down``, the monitors will mark the placement group ``stale``.
@@ -453,7 +453,7 @@ include:
   are waiting for an OSD with the most up-to-date data to come back ``up``.
 - **Stale**: Placement groups are in an unknown state, because the OSDs that 
   host them have not reported to the monitor cluster in a while (configured 
-  by ``mon osd report timeout``).
+  by ``mon_osd_report_timeout``).
 
 To identify stuck placement groups, execute the following:: 
 
@@ -484,7 +484,7 @@ location, all you need is the object name and the pool name. For example::
 	test file containing some object data and a pool name using the 
 	``rados put`` command on the command line. For example::
    
-		rados put {object-name} {file-path} --pool=data   	
+		rados put {object-name} {file-path} --pool=data
 		rados put test-object-1 testfile.txt --pool=data
    
 	To verify that the Ceph Object Store stored the object, execute the following::
@@ -508,7 +508,7 @@ location, all you need is the object name and the pool name. For example::
 
 As the cluster evolves, the object location may change dynamically. One benefit
 of Ceph's dynamic rebalancing is that Ceph relieves you from having to perform
-the migration manually. See the  `Architecture`_ section for details.
+the migration manually. See the `Architecture`_ section for details.
 
 .. _data placement: ../data-placement
 .. _pool: ../pools

doc/rados/troubleshooting/log-and-debug.rst

@@ -74,22 +74,22 @@ particular daemons are set under the daemon section in your configuration file
 .. code-block:: ini
 
 	[global]
-		debug ms = 1/5
+		debug_ms = 1/5
 		
 	[mon]
-		debug mon = 20
-		debug paxos = 1/5
-		debug auth = 2
+		debug_mon = 20
+		debug_paxos = 1/5
+		debug_auth = 2
 		 
  	[osd]
- 		debug osd = 1/5
- 		debug filestore = 1/5
- 		debug journal = 1
- 		debug monc = 5/20
+ 		debug_osd = 1/5
+ 		debug_filestore = 1/5
+ 		debug_journal = 1
+ 		debug_monc = 5/20
  		
 	[mds]
-		debug mds = 1
-		debug mds balancer = 1
+		debug_mds = 1
+		debug_mds_balancer = 1
 
 
 See `Subsystem, Log and Debug Settings`_ for details.

doc/rados/troubleshooting/troubleshooting-mon.rst

@@ -557,8 +557,8 @@ related to your issue. This may not be an easy task for someone unfamiliar
 with troubleshooting Ceph. For most situations, setting the following options
 on your monitors will be enough to pinpoint a potential source of the issue::
 
-      debug mon = 10
-      debug ms = 1
+      debug_mon = 10
+      debug_ms = 1
 
 If we find that these debug levels are not enough, there's a chance we may
 ask you to raise them or even define other debug subsystems to obtain infos

doc/rados/troubleshooting/troubleshooting-osd.rst

@@ -243,9 +243,9 @@ No Free Drive Space
 
 Ceph prevents you from writing to a full OSD so that you don't lose data.
 In an operational cluster, you should receive a warning when your cluster's OSDs
-and pools approach the full ratio. The ``mon osd full ratio`` defaults to
+and pools approach the full ratio. The ``mon_osd_full_ratio`` defaults to
 ``0.95``, or 95% of capacity before it stops clients from writing data.
-The ``mon osd backfillfull ratio`` defaults to ``0.90``, or 90 % of
+The ``mon_osd_backfillfull_ratio`` defaults to ``0.90``, or 90 % of
 capacity above which backfills will not start. The
 OSD nearfull ratio defaults to ``0.85``, or 85% of capacity
 when it generates a health warning.
@@ -456,7 +456,7 @@ Blocked Requests or Slow Requests
 
 If a ``ceph-osd`` daemon is slow to respond to a request, messages will be logged
 noting ops that are taking too long.  The warning threshold
-defaults to 30 seconds and is configurable via the ``osd op complaint time``
+defaults to 30 seconds and is configurable via the ``osd_op_complaint_time``
 setting.  When this happens, the cluster log will receive messages.
 
 Legacy versions of Ceph complain about ``old requests``::
@@ -589,7 +589,7 @@ You can clear the flags with::
 Two other flags are supported, ``noin`` and ``noout``, which prevent
 booting OSDs from being marked ``in`` (allocated data) or protect OSDs
 from eventually being marked ``out`` (regardless of what the current value for
-``mon osd down out interval`` is).
+``mon_osd_down_out_interval`` is).
 
 .. note:: ``noup``, ``noout``, and ``nodown`` are temporary in the
    sense that once the flags are cleared, the action they were blocking