a606e57bbd
Fixes #1565 Fixes #1561 Fixes #1300 This PR focuses on three main changes: 1. **Prioritizing object-level lock configuration over bucket-level default retention** When an object is uploaded with a specific retention configuration, it takes precedence over the bucket’s default retention set via `PutObjectLockConfiguration`. If the object’s retention expires, the object must become available for write operations, even if the bucket-level default retention is still active. 2. **Preventing object lock configuration from being disabled once enabled** To align with AWS S3 behavior, once object lock is enabled for a bucket, it can no longer be disabled. Previously, sending an empty `Enabled` field in the payload would disable object lock. Now, this behavior is removed—an empty `Enabled` field will result in a `MalformedXML` error. This creates a challenge for integration tests that need to clean up locked objects in order to delete the bucket. To handle this, a method has been implemented that: * Removes any legal hold if present. * Applies a temporary retention with a "retain until" date set 3 seconds ahead. * Waits for 3 seconds before deleting the object and bucket. 3. **Allowing object lock to be enabled on existing buckets via `PutObjectLockConfiguration`** Object lock can now be enabled on an existing bucket if it wasn’t enabled at creation time. * If versioning is enabled at the gateway level, the behavior matches AWS S3: object lock can only be enabled when bucket versioning status is `Enabled`. * If versioning is not enabled at the gateway level, object lock can always be enabled on existing buckets via `PutObjectLockConfiguration`. * In Azure (which does not support bucket versioning), enabling object lock is always allowed. This change also fixes the error message returned in this scenario for better clarity.
The Versity S3 Gateway:
A High-Performance S3 Translation Service
Binary release builds
Download latest release
| Linux/amd64 | Linux/arm64 | MacOS/amd64 | MacOS/arm64 | BSD/amd64 | BSD/arm64 |
|---|---|---|---|---|---|
| ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
Use Cases
- Turn your local filesystem into an S3 server with a single command!
- Proxy S3 requests to S3 storage
- Simple to deploy S3 server with a single command
- Protocol compatibility in
posixallows common access to files via posix or S3 - Simplified interface for adding new storage system support
News
Check out latest wiki articles: https://github.com/versity/versitygw/wiki/Articles
Mailing List
Keep up to date with latest gateway announcements by signing up to the versitygw mailing list.
Documentation
See project documentation on the wiki.
Need help?
Ask questions in the community discussions.
Contact Versity Sales to discuss enterprise support.
Overview
Versity Gateway, a simple to use tool for seamless inline translation between AWS S3 object commands and storage systems. The Versity Gateway bridges the gap between S3-reliant applications and other storage systems, enabling enhanced compatibility and integration while offering exceptional scalability.
The server translates incoming S3 API requests and transforms them into equivalent operations to the backend service. By leveraging this gateway server, applications can interact with the S3-compatible API on top of already existing storage systems. This project enables leveraging existing infrastructure investments while seamlessly integrating with S3-compatible systems, offering increased flexibility and compatibility in managing data storage.
The Versity Gateway is focused on performance, simplicity, and expandability. The Versity Gateway is designed with modularity in mind, enabling future extensions to support additional backend storage systems. At present, the Versity Gateway supports any generic POSIX file backend storage, Versity’s open source ScoutFS filesystem, Azure Blob Storage, and other S3 servers.
The gateway is completely stateless. Multiple Versity Gateway instances may be deployed in a cluster to increase aggregate throughput. The Versity Gateway’s stateless architecture allows any request to be serviced by any gateway thereby distributing workloads and enhancing performance. Load balancers may be used to evenly distribute requests across the cluster of gateways for optimal performance.
The S3 HTTP(S) server and routing is implemented using the Fiber web framework. This framework is actively developed with a focus on performance. S3 API compatibility leverages the official aws-sdk-go-v2 whenever possible for maximum service compatibility with AWS S3.
Getting Started
See the Quickstart documentation.
Run the gateway with posix backend:
mkdir /tmp/vgw
ROOT_ACCESS_KEY="testuser" ROOT_SECRET_KEY="secret" ./versitygw --port :10000 posix /tmp/vgw
This will enable an S3 server on the current host listening on port 10000 and hosting the directory /tmp/vgw.
To get the usage output, run the following:
./versitygw --help
The command format is
versitygw [global options] command [command options] [arguments...]
The global options are specified before the backend type and the backend options are specified after.
Versity gives you clarity and control over your archival storage, so you can allocate more resources to your core mission.
Contact
info@versity.com
+1 844 726 8826
@versitysoftware
