Hi team,
I am currently migrating our commcare-cloud deployment (Ubuntu 22.04) from a local File System blobdb backend to an S3-compatible backend using a self-hosted Garage S3 cluster behind an Nginx proxy.
i followed this documentation for the process. Migrate from File System backend to an S3 compatible backend — CommCareHQ Deployment documentation
Prior to running the automated scripts, I verified that the remote object storage cluster is fully reachable and functional by successfully executing commands with the AWS CLI, such as:
aws --endpoint-url=http://192.168.200.41 s3 cp test.txt s3://test/
I added the following settings to my public.yml file:
s3_blob_db_enabled: yes
s3_blob_db_url: "http://192.168.200.41"
s3_blob_db_s3_bucket: misau
localsettings:
BLOB_DB_MIGRATING_FROM_FS_TO_S3: True
I also added the respective credentials to environments/<env>/vault.yml:
-
secrets.S3_ACCESS_KEY -
secrets.S3_SECRET_KEY
After configuring these, I ran commcare-cloud <env> update-config and restarted the commcare services. However, running commcare-cloud <env> check_services throws the following exception under blobdb
EXCEPTION (Took 0.08s) blobdb : Service check errored with exception 'ClientError('An error occurred (400) when calling the HeadBucket operation: Bad Request')'
Because Garage strictly requires path-style addressing (rather than virtual-host style routing), it seems the underlying boto3 client initialized by CommCare is defaulting to virtual-host lookups and causing the 400 error.
Is there an additional configuration block or environment setting needed in public.yml to ensure boto3 maps the HeadBucket check properly for a custom path-style S3 endpoint, or is this a known limitation of the automated check_services script with non-AWS S3 endpoints?
Thanks in advance!