v1alpha2 KEP update: allow admins to disable multi-bucket access if desired

[BlaineEXE]

Enhancement

Why is this needed?:

KEP change request was made here: kubernetes/enhancements#4599 (comment)

Describe the solution you'd like in detail:

In addition to drivers having the ability to reject a multi-bucket access request, admins should be able to disable the feature on the BucketAccessClass as well.

Describe alternatives you've considered:
N/A

Additional context:
N/A

[BlaineEXE]

I think there are a couple of ways this could be implmented, and I'd like to solicit feedback.

Option 1, a dedicated bool option similar to StorageClass AllowVolumeExpansion *bool https://github.com/kubernetes/api/blob/180fdecad17ae409e7fc5a7505811cb4ed1bb881/storage/v1/types.go#L63-L65

This could be

type BucketAccessClass struct {
  Spec BucketAccessClassSpec {
    // ...

    // DisallowedBucketAccessModes defines optional limitations on the BucketAccessModes that can be provisioned.
    DisallowedBucketAccessModes []BucketAccessMode
    
    // DisallowMultiBucketAccess allows disabling the ability for a BucketAccess to reference
    // multiple BucketClaims. This could be because the driver does not support the feature,
    // or it could be the admin's preference.
    DisallowMultiBucketAccess *bool

    // Parameters is an opaque map for passing in configuration to a driver for granting access to a bucket.
    // +optional
    Parameters map[string]string
  }
}

Alternately, we could plan for potential other feature enable/disable scenarios by nesting the option. Something like this

type BucketAccessClass struct {
  Spec BucketAccessClassSpec {
    // ...

    // DisallowedBucketAccessModes defines optional limitations on the BucketAccessModes that can be provisioned.
    DisallowedBucketAccessModes []BucketAccessMode

    // FeatureOptions allows modifying some COSI feature behavior.
    FeatureOptions *struct {
        DisallowMultiBucketAccess *bool 

        // potentially, DisallowedBucketAccessModes could go here too

        // Any future feature options would go here
    }

    // Parameters is an opaque map for passing in configuration to a driver for granting access to a bucket.
    // +optional
    Parameters map[string]string
  }
}

[BlaineEXE]

I personally lean toward allowing more room for future expansion that wouldn't crowd the main API, with a design like this. The concern I have is that this could be a bit over-engineered.

type BucketAccessClass struct {
  Spec BucketAccessClassSpec {
    // ...

    // Parameters is an opaque map for passing in configuration to a driver for granting access to a bucket.
    // +optional
    Parameters map[string]string

    // FeatureOptions allows modifying some COSI feature behavior.
    FeatureOptions *struct {
        // DisallowedBucketAccessModes defines optional limitations on the BucketAccessModes that can be provisioned.
        DisallowedBucketAccessModes []BucketAccessMode

        // DisallowMultiBucketAccess allows disabling the ability for a BucketAccess to multiple BucketClaims.
        DisallowMultiBucketAccess bool 

        // Any future feature options would go here
    }
  }
}

[shanduur]

Between the options, I like the FeatureOptions struct more. While it adds a small amount of complexity, it is IMHO a cleaner and more scalable way to evolve the API.

[BlaineEXE]

Thanks! I updated the KEP, and we can always adjust based on conversations in the next few days.

[BlaineEXE]

Xing wonders if a flat hierarchy might be simpler overall but is okay with the change. We will wait to see what shows up in KEP review. I'll leave this open for now in case anyone wants to chime in. Otherwise, I think prow will close it after a period of no updates