Add --storage-class CLI flag validation logic

[DavidCastroSanchez]

Tell us more about this new feature.

Summary

Add CLI-level validation for the --storage-class flag to ensure only valid S3 storage classes are accepted at mount time, providing immediate feedback to users before attempting to mount.

Motivation

Currently, invalid storage class values may not be caught until an upload operation fails. By validating storage classes at CLI parsing time using a strongly-typed enum, users receive immediate, clear error messages when specifying an invalid value.

Example (misspelled INTELLIGENT_TIERING with one L):

Current behavior:

# mount-s3 <bucket_name> mounted-s3 --storage-class INTELIGENT_TIERING
bucket <bucket_name> is mounted at mounted-s3
# echo "Hello from Mountpoint!" > test.txt
bash: echo: write error: Input/output error

Expected behavior:

# mount-s3 <bucket_name> mounted-s3 --storage-class INTELIGENT_TIERING
error: invalid value 'INTELIGENT_TIERING' for '--storage-class <STORAGE_CLASS>'
  [possible values: STANDARD, REDUCED_REDUNDANCY, STANDARD_IA, ONEZONE_IA, INTELLIGENT_TIERING, GLACIER, DEEP_ARCHIVE, OUTPOSTS, GLACIER_IR, SNOW, EXPRESS_ONEZONE]

  tip: a similar value exists: 'INTELLIGENT_TIERING'

For more information, try '--help'.

Proposed Implementation

Introduce a StorageClass enum implementing clap's ValueEnum trait that validates input against all valid S3 storage classes:

• STANDARD
• REDUCED_REDUNDANCY
• STANDARD_IA
• ONEZONE_IA
• INTELLIGENT_TIERING
• GLACIER
• DEEP_ARCHIVE
• OUTPOSTS
• GLACIER_IR
• SNOW
• EXPRESS_ONEZONE

The validation should:

• Accept only uppercase values (matching S3 API requirements)
• Reject empty strings, lowercase and mixed case
• Provide helpful error messages listing valid options and similar values when possible

Additional Context

• Reference: S3 PutObject StorageClass documentation
• Note: EXPRESS_ONEZONE is only valid for directory buckets (further bucket-type validation may be a separate enhancement)
• Note: FSX_OPENZFS and FSX_ONTAP options are not included

[muddyfish]

Hi, thanks for your feature request.

We've not included this to allow Mountpoint to work when new storage classes are introduced to S3 (or other S3 compatible systems)

Given that you'd see all writes failing, I'd expect you'd be able to catch this type of issue in development rather in production. Are the existing Mountpoint logs not clear enough to see when the problem happens?

[DavidCastroSanchez]

First of all, thank you for the prompt response.

I see your point regarding new storage classes. I would argue that new storage classes aren't introduced that often, but it's still a valid concern. Perhaps this could be an opt-out feature for customers who want to maintain forward compatibility with potential future storage classes, so if they don't want this validation, they could disable it with a flag like --no-storage-class-validation.

Alternatively, it could be opt-in, where users include something like --validate-storage-class when they want to ensure they're using a valid storage class.

I haven't checked the logs, and I can imagine the write failure gets captured there. However, I would push back and say that just because something is logged somewhere doesn't mean users should be allowed to do it in the first place.

I would prefer a "fail-fast" approach, catching this error as early as possible (at mount time rather than at write time). I believe this leads to a better user experience and easier debugging. The current behavior creates a confusing situation where the mount succeeds but subsequent operations fail silently with generic terminal I/O errors (again, I haven't checked the actual logs, I assume the invalid storage class error is logged somewhere in them).

The real question I'm trying to tackle is: Why allow mounting a bucket with a non-existent or misspelled storage class instead of returning an error?

Even though this type of error could be caught in dev environments, it also adds friction for less experienced users, potentially reducing adoption of this connector. I have personally experienced multiple customers struggling with this during workshops I delivered around Mountpoint, so this is something less experienced users are actually facing.

Thoughts?