Hi
Generally speaking, that's the purpose of Community Meeting: discuss
about what's going on and new proposals, populating the roadmap. The
GitHub Discussion is one vision/proposal from some of us and anyone
can add new features to it.
In Apache projects, it's also just proposals, because any con
Thanks for the detailed response Dimitri and Yufei!
I agree with making the PR to support user-defined client ID and secret via
the REST API, along with appropriate access checks and possibly introducing
a new permission type/config. I will work on this
REST fits better with our tooling as it has
Hi
I'm fine having a dedicated repo for helm chart, it all depends on
what we want to release:
1. If we just want to release helm charts "package", then helm charts
can stay in the polaris repo (as so part of the source distribution)
2. if we want to release a complete different source distributio
Hi all,
For reference and completeness, this has also been previously
discussed in a much older thread:
https://lists.apache.org/thread/428xb6dfrmm7xgr91p2dxoy8ptcyovs2
So far the consensus was, as Yufei pointed out, to release the Helm
chart along with the Polaris server release (+docker images,
If we decide to adopt an independent release cadence for the Helm chart, it
might
be more intuitive to host it in a separate repository. While this would
increase the
effort required to maintain compatibility between Helm chart releases and
Polaris
releases—particularly around testing and documenta
Hi everyone,
I believe Hive Metastore (HMS) federation is a critical feature for the success
and widespread
adoption of the project. The reality of the current data lake ecosystem is that
a vast number of
organizations have significant footprint in HMS. For Polaris to be the Iceberg
Rest Catal
I also think that the compatibility between helm charts and Polaris
binaries will need more attention if we use a separate repository.
However, from my POV I'd expect helm charts to get changes / contributions
independently of the Polaris Server code (for all sorts of deployment
choices), so havin
Thanks for volunteering to make a PR for this, Arun! Looking forward to it.
As discussed, please consider securing the extra capability via (new)
permission checks. I'd think it might be worth it to also have a feature
flag to control the new functionality.
Re: External IdP - most of the authenti
Hi Yufei,
I do not think what Arun proposes is related to Secrets Management in
Polaris. The use cases you mentioned do require accessing "raw" secrets
owned by external systems. What Arun is proposing is about basically
resetting Polaris' own password (for Polaris Principals). In that case
Polari
Hi Arun,
After writing my previous email I realised that we might be able to support
your use case via REST API by implementing admin-base password reset [624].
The flow would be:
1) create a principal using current ID (random client ID/secret)
2) set your own client ID / secret via the password
Howdy Polaris Community,
Now that 1.0 has shipped, I think it might be nice to have a dedicated
community meeting where we discuss what large Polaris enhancements we want
to work on in the next few months.
>From what I've learned from folks, back in February, the community came
together and had a
11 matches
Mail list logo
