Joshua Hoblitt bf00821056 ci: make rgw-multisite-testing wait for multisite readiness
The rgw-multisite-testing canary job has been chronically flaky
(roughly a third of recent canary runs, including on master and
release branches). Job logs and collected artifacts show two recurring
mechanisms, neither of which is addressed by bumping timeouts:

1. Every recent failure of the "write an object" step died within
   ~16s: the very first "s3cmd mb" against the primary zone got
   ECONNREFUSED three times across the 10s retry window. The RGW
   process never crashed; RGWs pause their HTTP frontends to reload
   the realm whenever the RGW configuration period changes ("rgw
   realm reloader: Pausing frontends for realm update..."), which
   keeps happening shortly after the second zone joins the zonegroup,
   exactly when the test starts writing. While paused, the readiness
   probe also times out, the endpoint is removed from the Service, and
   connections to the ClusterIP are refused.

2. The "kubectl wait --for=condition=available deployment/..."
   barrier added previously is a no-op for these deployments: with one
   replica and maxUnavailable=1, the availability threshold is zero
   ready pods, so the condition is always true.

Changes:

- Wait on RGW pod readiness instead of deployment availability.
- Add a "wait for multisite sync to be established" step that polls
  "radosgw-admin sync status" on both clusters until metadata and
  data sync report caught up, mirroring the checkpoints ceph's own
  multisite QA performs before asserting replication.
- Probe both RGW endpoints over HTTP until several consecutive
  requests succeed before writing, to ride out realm-reload pauses.
- Replace the fixed 3-attempt s3cmd retries with time-budgeted
  retries.
- Replace the s3cmd read polling loop and its SIGUSR1 timer (which was
  never cancelled on success, silently shrinking the second
  direction's time budget) with "radosgw-admin bucket sync
  checkpoint", the marker-based barrier used by ceph QA, followed by
  a single get and diff.
- Dump multisite diagnostics (pod state, RGW logs, sync status,
  period) when the job fails.

Signed-off-by: Joshua Hoblitt <josh@hoblitt.com>
2026-06-10 15:42:51 -07:00
2026-02-26 12:00:38 +01:00
2026-04-29 14:24:26 -06:00
2018-01-29 20:38:41 -08:00
2026-04-24 11:49:22 -06:00
2016-11-07 17:13:39 -08:00
2016-11-07 17:13:39 -08:00
2024-03-06 23:17:45 +05:30
2026-04-02 13:19:21 -07:00
2026-03-23 11:48:42 -06:00
2022-02-19 20:32:01 +09:00

Rook

CNCF Status GitHub release Docker Pulls Go Report Card OpenSSF Scorecard CII Best Practices Security scanning Slack Twitter Follow

What is Rook?

Rook is an open source cloud-native storage orchestrator for Kubernetes, providing the platform, framework, and support for Ceph storage to natively integrate with Kubernetes.

Ceph is a distributed storage system that provides file, block and object storage and is deployed in large scale production clusters.

Rook automates deployment and management of Ceph to provide self-managing, self-scaling, and self-healing storage services. The Rook operator does this by building on Kubernetes resources to deploy, configure, provision, scale, upgrade, and monitor Ceph.

The status of the Ceph storage provider is Stable. Features and improvements will be planned for many future versions. Upgrades between versions are provided to ensure backward compatibility between releases.

Rook is hosted by the Cloud Native Computing Foundation (CNCF) as a graduated level project. If you are a company that wants to help shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented, consider joining the CNCF. For details about who's involved and how Rook plays a role, read the CNCF announcement.

Getting Started and Documentation

For installation, deployment, and administration, see our Documentation and QuickStart Guide.

Contributing

We welcome contributions. See Contributing to get started.

Report a Bug

For filing bugs, suggesting improvements, or requesting new features, please open an issue.

Reporting Security Vulnerabilities

If you find a vulnerability or a potential vulnerability in Rook please let us know immediately at cncf-rook-security@lists.cncf.io. We'll send a confirmation email to acknowledge your report, and we'll send an additional email when we've identified the issues positively or negatively.

For further details, please see the complete security release process.

Contact

Please use the following to reach members of the community:

Community Meeting

A regular community meeting takes place the 2nd Tuesday of every month at 9:00 AM PT (Pacific Time). Convert to your local timezone.

Any changes to the meeting schedule will be added to the agenda doc and posted to Slack #announcements.

Anyone who wants to discuss the direction of the project, design and implementation reviews, or general questions with the broader community is welcome and encouraged to join.

Official Releases

Official releases of Rook can be found on the releases page. Please note that it is strongly recommended that you use official releases of Rook, as unreleased versions from the master branch are subject to changes and incompatibilities that will not be supported in the official releases. Builds from the master branch can have functionality changed and even removed at any time without compatibility support and without prior notice.

Licensing

Rook is under the Apache 2.0 license.

FOSSA Status

S
Description
This fork holds my modifications to the rook example configs as they are applied to my cluster
Readme Apache-2.0
175 MiB
0 Stars 1 Watchers 0 Forks
Languages
Go 93.9%
Shell 3.2%
Python 1.8%
Makefile 0.8%
Go Template 0.2%