jackye1995 commented on code in PR #10722:
URL: https://github.com/apache/iceberg/pull/10722#discussion_r1773613570
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -3103,6 +3103,81 @@ components:
uuid:
type: string
+ ADLSCredentials:
+ type: object
+ allOf:
+ - $ref: '#/components/schemas/Credentials'
+ required:
+ - type
+ properties:
+ type:
+ type: string
+ enum: [ "adls" ]
+ account-name:
+ type: string
+ account-key:
+ type: string
+ sas-token:
+ type: string
+ expires-at-ms:
+ type: integer
+ format: int64
+
+ GCSCredentials:
+ type: object
+ allOf:
+ - $ref: '#/components/schemas/Credentials'
+ required:
+ - type
+ - token
+ - expires-at-ms
+ properties:
+ type:
+ type: string
+ enum: [ "gcs" ]
+ token:
+ type: string
+ expires-at-ms:
+ type: integer
+ format: int64
+
+ S3Credentials:
+ type: object
+ allOf:
+ - $ref: '#/components/schemas/Credentials'
+ required:
Review Comment:
Sorry a bit late to this, I was in general neutral about the proposal so did
not pay too much attention.
But the AWS client thing seems worth discussion. Ultimately, it sounds like
we want the freedom to configure the FileIO in the way we want **per table**,
that includes credentials and region and maybe other things in the future.
Given that we already want to formally standardize all the FileIO properties
across languages, and also we are using config map to vend the configurations
of those FileIO, then why do we still need to have dedicated credentials
fields? It does seem a bit redundant to me just for the sake of not using
config properties for a selective subset of fields...
Yufei's proposal of having a dedicated storage field could be a more
formalized way to say that these configs are only for FileIO, I am neutral on
that.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
