doc/cephadm: correct markup in rgw.rst

Correct the presentation of an example string in doc/cephadm/rgw.rst in
order to obviate an error reading "rgw.rst:202: WARNING: Inline emphasis start-string without end-string."

Signed-off-by: Zac Dover <zac.dover@proton.me>
(cherry picked from commit 64bb1cffe3dd2fc495f9f4ddab1dc6c512eda624)

diff --git a/doc/cephadm/services/rgw.rst b/doc/cephadm/services/rgw.rst
index 6605e75f5f724c80a5386aea2aabfe04780d68ac..d9f7d883dd0aaa8307de9aee9cf1bc754090339e 100644 (file)
--- a/doc/cephadm/services/rgw.rst
+++ b/doc/cephadm/services/rgw.rst
@@ -173,6 +173,97 @@ Then apply this yaml document:
 Note the value of ``rgw_frontend_ssl_certificate`` is a literal string as
 indicated by a ``|`` character preserving newline characters.
 
+Setting up HTTPS with Wildcard SANs
+-----------------------------------
+
+To enable HTTPS for RGW services, apply a spec file following this scheme:
+
+.. code-block:: yaml
+
+  service_type: rgw
+  service_id: foo
+  placement:
+    label: rgw
+    count_per_host: 1
+  spec:
+    ssl: true
+    generate_cert: true  
+    rgw_frontend_port: 8080
+    wildcard_enabled: true  # Enables wildcard SANs in the certificate
+    zonegroup_hostnames:
+    - s3.cephlab.com
+
+Then apply this yaml document:
+
+.. prompt:: bash #
+
+  ceph orch apply -i myrgw.yaml
+
+The ``wildcard_enabled`` flag ensures that a wildcard SAN entry is included in the self-signed certificate,
+allowing access to buckets in virtual host mode. By default, this flag is disabled.
+example: wildcard SAN - (``*.s3.cephlab.com``)
+
+Disabling multisite sync traffic
+--------------------------------
+
+There is an RGW config option called ``rgw_run_sync_thread`` that tells the
+RGW daemon to not transmit multisite replication data. This is useful if you want
+that RGW daemon to be dedicated to I/O rather than multisite sync operations.
+The RGW spec file includes a setting ``disable_multisite_sync_traffic`` that when
+set to "True" will tell cephadm to set ``rgw_run_sync_thread`` to false for all
+RGW daemons deployed for that RGW service. For example
+
+.. code-block:: yaml
+
+    service_type: rgw
+    service_id: foo
+    placement:
+      label: rgw
+    spec:
+      rgw_realm: myrealm
+      rgw_zone: myzone
+      rgw_zonegroup: myzg
+      disable_multisite_sync_traffic: True
+
+.. note:: This will only stop the RGW daemon(s) from sending replication data.
+    The daemon can still receive replication data unless it has been removed
+    from the zonegroup and zone replication endpoints.
+
+Draining client connections on shutdown
+---------------------------------------
+
+When an RGW daemon is stopped by for any reason, including during the cephadm upgrade process,
+RGW offers a setting to delay shutdown as the RGW daemon attempts to complete ongoing
+client requests. This setting is off by default but activated manually by either passing
+``--stop-timeout=<timeout-in-seconds>`` to the RGW process or by setting the
+``rgw_exit_timeout_secs`` config option for the RGW daemon. This value may be configured in
+the RGW service spec file by specifying the ``rgw_exit_timeout_secs`` parameter in the spec
+file. For example
+
+.. code-block:: yaml
+
+    service_type: rgw
+    service_id: foo
+    placement:
+      label: rgw
+    spec:
+      rgw_realm: myrealm
+      rgw_zone: myzone
+      rgw_zonegroup: myzg
+      rgw_exit_timeout_secs: 120
+
+would tell the RGW daemons cephadm deploys for the rgw.foo service to wait up to 120
+seconds for current client requests to complete. Note that the RGW daemon will refuse
+new client requests during this time.
+
+.. note:: In cephadm deployments this setting defaults to on and 120 seconds. If you would
+    like to disable this feature you must set ``rgw_exit_timeout_secs`` to 0 in the spec
+
+.. note:: Modifications to this setting in the spec will not be picked up by the RGW daemons
+    in the service until they are redeployed using either the ``ceph orch redeploy <service-name>``
+    or ``ceph orch daemon redeploy <daemon-name>`` commands
+
+
 Service specification
 ---------------------