[Feature Request] Standardize available S3 features

[toothstone]

In practice the SCS-IaaS mandatory "S3 API" is not well defined, given its sorry state of being a proprietary Amazon product, not a standardized thing. Basically all clone implementations I know of support a (different) subset of S3 features, especially those relevant here, such as Swift and Ceph.

• Garage has a nice overview comparing the different solutions that are around: https://garagehq.deuxfleurs.fr/documentation/reference-manual/s3-compatibility/
• Swift feature matrix: https://docs.openstack.org/swift/latest/s3_compat.html
• Ceph feature matrix: https://docs.ceph.com/en/latest/radosgw/s3/

So for example I can't use Bucket lifecycles to have a caching bucket expire automatically when the bucket lives on a Swift-backed S3. But currently I would have no idea that there might be such a limitation when buying a SCS-IaaS certified cloud (indeed had to learn that the hard way myself).

To be really clear, this has the potential to be certification-breaking and require quite some effort from CSPs if it is decided to require a more complete set of S3 features, since they might have to migrate their S3 service to completely different solution then.

I'm not clear how representative my experience is for other users/SCS-IaaS Cloud customers, I'll try to get some more opinions on that.

[toothstone]

During todays Lean Operator Coffee it was discussed that this is an actual pain point for CSPs and customers, since it makes the requirement "s3" much more difficult to assess. Although this is more a weakness of s3 overall, we still should have a somewhat helpful spec what SCS users can expect.

One pragmatic approach would be to define the Ceph/RGW feature set as a common baseline, since this seems to be most commonly used object storage provider. We should check this against other common backends, e.g. NetApps proprietary s3 compatibility layer was mentioned.

However, that would currently prevent CSPs from using Swift, garage and openio, according to the garage feature matrix.

[toothstone]

I was asked to kick this off by supplying of list of features I need for my use cases, which are mainly GitLab runners:

• Bucket CRUD
• Object CRUD
• BucketLifecycle CRUD - given S3 is often used for caching and backup applications, this seems generally relevant, eliminating Swift

[mbuechse]

I had to "fix a bug" in the test code regarding boto3, and now I'm wondering if the bug was rather with the server implementation?

Quoting e9174b0#diff-b51a59fb4eb3e17760a4e89763f53f2b029a5281390f4eb0ac8286aed2b90328:

-            s3.delete_bucket(Bucket=TESTCONTNAME)
+            # contrary to Boto docs at
+            # https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3/client/delete_bucket.html
+            # , the following fails with
+            # AttributeError: 's3.ServiceResource' object has no attribute 'delete_bucket'. Did you mean: 'create_bucket'?
+            # s3.delete_bucket(Bucket=TESTCONTNAME)
+            # workaround:
+            s3.Bucket(name=TESTCONTNAME).delete()

Does anyone know?

[toothstone]

I had to "fix a bug" in the test code regarding boto3, and now I'm wondering if the bug was rather with the server implementation?

s3_conn returns an s3.ServiceResource, not an s3.Client, contrary to the docstring. So no relation to the server-side feature set.

[mbuechse]

My memory is faded a bit, but I was under the impression that s3.ServiceResource was a subclass of s3.Client

At any rate, why does create_bucket work then?

[toothstone]

At any rate, why does create_bucket work then?

https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3/service-resource/index.html states that is one of the two existing methods for ServiceResource.

[mbuechse]

You're right, of course. This API does make me feel stupid. They have a method named create_bucket in two distinct classes, and only one of them has the corresponding delete_bucket.