flyingImer commented on PR #4052: URL: https://github.com/apache/polaris/pull/4052#issuecomment-4146110446
Thanks for the draft here. I’m aligned with the direction, and I think this is already useful in showing that S3 Tables can fit the federated catalog path at the protocol level. My bias would be to treat this as a good proof point, and then use the next iteration to tighten both the shape and the vending semantics a bit more. In particular, I wonder if the cleaner direction here would be: - keep the S3 Tables-specific policy generation in a dedicated storage-integration path, rather than growing more branching in the existing S3 logic - align that with the broader push toward a more unified call path for storage locations, rather than introducing another parallel path here On the credential vending side, there is also a concrete next-step item that feel worth making explicit: - IIUC, only `loadTable` currently derives S3 Tables `resourceArns`, while the create paths still flow through with empty resource scope. I think the next iteration should make those create-time semantics explicit: either derive the usable scope there as well, or fail/defer vending rather than returning partially-scoped credentials. This seems especially relevant given the S3 Tables REST docs note that stage-create is not supported. Also worth aligning with Tornike's PR #3699 on the unified call path for storage locations, seems like natural synergy. Looking forward to seeing this evolve. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
