Is it possible to avoid specification of protocol twice?

[BlaineEXE]

https://github.com/kubernetes-sigs/container-object-storage-interface-api/blob/7c26b4fc1ed9e719cd3342f2666c855260930cc9/apis/objectstorage.k8s.io/v1alpha1/protocol_types.go#L28-L37

Do we need to include Name as well as the different protocol options? This makes it so that whenever options are included, users must specify their choice twice: once in Name and once implicitly in the protocol spec. E.g.,

protocol:
  name: s3
  s3:
     blah: stuff

K8s volume claims use a syntax where the option itself implicitly specifies the option desired. E.g.,

volumes:
  - name: myDir
    emptyDir: {}

Does it make sense to follow that pattern for the protocol also? Like below would be an S3 config with no options set.

protocol:
  s3: {}

[jeffvance]

Good observation @BlaineEXE
cc @wlan0

[wlan0]

@BlaineEXE without the name, we wouldn't be able to disambiguate between no options and default options. In case of pvc, the emptyDir you've specified is interpreted as a nil value. It only works because emptyDir is the default volume type (https://github.com/kubernetes/api/blob/master/core/v1/types.go#L43). This would give you the same result

volume:
  - name: myDir

In case of protocol, we cannot assume a default like that.

[BlaineEXE]

I don't believe that is quite correct. I did an experiment in Rook with the Protocol.

I think the secret is to set the nullable: true field in the CRD spec so that if the value is not present, it gets a nil pointer.

I added the below CRD spec to Rook and types for the protocols to test.

                protocol:
                  properties:
                    azureBlob:
                      properties:
                        containerName:
                          type: string
                        storageAccount:
                          type: string
                      type: object
                      nullable: true
                    gcs:
                      properties:
                        bucketName:
                          type: string
                        privateKeyName:
                          type: string
                        projectID:
                          type: string
                        serviceAccount:
                          type: string
                      type: object
                      nullable: true
                    s3:
                      properties:
                        bucketName:
                          type: string
                        endpoint:
                          type: string
                        region:
                          type: string
                        signatureVersion:
                          enum:
                          - s3v2
                          - s3v4
                          type: string
                      type: object
                      nullable: true
                  type: object

I put nothing in the manifest to get nil specs for all. (golang print "%+v" for the protocol shown after examples)

{S3:<nil> AzureBlob:<nil> GCS:<nil>}

I put this in the manifest to get a non-nil S3 spec.

  protocol:
    s3: {}

{S3:0xc000d29600 AzureBlob:<nil> GCS:<nil>}

This should allow testing for non-nil to see if anything is present, even if nothing is actually specified.

[wlan0]

I see, tbh I'm not opposed to this - There is one more concern to address though.

This protocol structure is going to be sent to the application that consumes the bucket. If the application parser cannot disambiguate between default and nil values, that would make drivers buggy and put extra load the vendors writing the driver. Is there someway we can address that?

Note that the application parser will not understand CRD spec

[BlaineEXE]

That's a good point. I think I have some questions to better understand COSI's operation around this since I don't have as deep an understanding.

The whole Protocol struct is sent to applications. Is this sent via Go code, or is this sent via a k8s resource?

Cursory thoughts: If it's sent via Go code, then COSI can still send nil for non-selected protocols. If it's sent to apps via k8s resource and is mostly an internal detail to COSI, then protocolName could be sent to applications additionally based on a Go reflect of the name of the struct.

If there are no longer any high-level options in the Protocol struct (name and version wouldn't seem to apply with the proposed spec), does it need sent in its entirety? Can COSI send only the relevant protocol/options to the application in some way?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[k8s-triage-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.