Yeah, maybe NONE is misleading and so UNMANAGED or IMPLICIT could be
better. In some cases it's conceivable that there really is no "auth" as
such -- like with HADOOP -- and so I wonder if IMPLICIT over-promises a bit?
--EM
On Wed, Jul 2, 2025 at 1:10 PM Dmitri Bourlatchkov wrote:
> How about u
+1 (binding)
Verified:
* Checksums
* Signatures
* Admin tool bootstrap with PostgreSQL
* ./gradlew pTML (from the source bundle)
* Spark Client smoke test (create / insert / select with AWS)
Cheers,
Dmitri.
On Wed, Jul 2, 2025 at 2:57 PM Yufei Gu wrote:
> Hi everyone,
>
> I propose that we re
Yeah I think IMPLICIT seems reasonable -- we could start with that and then
expand to NONE if the need arises.
On Wed, Jul 2, 2025 at 2:34 PM Dmitri Bourlatchkov wrote:
> I'd be fine with supporting both NONE and IMPLICIT.
>
> I'd expect NONE to be executed as strictly no authentication in reque
Thanks Dimtri and Eric, for now I will update the PR with IMPLICIT. If others
send out suggestions later, I could change it. If not, we can proceed with
IMPLICIT.
Thanks,
Pooja
On 2025/07/02 22:21:50 Eric Maynard wrote:
> Yeah I think IMPLICIT seems reasonable -- we could start with that and
IMO 2a should be off the table; the person creating an EXTERNAL catalog
does not necessarily have permission to access the path that a
hive-site.xml is as (whether local to the Polaris catalog service or in
object storage) or to even know what paths the catalog has access to. It's
the same problem
Hi Eric,
I agree with your points.
However, I am not sure now that I understand the proposed use case.
When the new NONE (or any proposed alternative name) is used as the
authentication type in an External Catalog, what kind of auth flow will
actually happen in runtime?
* Will Polaris not perfo
+1 (binding)
-Verified Checksums and Sigs
-Verified all build and test again
-Rechecked the license fixes we did in the past RC's
On Wed, Jul 2, 2025 at 2:46 PM Dennis Huo wrote:
> +1 (binding)
>
> -Verified all checksums
> -Verified compile from source tarball
> -Verified setting feature confi
I'd be fine with supporting both NONE and IMPLICIT.
I'd expect NONE to be executed as strictly no authentication in requests to
external catalogs, though, even if the connector (inside Polaris) allows
defaulting to environment or files, etc.
If IMPLICIT is specified and the Polaris Server cannot
+ 1 (non-binding)
Verified usage of Polaris Spark client plugin with --package and --jars
usage. The operations verified:
- create/drop namespaces
- create/insert/list/load/drop tables
Best Regards,
Yun
On Wed, Jul 2, 2025 at 12:46 PM Dennis Huo wrote:
> +1 (binding)
>
> -Verified all checksum
Hi everyone,
I propose that we release the following RC as the official Apache Polaris
1.0.0-incubating release.
This corresponds to the tag: apache-polaris-1.0.0-incubating-rc6
*
https://github.com/apache/polaris/commits/apache-polaris-1.0.0-incubating-rc6
*
https://github.com/apache/polaris/tre
Thanks Dennis for flagging this. Good news is that it's a
clean cherry-pick. Cancelling RC5, will cut RC6 with the fix(
https://github.com/apache/polaris/commit/22eaff4fed431715ec8efc8c749a1707c99c48e7
).
Yufei
On Tue, Jul 1, 2025 at 11:49 PM Dennis Huo wrote:
> -1 (binding)
>
> Given the natu
Hey Eric,
The part about other auth types has a few aspects we should consider:
1. We can reliably support HMS instances that have (Simple, ie. NO_AUTH) and
LDAP (with some implementation of LDAPAuthenticationType).
2. We can't support Kerberos because it requires that the user via the Polaris
> I believe we need to consider both the server-side impact and user-side
impact
> NONE [...] feels like the federated catalog will not perform any
authentication.
I see multiple users here. There's an admin configuring the Polaris
service, there's a person creating the EXTERNAL catalog, and there
I think this is orthogonal to Dmitri's note above but my understanding is
the following:
When the auth type is NONE, the config doesn't tell Polaris which (or any)
hive-site.xml to pick up. This is essentially just a test mode or a mode
for when the Polaris service is deployed as a wrapper around
+1
Regards
JB
On Thu, Jul 3, 2025 at 7:29 AM Ajantha Bhat wrote:
>
> Hello, everyone.
> I'm starting this thread to discuss the possibility of changing the CI
> settings for apache/polaris to only require approval for new contributors.
> This will improve the experience for our contributors. We
+1 to IMPLICIT.
Note, I would consider the Hadoop/HDFS one to actually also correctly be
following the conventions we described for IMPLICIT, because the Polaris
service/system environment can indeed be configured to make the Hadoop
FileSystem use whatever auth it wants, even Kerberos-based access
Hello, everyone.
I'm starting this thread to discuss the possibility of changing the CI
settings for apache/polaris to only require approval for new contributors.
This will improve the experience for our contributors. We do not have
self-hosted runners, so there is no attack surface from the action
+1 (binding)
-Verified all checksums
-Verified compile from source tarball
-Verified setting feature configs
-Successfully tested federation with list fix
On Wed, Jul 2, 2025 at 11:57 AM Yufei Gu wrote:
> Hi everyone,
>
> I propose that we release the following RC as the official Apache Polaris
How about using the enum name IMPLICIT in this case?
YAML comments will briefly mention runtime env. implications. Documentation
will (later) explain how it works in detail.
>From my POV, "NONE" means strictly no auth.
Cheers,
Dmitri.
On Wed, Jul 2, 2025 at 4:04 PM Eric Maynard
wrote:
> > W
+1 (non-binding)
* Checksums
* Signatures
* tested Postgres
Thank you Yufei,
Best,
Prashant Singh
On Wed, Jul 2, 2025 at 3:32 PM Russell Spitzer
wrote:
> +1 (binding)
>
> -Verified Checksums and Sigs
> -Verified all build and test again
> -Rechecked the license fixes we did in the past RC's
>
Thanks for resuming this discussion, Pooja!
I believe we need to consider both the server-side impact and the user-side
impact. I tend to think that user-side clarity is preferred in this context
since the user is the actor creating/updating catalog authentication
parameters in runtime.
In that r
> When the new NONE (or any proposed alternative name) is used as the
authentication type in an External Catalog, what kind of auth flow will
actually happen in runtime?
This question really gets to the core of what we are discussing. From my
perspective in implementing HADOOP, we can interpret NO
+1 (binding)
I checked:
- Source distribution
-- incubating is in the version
-- signature and checksum are good
-- DISCLAIMER is present
-- LICENSE and NOTICE are good (personally, I think NOTICE should not
mention Nessie as it's just the copyright and already in the LICENSE,
but one IPMC asked t
23 matches
Mail list logo
