On Wed, May 7, 2025 at 11:29 AM Robert Stupp wrote:
> If federated principals cannot be created, it doesn't make sense to me
> to even have that flag.
>
I think Robert has a point here. Still, from my POV (as I commented in GH
[1])
exposing the same property in PrincipalRole and Principal at the
Hi Dmitri,
If it's not "all" is it not strong enough for a spec, IMHO. If some tables
have multiple base locations how is Polaris going to deal with them?
Sorry, when I say most of them, it was because I haven't tested all of them
(I only tested Delta and CSV before).
However, if Unity Catalog is
Hi everyone,
Thanks everyone who participated in the vote for Release Apache
Polaris 0.10.0-beta-incubating (rc2).
The vote result is:
+1: 5 (binding) 5 (non binding)
0: 0 (binding) 0 (non binding)
-1: 0 (binding) 0 (binding)
I'm starting the vote on the Incubator general mailing list.
Thanks
If federated principals cannot be created, it doesn't make sense to me
to even have that flag.
On 01.05.25 19:57, Michael Collado wrote:
Maybe our approaches are just different. As for me, making backend changes
first, adding API later is more "natural" :)
I definitely have the opposite appr
Hi everyone,
The Apache Polaris community has voted and approved the release of
Apache Polaris 0.10.0-beta-incubating (rc2).
We now kindly request the IPMC members (and everyone) to review and
vote for this release.
Polaris community vote thread:
* https://lists.apache.org/thread/d0ywnzmp481f1p0l
Even for Iceberg, as I noted, we track multiple locations and vend
credentials scoped to those multiple locations.
On Wed, May 7, 2025 at 5:22 PM Dmitri Bourlatchkov wrote:
> No worries about the name. It is a possible alternative spelling :)
>
> On Wed, May 7, 2025 at 8:04 PM yun zou wrote:
>
Re: funky S3 URIs: https://github.com/apache/polaris/issues/1545
On Wed, May 7, 2025 at 7:48 PM Dmitri Bourlatchkov wrote:
> What options do we have other than URI? I think it's more an engine side
> concern.
>
>
> If (as mentioned in previous emails) we use this location as an input into
> gene
It doesn't really matter. Robert, if I remove the flag, will you remove the
-1 on the PR?
On Wed, May 7, 2025 at 10:43 AM Dmitri Bourlatchkov
wrote:
> On Wed, May 7, 2025 at 11:29 AM Robert Stupp wrote:
>
> > If federated principals cannot be created, it doesn't make sense to me
> > to even hav
>
> Another point: I'm pretty sure sooner or later users will want to move
> their data to some other location. As an option users may want to write new
> files into another location but keep old files in place.
What's the concern here? This field is pretty much like the Iceberg table
location, wh
Another point: I'm pretty sure sooner or later users will want to move
their data to some other location. As an option users may want to write new
files into another location but keep old files in place.
Also: if the location is a URI, how do we deal with s3 vs. s3a for example?
In Iceberg it is
What options do we have other than URI? I think it's more an engine side
concern.
If (as mentioned in previous emails) we use this location as an input into
generating vended credentials, then Polaris must be able to interpret it.
Therefore, it is not only an engine side concern.
What's the con
Hi Dimitri and Eric,
Thanks a lot for the feedback!
For the questions:
- Is one value or many?
It will be one value, similar to the location in Iceberg and the
storage_location in unity catalog.
Regarding to the point about having new data in new locations and keeping
old data in old locations,
Hi folks,
I would like to propose to add an optional `location` field to
CreateGenricTable Request and LoadGenericTable response.
The `location` is the location for the table, which is common to most table
formats including Iceberg, Delta, Hudi, csv, parquet etc. The location
information is criti
Hi Yun,
Please clarify the meaning of the value of the new location attribute.
- Is is one value or many?
- Is it a URI?
- Does it point to any particular file?
- Is it a common prefix of all files within a table?
- What happens when a value does not match these expectation?
Thanks,
Dmitri.
On
All good questions Dmitri — I’m especially interested in the first one as
from what I understand Iceberg tables can have metadata and data at two
different paths that we need to vend credentials for.
For iceberg tables, we just use special properties to track these
locations. I wonder if we couldn
+1 Credential vending won't be possible without it.
Yufei
On Wed, May 7, 2025 at 2:50 PM yun zou wrote:
> Hi folks,
>
> I would like to propose to add an optional `location` field to
> CreateGenricTable Request and LoadGenericTable response.
>
> The `location` is the location for the table, wh
Hi Dmitri,
Sorry, I accidentally typed your name wrong in the previous reply!
Apologize for this!
For the S3 issue, I think we will need to deal with those regardless,
especially with the federation work going on, we will need to handle all
those entities eventually coming from different Catalogs
Thanks for the quick reply, Yun!
Regarding to the point about having new data in new locations and keeping
old data in old locations, do we support that for Iceberg
today?
My concern is not about supporting that for Iceberg tables. Their spec is
outside
of Polaris' control. Here we're talking ab
No worries about the name. It is a possible alternative spelling :)
On Wed, May 7, 2025 at 8:04 PM yun zou wrote:
> Hi Dmitri,
>
> Sorry, I accidentally typed your name wrong in the previous reply!
> Apologize for this!
>
> For the S3 issue, I think we will need to deal with those regardless,
>
Hi folks,
FYI, I merged the PR about nightly builds (SNAPSHOTs).
The GitHub Action has been executed yesterday (as expected):
https://github.com/apache/polaris/actions/workflows/nightly.yml
and the SNAPSHOT artifacts have been deployed in the snapshots
repository (for instance
https://repository.
20 matches
Mail list logo
