doc: Revert doc/cephadm: correct markup in rgw.rst

This reverts commit fccb60922e80b0a446759ddfc8d1266b491277be.

Commit fccb609 backported changes that do not apply to Reef.
PR #63074 and the commit referenced therein as cherry-pick do not
correspond to the diff. Revert the commit because:

- Wildcard SAN feature in 3c24753 only since Tentacle.
- Disable multisite sync traffic feature in d620ba6 only since Squid.
- Shutdown delay feature in b84bb72 only since Tentacle.

Signed-off-by: Ville Ojamo <14869000+bluikko@users.noreply.github.com>

diff --git a/doc/cephadm/services/rgw.rst b/doc/cephadm/services/rgw.rst
index d9f7d883dd0aaa8307de9aee9cf1bc754090339e..6605e75f5f724c80a5386aea2aabfe04780d68ac 100644 (file)
--- a/doc/cephadm/services/rgw.rst
+++ b/doc/cephadm/services/rgw.rst
@@ -173,97 +173,6 @@ 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
 ---------------------