From cb131d00450fe06c96d441c073de8c894ee1e0a8 Mon Sep 17 00:00:00 2001 From: Ville Ojamo <14869000+bluikko@users.noreply.github.com> Date: Mon, 19 Jan 2026 20:13:10 +0700 Subject: [PATCH] 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> --- doc/cephadm/services/rgw.rst | 91 ------------------------------------ 1 file changed, 91 deletions(-) diff --git a/doc/cephadm/services/rgw.rst b/doc/cephadm/services/rgw.rst index d9f7d883dd0..6605e75f5f7 100644 --- 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=`` 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 `` - or ``ceph orch daemon redeploy `` commands - - Service specification --------------------- -- 2.47.3