Biota DB Uploader

A task that uploads a zipped Biota MariaDB data folder to the cloud bucket, to declare a new version of the Biota database.

Overview

This is the missing step between BiotaDbZipper (which produces the zip) and BiotaDbDownloader (which consumes it). It uploads the zip as a raw file, under a versioned key:

db/<db_version>/mariadb.zip

Unlike the generic ResourceUploaderS3 task from gws_core, the uploaded object is the zip itself, byte for byte. ResourceUploaderS3 wraps its input in a ResourceZipper archive named <uuid>.tar, which is meant to be re-imported by another data lab and cannot be consumed by the Biota DB Docker image.

Once uploaded, update the BIOTA_DB_URL variable in the brick settings.json to point to the new key, so that BiotaDbDownloader picks up the new version.

Input/Output

• Input: File resource, the zip produced by BiotaDbZipper
• Outputs: None

Configuration Parameters

Notes

• Bucket naming: the historical gws_biota container cannot be used here, which is why the default is gws-biota (hyphen). Swift container names may contain underscores, S3 bucket names may not, so the OVH S3 gateway answers 400 InvalidBucketName for gws_biota and omits it from ListBuckets entirely. That container is fine, it is simply not addressable over S3, whatever the endpoint or credentials. gws-biota lives in the same Swift account and is public.
• Public read: database_image/init-db.sh downloads the zip with an anonymous wget, so the uploaded object must be publicly readable. Note that the S3 host itself refuses anonymous requests: the public URL is the Swift one, https://storage.<region>.cloud.ovh.net/v1/AUTH_<project>/<container>/<key>.
• Zip layout: init-db.sh extracts the archive and copies /tmp/mariadb/*, so the zip must contain a top-level mariadb/ folder.