Hi Dmitri, I agree with the "NONE" suggestion, I will send out the new version once PR 1931 <https://github.com/apache/polaris/pull/1931> is merged because as discussed on GH, we plan to use changes from 1931.
Regarding the NULL_TYPE enum: In my experiences, it is always good to think about backward compatibility and "forward" compatibility. The NULL_TYPE provides a catch-all for any unrecognized value that Polaris finds in its persistence layer that it can't interpret. Let me know what you think. Thanks, Pooja On 2025/06/24 17:35:22 Dmitri Bourlatchkov wrote: > Thanks for starting this discussion, Pooja! > > The general idea of explicitly supporting unauthenticated connections > sounds good to me. > > Adding a new auth type enum value to the Management REST API spec also > sounds good to me. I believe it is a backward-compatible API change (still > it was correct to start a dev list discussion since it is a REST API > change). > > However, we need to be careful with naming the new enum value as the name > will propagate through many future releases. Eric proposed "NONE" in the > PR, and I'd prefer this name too. > > Regarding specific changes in the PR, as I commented in GH, the presence of > the NULL_TYPE enum value in java code looks odd to me, as it does not map > to any REST API parameters. I hope we can clarify that as part of this > effort (perhaps as a separate PR). WDYT? > > Cheers, > Dmitri. > > On Tue, Jun 24, 2025 at 1:18 PM Pooja Nilangekar <nilangekar.po...@gmail.com> > wrote: > > > Hi all, > > > > As suggested in the PR 1925 <https://github.com/apache/polaris/pull/1925>, > > I wanted to initiate a discussion for the NO_AUTH support. My apologies for > > not starting this discussion sooner. > > > > > > The primary goal is to enable Polaris to federate with catalogs that permit > > authentication-less access, such as the Hadoop Catalog and Hive Metastore. > > This is currently a significant gap. For instance, while we've merged > > support for Hadoop federation (1466) > > <https://github.com/apache/polaris/pull/1466>, it's not practically usable > > because Hadoop requires either auth-less or Kerberos access—neither of > > which Polaris currently supports. > > > > I propose we tackle this in two phases: > > > > 1. *Phase 1: Initial Support:* Implement the core functionality to allow > > auth-less connections to external catalogs. > > 2. *Phase 2: Connection Type Validation (Future Enhancement):* Introduce > > a mapping between connection types and their allowed authentication > > methods. This would allow Polaris to validate and reject unsupported > > combinations upfront, providing a cleaner user experience. > > > > I believe it's safe to defer Phase 2 because any incorrect connection > > attempt will still be rejected by the federated catalog's server. > > > > Please let me know your thoughts on this approach or if you can think of > > any alternative ways to support auth-less connections. > > > > Thanks, > > Pooja > > >
