WKBCH-25: Complete CRR support#77
Conversation
PR #49 added the CRR plumbing but didn't create the IAM role backbeat assumes for replication. Add it in the data account via vault accountSeeds so role-issued credentials authorize source and destination S3 calls. Ship scripts/enable-crr.sh to create the buckets and apply the replication policy idempotently.
|
Both containers write into host-mounted directories. Becuase the run as root, they left root-owned files.
15800df to
705326d
Compare
|
LGTM — changes are internally consistent and well-structured. Replication role, admin credentials file, Kafka topic rename, host UID/GID mapping, and the enable-crr.sh helper all line up correctly across the touched files. The set +e guard for zookeeper-shell.sh NodeExists is appropriate, and the new setup-kafka dependency on backbeat closes a real race condition. |
| "port": 8500, | ||
| "adminPort": 8600, | ||
| "adminCredentialsFile": "/home/scality/backbeat/node_modules/vaultclient/tests/utils/admincredentials.json" | ||
| "adminCredentialsFile": "/conf/admin-backbeat.json" |
There was a problem hiding this comment.
What's the diff between the two? or was there some permissions issue?
There was a problem hiding this comment.
It's the same content, I just thought it's a bit better for future readers to have the file here.
|
|
||
| func LoadEnvironmentConfig(path string) (EnvironmentConfig, error) { | ||
| cfg := DefaultEnvironmentConfig() | ||
| cfg.HostUID = os.Getuid() |
There was a problem hiding this comment.
I remember messing around with this but it was for the logs/volumes with the host, anything related to CRR in this case?
There was a problem hiding this comment.
Not related to CRR, just a side-fix for an issue I noticed (705326d).
It is about file permissions in volumes on the host.
Because containers run as root, files in volumes are owned by root and need sudo to rm.
Pin workbench to the head of WKBCH-25 (scality/workbench#77), which provisions the queue-populator's raft-id-dispatcher to cover all data raft sessions. The previous SHA only provisioned raftIds 0,1,2 while metadata-s3 with raftSessions=3 creates 4 sessions (0=admin, 1..3=data), leaving raftId 3 uncovered: any bucket whose hash landed there sat at ReplicationStatus=PENDING forever and the CRR e2e test timed out. Temporary pin; revert to a tagged workbench release once WKBCH-25 is merged and tagged.
WKBCH-25 added redis to backbeat config, which activates backlogControl (previously a no-op since redis was unreachable). It then throttles the conductor whenever the bucket-tasks topic has any consumer lag, which causes test flakiness under bursty parallel load: lifecycle stalls long enough to blow expiration timeouts.
Pin workbench to the head of WKBCH-25 (scality/workbench#77) which disables the lifecycle conductor's backlogControl. Without this, the conductor throttles whenever the bucket-tasks topic has any consumer lag, which the parallel e2e suite triggers reliably and stalls lifecycle expiration past the test timeout.
|
499253b to
f9a33d1
Compare
Pin workbench to the head of WKBCH-25 (scality/workbench#77) which provisions the queue-populator for all data raft sessions. Without this, raftId 3 was uncovered: any source bucket whose hash landed there sat at ReplicationStatus=PENDING forever and the CRR e2e test timed out.
|
|
LGTM — changes are consistent and well-structured. Replication-role seed, admin credentials file, Kafka topic rename, ZooKeeper provision path fix, host UID/GID for setup containers, and the enable-crr.sh helper all look correct. No issues found. |
|
LGTM — clean, well-structured changes. Template modifications produce valid configs, the new helper script is idempotent, and the zookeeper provision path fix (0-indexed → 1-indexed) correctly aligns with raft session IDs. No issues found. |
Builds on #49 to make replication actually fire end-to-end.
testaccount(the bucket-owning account) via vault'saccountSeeds.Adds a helper script (
scripts/enable-crr.sh) that creates the source and destination buckets, enables versioning, and applies the replication policy.Idempotent for CI use.