openstack
/
charm-ceph-radosgw
Code Issues Proposed changes

Update patch set 15 

Patch Set 15:

(1 comment)

Patch-set: 15
This commit is contained in:
Gerrit User 13178 2024-04-24 16:13:06 +00:00 committed by Gerrit Code Review
parent 23f016c37d
commit ea2ddf152e
1 changed files with 18 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
dda2b0b83fc6b5318f4731eca05bbfa44c5b11b5
View File

@ -16,6 +16,24 @@
"message": "I\u0027m looking over the Zaza tests failure.",
"revId": "dda2b0b83fc6b5318f4731eca05bbfa44c5b11b5",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": false,
"key": {
"uuid": "0186eb07_d9561bc0",
"filename": "/PATCHSET_LEVEL",
"patchSetId": 15
},
"lineNbr": 0,
"author": {
"id": 13178
},
"writtenOn": "2024-04-24T16:13:06Z",
"side": 1,
"message": "Hi!\n\nI figured out why the integration test was failing on `focal-yoga-multisite` (which installs Ceph Quincy release).\nThis was not happening on `jammy-bobcat-multisite` (which installs Ceph Reef release).\n\nWe have the following function that is used to check that metadata and data are in sync:\nhttps://github.com/openstack-charmers/zaza-openstack-tests/blob/2e0beacad42d41bded68039dbb297d33786ace06/zaza/openstack/charm_tests/ceph/tests.py#L719-L756\n\nThe function basically checks the output of the `radosgw-admin sync status` command, and\nit asserts that the stdout contains:\n\n* `metadata is caught up with master` (if secondary zone) or `metadata sync no sync (zone is master)` (if primary zone).\n* `data is caught up with source`\n\nThe problem is that when `directional` sync flow is configured, the output is different on Reef vs Quincy on the primary unit.\n\nThis is the output of `radosgw-admin sync status` on Ceph Quincy:\n\n```\nroot@juju-9c97f9-0:/home/ubuntu# radosgw-admin --id rgw.$(hostname) sync status\n realm 680b8c84-7947-419a-a4a8-1b955ff2bab7 (zaza_realm)\n zonegroup 8109e66a-20e3-45f9-b2de-27c972348e89 (zaza_zg)\n zone 171bb40d-5486-4551-b397-0dc03f6e5999 (zaza_primary)\n metadata sync no sync (zone is master)\n data sync source: b61dccec-f111-4bb0-8fc3-dfc80f73ddd9 (zaza_secondary)\n not syncing from zone\n```\n\nAnd this is the output of the same command on Ceph Reef:\n\n```\nroot@juju-a91add-0:/home/ubuntu# radosgw-admin --id rgw.$(hostname) sync status\n realm 5983b280-4f05-4c74-86ba-05fd0d989d29 (zaza_realm)\n zonegroup b368ffec-ff51-40f7-8ae7-9a5a40dbbd65 (zaza_zg)\n zone 3b38bace-63b8-455d-9b01-609819a051fc (zaza_primary)\n current time 2024-04-24T11:30:15Z\nzonegroup features enabled: resharding\n disabled: compress-encrypted\n metadata sync no sync (zone is master)\n data sync source: 4204da32-77d2-4299-961c-92738321511d (zaza_secondary)\n init\n full sync: 0/0 shards\n incremental sync: 0/0 shards\n data is caught up with source\n```\n\nNotice that the assertion string for `data is caught up with source` is not present on Quincy, while this is present on Reef.\n\nGiven the fact that the test case verifies `directional` sync flow (primary --\u003e secondary), we don\u0027t need to assert any metadata / data syncronization status on the primary zone.\n\nWe only need to do metadata / data sync status assertion on the secondary zone, which is working as expected. The `radosgw-admin sync status` output is consistent with both Reef and Quincy.\n\nI updated the associated Zaza test case with this.\n\nBesides this inconsistency of the CMD stdout, nothing is functionally different between Quincy and Reef regarding multi-site sync policies.\n\nAs a bonus when debugging this, I discovered that the sync flow type couldn\u0027t be changed if objects were already present in the bucket. I fixed this in patchset 16, because there\u0027s no limitation in Ceph that prevents this.",
"parentUuid": "334709d1_fb952e59",
"revId": "dda2b0b83fc6b5318f4731eca05bbfa44c5b11b5",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
}
]
}