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.
| setup-vault: | ||
| condition: service_completed_successfully | ||
| setup-kafka: | ||
| condition: service_completed_successfully |
There was a problem hiding this comment.
The PR adds a redis config block to backbeat's config.json, making redis a new runtime dependency. Consider adding an explicit depends_on so backbeat doesn't start before redis is healthy. In practice redis starts faster than the setup services, so this is unlikely to bite, but it keeps the ordering guarantees consistent with the other dependencies.
| condition: service_completed_successfully | |
| condition: service_completed_successfully | |
| redis: | |
| condition: service_healthy |
— Claude Code
|
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.