[BUG] SCS-IaaS mandatory "s3" service type is ambiguous, untested and not aligned with the OS Service Type Authority

[toothstone]

As discussed on 2025-09-18 and on Matrix, https://docs.scs.community/standards/scs-0123-v1-mandatory-and-supported-IaaS-services implies a Service type of "s3", but the test suite looks for "object-store", which is actually out of scope since the OpenStack API listed by the Service Type Authority for that type is the Swift API.

The next version of SCS-IaaS should define the mandatory catalog in a more precise manner (e.g. in the format OS users are used to from openstack catalog list, since this is crucial for the (machine-to-machine) discovery of services.
Furthermore I suggest that whatever SCS defines should adhere with the guidelines of the OpenStack Service Type Authority.

[toothstone]

My take-away from todays Lean Operator Coffee is that most CSPs just "deal with it" and enable Swift to pass the tests, even though there is little demand for it. Customers don't seem to notice/care about the catalog entries.

[mbuechse]

@toothstone That's valid from the POV of the operators, but standards-wise the current situation is quite undesirable (if not untenable). So how do we proceed?

To be clear:

• the standard does NOT talk about an OpenStack service type S3; it only requires S3 to be present (quote: "The following IaaS APIs MUST be present in SCS-compliant IaaS deployments and could be implemented with the corresponding OpenStack services")
• it does not specify how to discover S3, which is the main weak point
• enabling Swift may make the test find its "S3", but if that's not the S3 that the customers use, then we have a big problem!

I think we urgently need to specify how to announce presence of S3....

[toothstone]

My proposal:

• refactor SCS-0123 to mandate OS Catalog entries, i.e. rename the "Mandatory API" column to "Mandatory Service type", align the table format with the OpenStack CLI catalog output, and its entries with the Service Type Authority
• mandate the Service Type "scs:s3" for the s3 service, from here on we handle it like any other service - we can drop the special case language for s3, all services MUST be discoverable via the catalog
• adjust the compliance checker to look for that service type, drop the URL magic, and run the s3 tests as before against the URL now given in the catalog

I'm not super familiar with the versioning yet, but in my understanding this will be a breaking change for certification, so we probably need a new SCS-0123 version and switch to that in SCS-IaaS version next?

[mbuechse]

@toothstone I like your proposal very much, and I think we should discuss it in the SIG (S3 is on the agenda for tomorrow).

One thing: I probably wouldn't use the prefix scs: for a service type as common and widespread as S3 (it's much more common than OpenStack I presume).

[toothstone]

I considered aws: but that seems like a can of worms we should not touch, I expect lots of brand/copyright FUD. I simply don't have any better idea, especially if we stick with the guidance that the prefix should refer to an "organization".

[mbuechse]

I understand that. Let's discuss it in the SIG. I guess we could deviate from the guidelines here and drop the prefix, if we so decide...

[garloff]

While using the Swift entry ("Name": "swift", "Type": "object-store") in the service catalog to discover S3 is not perfect, I would advise against outlawing it. The reason is that both the native OpenStack swift service as well as the commonly used radosgw support both swift and s3 protocols (which are similar!) on the same endpoints.
We only need a solution for those operators that do not offer swift and need to agree on a service type for them, ideally finding consensus beyond the SCS community.

[garloff]

Here's a little market overview from clouds that I have access to:
Service catalogue entries (Name, Type):

Cloud	Swift	S3	Remarks
OTC	-	objectstorage, object	-
Cleura	-	-	-
PlusServer	swift, object-store	-	Primary S3 in docs
Noris	swift, object-store	-	rgw
Artcodix	swift, object-store	-	-
CiaB	swift, object-store	-	rgw
SCS-HWLab	-	-	-
OVH	swift, object-store	s3, object-store-s3	Addtl s3-X, object-store-s3-X pairs in svc catalogue (X=tape, standard, ...)
PoC-WGCloud	-	-	yaook
SysEleven	-	-	-

[garloff]

The service catalogue entry from OVH looks reasonable to me.
The standard could say something like:

An S3-compatible object-storage service MUST be available. The S3 endpoint MUST be discoverable through the OpenStack service catalogue. If the S3 service does not support the OpenStack Swift protocol, it MUST use the Name "s3" and Type "object-store-s3". Otherwise the Swift endpoint (with Name "swift" and Type "object-store") MAY be used to also imply the S3 endpoint and a separate "s3","object-store-s3" is not required. If only the Swift endpoint is advertised, it is MANDATORY that the objects and buckets/containers visible through both protocols are identical.

(The last sentence may go beyond what we had standardized in the past, so we could make this RECOMMENDED.)

[garloff]

(Variants: We may opt to only mandate the Type and only recommend the Name for s3. With an implementation note that users should match Type ...)
If people have access to further clouds (VexxHost, StackHPC, Aptira, ChinaTelekom, ...), further feedback is welcome, of course.
@toothstone: In theory, there should be a IANA-like registry for the OpenStack service catalogue to avoid naming conflicts. Thus using a prefix ("namespace") would be cleanest, agreed. That said, I'd be pragmatic and would consider a Name and Type s3, object-store-s3 to be very safe against being already used and conflicting with something that does not speak the S3-API.

I guess the more difficiult task is to move to a higher level of precision which subset of the S3 features we require.
Maybe starting with an intersection of radosgw, swift and minio would be a reasonable starting point for the discussion.
(Again, the cleaner approach is of course to come from the user perspective, but not having that data easily accessible to us, we take what popular implementations have done as a proxy for this. If we have additional insight, we can of course add or remove features.)