feat: rgw replication status - #821
Conversation
55d782d to
a5a4af2
Compare
The request struct every rgw replication verb travels in, and the response types for site scoped status. It carries only what the implemented verbs read. The later verbs each bring their own fields when they land, so nothing here describes a shape no code fills in. Assisted-by: claude-code:claude-opus-5 Signed-off-by: John Ramsden <john.ramsden@canonical.com>
The handler reads the local multisite topology and derives the resource state from it, live, with no database read: a secondary cluster stores no replication state of its own. Every verb returns not implemented for now. Assisted-by: claude-code:claude-opus-5 Signed-off-by: John Ramsden <john.ramsden@canonical.com>
Report the local zone's place in the multisite topology and how far it has got syncing from each of its peers. Each peer's log head is read from that peer's own cluster through its imported remote. Comparing local markers against the local log would report caught up unconditionally, so a zone with no matching remote is reported as unreadable instead, which is not the same as being caught up, and neither is a period the markers could not be compared against. Bucket scoped status stays unimplemented. Assisted-by: claude-code:claude-opus-5 Signed-off-by: John Ramsden <john.ramsden@canonical.com>
Route rgw requests to the new handler, completing the path from the REST endpoint to a status answer. Assisted-by: claude-code:claude-opus-5 Signed-off-by: John Ramsden <john.ramsden@canonical.com>
a5a4af2 to
67a3c84
Compare
UtkarshBhatthere
left a comment
UtkarshBhatthere
left a comment
There was a problem hiding this comment.
I think these need fixing before merge:
[P1] Use the realm metadata master, not the local zonegroup master
isMasterZone() only compares the local zone with the local zonegroup’s master_zone. In a realm with multiple zonegroups, the master of a non-master zonegroup will incorrectly skip metadata-sync status and be reported as master. The metadata source needs to be the master zone in the realm’s master zonegroup.
[P2] Do not query every zonegroup peer as a data-sync source
The status code calls data sync status --source-zone for every peer zone. RGW can be configured with directional sync_from relationships or sync policies, so not every peer is necessarily a source for this zone. Non-source peers can therefore appear as unavailable or behind even though no data stream exists.
[P2] Preserve failed local status reads
The RGW wrappers turn a failed local radosgw-admin ... sync status command into a zero value with no error. When the peer log is available, that zero value falls through to behind, even though no local sync state was read. This should be surfaced as an unavailable/error result instead.
Targeted check run successfully:
go test -count=1 ./ceph ./api ./api/types
2 participants
Description
Part 02 of #809
Add the plumbing and relevant API for a status subcommand.
Note: We are pausing on this features development so we are not moving forward with creating the user facing part yet, but we are merging what we have to avoid having to come back to it in the future when drift has occurred. Everything here is read only, and will not be interacted with The intention of this PR is the place it in so that we can continue working in the future when we come back to the future.
As of this point we just have read wrappers to facilitate executing rgw commands, and the API for status.
This does not support bucket status, which will require more read wrappers.
Next steps when we pick this up again:
listenable/disableconfigureType of change
How has this been tested?
Contributor checklist
Please check that you have: