You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polaris.apache.org by artur rakhmatulin <ar...@gmail.com> on 2026/02/01 19:23:35 UTC
[DISCUSS] Introducing workspaces in Polaris Console UI
Hi all,
I’d like to start a discussion on introducing "workspaces" in the Polaris
Console UI.
The idea is to move away from environment-variable–based configuration
toward a UI-managed model, where a workspace represents an isolated Polaris
context (server, realm, and authentication). This allows a single console
instance to work with multiple realms and Polaris environments in a clean
and scalable way.
A preliminary PR is available for review [1]
Thanks, Artur.
[1]: https://github.com/apache/polaris-tools/pull/138
Re: [DISCUSS] Introducing workspaces in Polaris Console UI
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi
I agree with the take away from the discussion.
Client side is fine to me. I will do a new pass on the PR.
Thanks !
Regards
JB
On Mon, Feb 9, 2026 at 4:17 PM Dmitri Bourlatchkov <di...@apache.org> wrote:
> Hi Artur,
>
> From the discussion, it seems that:
> - 1:1 remains the preferred deployment model.
> - There is currently no request to embed the UI into the Polaris Server,
> and the UI remains a separate component.
>
>
> +1 to that from my side.
>
> If this understanding is correct, I propose to keep the current PR focused
> on the client-side use case and proceed with review/merge.
>
>
> I'll review shortly (hopefully :) )
>
> Cheers,
> Dmitri.
>
> On Mon, Feb 9, 2026 at 5:08 AM artur rakhmatulin <
> artur.rakhmatulin@gmail.com> wrote:
>
> > Hi all, thanks for the discussion. I'm sorry for the late response, I was
> > on a vacation.
> >
> > Let me try to summarize and check alignment:
> > - The current PR introduces client-side workspaces only (LocalStorage, no
> > backend changes).
> > - It is meant as a UX improvement for working with multiple
> > realms/environments.
> > - It does NOT aim to implement a full 1 enterprise-grade console or a
> > centralized backend layer.
> >
> > One additional context - I originally started working on this while
> > experimenting with OIDC integration in the UI.
> > Having workspaces significantly simplifies testing, prototyping, and
> > integrating the UI with different Polaris servers and auth setups.
> > Without it, these workflows become a bit complex.
> >
> > From the discussion, it seems that:
> > - 1:1 remains the preferred deployment model.
> > - There is currently no request to embed the UI into the Polaris Server,
> > and the UI remains a separate component.
> >
> > If this understanding is correct, I propose to keep the current PR
> focused
> > on the client-side use case and proceed with review/merge.
> > Please let me know if anyone sees blockers for this approach.
> >
> > Regards,
> > Artur.
> >
> > чт, 5 февр. 2026 г. в 16:17, Dmitri Bourlatchkov <di...@apache.org>:
> >
> > > Hi Alex,
> > >
> > > Good point about the front-end service endpoint!
> > >
> > > I suppose in real life deployments, the proxy / API gateway can indeed
> be
> > > in front of both the UI server and the API server and the Browser will
> > > observe the same host/port but different URI paths.
> > >
> > > I suppose we could simulate that in the UI module by using helm instead
> > of
> > > plain docker for the getting-started example (i.e. the UI helm will
> > include
> > > a Polaris Server with some fixed version for its image).
> > >
> > > Cheers,
> > > Dmitri.
> > >
> > > On Thu, Feb 5, 2026 at 8:52 AM Alexandre Dutra <ad...@apache.org>
> > wrote:
> > >
> > > > Hi all,
> > > >
> > > > I think I would prefer to stay on the 1:1 model and I would even
> > > > advocate for co-locating the UI with the Polaris server.
> > > >
> > > > My reasons are:
> > > >
> > > > 1) Users would simply direct their browser to the service in front of
> > > > the Polaris deployment, completely eliminating CORS issues.
> > > >
> > > > 2) Quarkus already supports Human-to-Machine flows, such as the
> > > > authorization code grant. It would transparently redirect users to
> the
> > > > IDP login page if necessary.
> > > >
> > > > 3) For the internal /token endpoint, indeed a simple login page as
> > > > suggested by Dmitri could help, if it mimics the authorization code
> > > > grant flow.
> > > >
> > > > The 1:N model is undoubtedly attractive, as it could serve as a
> > > > central management interface for multiple Polaris deployments.
> > > > However, it introduces significant complexity, and I'm uncertain if
> we
> > > > have the resources to develop and sustain it. Not to mention that I
> > > > don't think any users have explicitly requested that feature.
> > > >
> > > > Thanks,
> > > > Alex
> > > >
> > > > On Mon, Feb 2, 2026 at 6:03 PM Dmitri Bourlatchkov <dimas@apache.org
> >
> > > > wrote:
> > > > >
> > > > > Good point by Romain about 1:1 vs. N:1 between UI and Polaris
> > Servers.
> > > > >
> > > > > I do agree that the N:1 model with CORS headers requires Polaris
> > > Servers
> > > > to
> > > > > be aware of all UI instances, which may be very inconvenient in
> > larger
> > > > > environments.
> > > > >
> > > > > From my POV the key negative point about using an API proxy in UI
> is
> > > > > passing credentials through it. Otherwise, the proxy is quite
> valid,
> > > > IMHO.
> > > > >
> > > > > So, in case of OAuth2, the UI should be able to redirect the
> browser
> > to
> > > > an
> > > > > auth page in an IdP (e.g. Keycloak). That is a pure browser-level
> > > > redirect
> > > > > and should not cause any CORS issues (although I'm not an expert in
> > > UI).
> > > > >
> > > > > In case of the "internal" Polaris Authentication flow, currently
> > > someone
> > > > > has to POST to the /tokens endpoint in Polaris. Doing that via
> proxy
> > is
> > > > not
> > > > > ideal from the security perspective, IMHO. Doing a direct POST from
> > JS
> > > > code
> > > > > causes CORS issues. So, how about we host a custom login page in
> > > Polaris
> > > > > (no full UI, just the login page), and allow UI to redirect the
> > browser
> > > > to
> > > > > it in a manner similar to OAuth2 flows?
> > > > >
> > > > > Given that the /token endpoint is already deprecated in the Iceberg
> > > REST
> > > > > Catalog API, handling the internal login flow via OAuth2 flows
> might
> > be
> > > > > preferable from that POV too. Polaris effectively acts as an IdP
> for
> > > > > internal principals anyway.
> > > > >
> > > > > WDYT?
> > > > >
> > > > > Sorry, if this steers the conversation a bit sideways from the
> > original
> > > > > topic, but I believe these issues are interconnected.
> > > > >
> > > > > Thanks,
> > > > > Dmitri.
> > > > >
> > > > > On Mon, Feb 2, 2026 at 4:12 AM Jean-Baptiste Onofré <
> jb@nanthrax.net
> > >
> > > > wrote:
> > > > >
> > > > > > Hi Romain
> > > > > >
> > > > > > That was my point and the reason why I started the console with
> > 1-1.
> > > > > > Again for dev it’s totally fine but enterprise grade probably
> need
> > > > extra
> > > > > > work.
> > > > > >
> > > > > > Regards
> > > > > > JB
> > > > > >
> > > > > > Le lun. 2 févr. 2026 à 09:55, Romain Manni-Bucau <
> > > > rmannibucau@gmail.com> a
> > > > > > écrit :
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > my 2 cts would be that if you switch to 1-N instead of 1-1 you
> > > can't
> > > > just
> > > > > > > rely on the frontend to do the switch since you will desire
> some
> > > > sort of
> > > > > > > centralized security management so specific backend to avoid to
> > > rely
> > > > on
> > > > > > > every backend to be configured the same way to enable smooth
> > > > workflows
> > > > > > > (login -> actions) plus sounds like the backend should handle
> the
> > > > list of
> > > > > > > instances it aggregates with security for every level?
> > > > > > >
> > > > > > > Indeed it only applies to enterprise grade solution, for dev
> the
> > > > current
> > > > > > > option is perfect.
> > > > > > >
> > > > > > > Romain Manni-Bucau
> > > > > > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog
> > > > > > > <https://dotnetbirdie.github.io/> | Blog <
> > > > https://rmannibucau.github.io/
> > > > > > >
> > > > > > > | Old
> > > > > > > Blog <http://rmannibucau.wordpress.com> | Github
> > > > > > > <https://github.com/rmannibucau> | LinkedIn
> > > > > > > <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > > <
> > > > > > >
> > > > > >
> > > >
> > >
> >
> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> > > > > > > >
> > > > > > > Javaccino founder (Java/.NET service - contact via linkedin)
> > > > > > >
> > > > > > >
> > > > > > > Le lun. 2 févr. 2026 à 09:24, Jean-Baptiste Onofré <
> > > jb@nanthrax.net>
> > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > Yes I know the change. My point was
> > > > > > > > More for context to everyone, in order to understand the
> > > > deployment and
> > > > > > > > behavior.
> > > > > > > >
> > > > > > > > Thanks for your work on workspaces. As said, I will take a
> > look.
> > > > > > > >
> > > > > > > > Regards
> > > > > > > > JB
> > > > > > > >
> > > > > > > > Le lun. 2 févr. 2026 à 08:49, artur rakhmatulin <
> > > > > > > > artur.rakhmatulin@gmail.com>
> > > > > > > > a écrit :
> > > > > > > >
> > > > > > > > > Hi JB,
> > > > > > > > > Thanks for the clarification and for sharing your
> experience
> > —
> > > > the
> > > > > > > > > distinction between the two approaches is very helpful.
> > > > > > > > >
> > > > > > > > > Just to clarify the scope of the current PR: it does not
> > > > introduce
> > > > > > any
> > > > > > > > > server-side changes. The workspace concept is purely
> > > client-side
> > > > and
> > > > > > > > > user-scoped, with all configuration stored in browser
> > > > LocalStorage.
> > > > > > > > >
> > > > > > > > > Also, a previous change already removed the strict 1
> Console
> > =
> > > 1
> > > > > > server
> > > > > > > > > limitation in main.
> > > > > > > > > As a result, using a Console with Polaris server now
> requires
> > > > > > explicit
> > > > > > > > CORS
> > > > > > > > > configuration on the server side.
> > > > > > > > > This adds some setup overhead, but keeps the security model
> > > > explicit
> > > > > > > and
> > > > > > > > > controlled by the server.
> > > > > > > > >
> > > > > > > > > The workspace approach builds on top of this by improving
> > > > usability
> > > > > > > when
> > > > > > > > > working with multiple realms or environments, without
> > changing
> > > > server
> > > > > > > > > assumptions.
> > > > > > > > >
> > > > > > > > > Thanks again for the context.
> > > > > > > > >
> > > > > > > > > Best regards, Artur.
> > > > > > > > >
> > > > > > > > > пн, 2 февр. 2026 г. в 10:44, Jean-Baptiste Onofré <
> > > > jb@nanthrax.net>:
> > > > > > > > >
> > > > > > > > > > Hi
> > > > > > > > > >
> > > > > > > > > > Fundamentally, it means about two different approaches:
> > > > > > > > > > 1. Without workspace, it means one Polaris server == one
> > > > Console
> > > > > > > > > > 2. With workspaces, it means one Console == several
> Polaris
> > > > servers
> > > > > > > > > >
> > > > > > > > > > Initially, the intent was (1), but we discussed (2) as
> > well.
> > > > > > > > > > Personally, when I started the Console, I was more (1) as
> > > it's
> > > > > > easier
> > > > > > > > in
> > > > > > > > > > terms of infrastructure (local to the server) and
> security
> > > (no
> > > > > > proxy,
> > > > > > > > > etc),
> > > > > > > > > > and the Console doesn't need any state/storage for the
> > access
> > > > to
> > > > > > the
> > > > > > > > > > different servers.
> > > > > > > > > >
> > > > > > > > > > I'm fine with the workspaces, even if it's a change in
> the
> > > > > > paradigm.
> > > > > > > > > >
> > > > > > > > > > I will take a look at the workspaces PR.
> > > > > > > > > >
> > > > > > > > > > Regards
> > > > > > > > > > JB
> > > > > > > > > >
> > > > > > > > > > On Sun, Feb 1, 2026 at 8:24 PM artur rakhmatulin <
> > > > > > > > > > artur.rakhmatulin@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi all,
> > > > > > > > > > > I’d like to start a discussion on introducing
> > "workspaces"
> > > > in the
> > > > > > > > > Polaris
> > > > > > > > > > > Console UI.
> > > > > > > > > > >
> > > > > > > > > > > The idea is to move away from
> environment-variable–based
> > > > > > > > configuration
> > > > > > > > > > > toward a UI-managed model, where a workspace represents
> > an
> > > > > > isolated
> > > > > > > > > > Polaris
> > > > > > > > > > > context (server, realm, and authentication). This
> allows
> > a
> > > > single
> > > > > > > > > console
> > > > > > > > > > > instance to work with multiple realms and Polaris
> > > > environments
> > > > > > in a
> > > > > > > > > clean
> > > > > > > > > > > and scalable way.
> > > > > > > > > > >
> > > > > > > > > > > A preliminary PR is available for review [1]
> > > > > > > > > > >
> > > > > > > > > > > Thanks, Artur.
> > > > > > > > > > >
> > > > > > > > > > > [1]: https://github.com/apache/polaris-tools/pull/138
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best regards, Artur Rakhmatulin
> > > > > > > > > e-mail: artur.rakhmatulin@gmail.com,
> > > > > > > > > telegram: https://t.me/binarycat0
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> >
> >
> > --
> > Best regards, Artur Rakhmatulin
> > e-mail: artur.rakhmatulin@gmail.com,
> > telegram: https://t.me/binarycat0
> >
>
Re: [DISCUSS] Introducing workspaces in Polaris Console UI
Posted by Dmitri Bourlatchkov <di...@apache.org>.
Hi Artur,
From the discussion, it seems that:
- 1:1 remains the preferred deployment model.
- There is currently no request to embed the UI into the Polaris Server,
and the UI remains a separate component.
+1 to that from my side.
If this understanding is correct, I propose to keep the current PR focused
on the client-side use case and proceed with review/merge.
I'll review shortly (hopefully :) )
Cheers,
Dmitri.
On Mon, Feb 9, 2026 at 5:08 AM artur rakhmatulin <
artur.rakhmatulin@gmail.com> wrote:
> Hi all, thanks for the discussion. I'm sorry for the late response, I was
> on a vacation.
>
> Let me try to summarize and check alignment:
> - The current PR introduces client-side workspaces only (LocalStorage, no
> backend changes).
> - It is meant as a UX improvement for working with multiple
> realms/environments.
> - It does NOT aim to implement a full 1 enterprise-grade console or a
> centralized backend layer.
>
> One additional context - I originally started working on this while
> experimenting with OIDC integration in the UI.
> Having workspaces significantly simplifies testing, prototyping, and
> integrating the UI with different Polaris servers and auth setups.
> Without it, these workflows become a bit complex.
>
> From the discussion, it seems that:
> - 1:1 remains the preferred deployment model.
> - There is currently no request to embed the UI into the Polaris Server,
> and the UI remains a separate component.
>
> If this understanding is correct, I propose to keep the current PR focused
> on the client-side use case and proceed with review/merge.
> Please let me know if anyone sees blockers for this approach.
>
> Regards,
> Artur.
>
> чт, 5 февр. 2026 г. в 16:17, Dmitri Bourlatchkov <di...@apache.org>:
>
> > Hi Alex,
> >
> > Good point about the front-end service endpoint!
> >
> > I suppose in real life deployments, the proxy / API gateway can indeed be
> > in front of both the UI server and the API server and the Browser will
> > observe the same host/port but different URI paths.
> >
> > I suppose we could simulate that in the UI module by using helm instead
> of
> > plain docker for the getting-started example (i.e. the UI helm will
> include
> > a Polaris Server with some fixed version for its image).
> >
> > Cheers,
> > Dmitri.
> >
> > On Thu, Feb 5, 2026 at 8:52 AM Alexandre Dutra <ad...@apache.org>
> wrote:
> >
> > > Hi all,
> > >
> > > I think I would prefer to stay on the 1:1 model and I would even
> > > advocate for co-locating the UI with the Polaris server.
> > >
> > > My reasons are:
> > >
> > > 1) Users would simply direct their browser to the service in front of
> > > the Polaris deployment, completely eliminating CORS issues.
> > >
> > > 2) Quarkus already supports Human-to-Machine flows, such as the
> > > authorization code grant. It would transparently redirect users to the
> > > IDP login page if necessary.
> > >
> > > 3) For the internal /token endpoint, indeed a simple login page as
> > > suggested by Dmitri could help, if it mimics the authorization code
> > > grant flow.
> > >
> > > The 1:N model is undoubtedly attractive, as it could serve as a
> > > central management interface for multiple Polaris deployments.
> > > However, it introduces significant complexity, and I'm uncertain if we
> > > have the resources to develop and sustain it. Not to mention that I
> > > don't think any users have explicitly requested that feature.
> > >
> > > Thanks,
> > > Alex
> > >
> > > On Mon, Feb 2, 2026 at 6:03 PM Dmitri Bourlatchkov <di...@apache.org>
> > > wrote:
> > > >
> > > > Good point by Romain about 1:1 vs. N:1 between UI and Polaris
> Servers.
> > > >
> > > > I do agree that the N:1 model with CORS headers requires Polaris
> > Servers
> > > to
> > > > be aware of all UI instances, which may be very inconvenient in
> larger
> > > > environments.
> > > >
> > > > From my POV the key negative point about using an API proxy in UI is
> > > > passing credentials through it. Otherwise, the proxy is quite valid,
> > > IMHO.
> > > >
> > > > So, in case of OAuth2, the UI should be able to redirect the browser
> to
> > > an
> > > > auth page in an IdP (e.g. Keycloak). That is a pure browser-level
> > > redirect
> > > > and should not cause any CORS issues (although I'm not an expert in
> > UI).
> > > >
> > > > In case of the "internal" Polaris Authentication flow, currently
> > someone
> > > > has to POST to the /tokens endpoint in Polaris. Doing that via proxy
> is
> > > not
> > > > ideal from the security perspective, IMHO. Doing a direct POST from
> JS
> > > code
> > > > causes CORS issues. So, how about we host a custom login page in
> > Polaris
> > > > (no full UI, just the login page), and allow UI to redirect the
> browser
> > > to
> > > > it in a manner similar to OAuth2 flows?
> > > >
> > > > Given that the /token endpoint is already deprecated in the Iceberg
> > REST
> > > > Catalog API, handling the internal login flow via OAuth2 flows might
> be
> > > > preferable from that POV too. Polaris effectively acts as an IdP for
> > > > internal principals anyway.
> > > >
> > > > WDYT?
> > > >
> > > > Sorry, if this steers the conversation a bit sideways from the
> original
> > > > topic, but I believe these issues are interconnected.
> > > >
> > > > Thanks,
> > > > Dmitri.
> > > >
> > > > On Mon, Feb 2, 2026 at 4:12 AM Jean-Baptiste Onofré <jb@nanthrax.net
> >
> > > wrote:
> > > >
> > > > > Hi Romain
> > > > >
> > > > > That was my point and the reason why I started the console with
> 1-1.
> > > > > Again for dev it’s totally fine but enterprise grade probably need
> > > extra
> > > > > work.
> > > > >
> > > > > Regards
> > > > > JB
> > > > >
> > > > > Le lun. 2 févr. 2026 à 09:55, Romain Manni-Bucau <
> > > rmannibucau@gmail.com> a
> > > > > écrit :
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > my 2 cts would be that if you switch to 1-N instead of 1-1 you
> > can't
> > > just
> > > > > > rely on the frontend to do the switch since you will desire some
> > > sort of
> > > > > > centralized security management so specific backend to avoid to
> > rely
> > > on
> > > > > > every backend to be configured the same way to enable smooth
> > > workflows
> > > > > > (login -> actions) plus sounds like the backend should handle the
> > > list of
> > > > > > instances it aggregates with security for every level?
> > > > > >
> > > > > > Indeed it only applies to enterprise grade solution, for dev the
> > > current
> > > > > > option is perfect.
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog
> > > > > > <https://dotnetbirdie.github.io/> | Blog <
> > > https://rmannibucau.github.io/
> > > > > >
> > > > > > | Old
> > > > > > Blog <http://rmannibucau.wordpress.com> | Github
> > > > > > <https://github.com/rmannibucau> | LinkedIn
> > > > > > <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > <
> > > > > >
> > > > >
> > >
> >
> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> > > > > > >
> > > > > > Javaccino founder (Java/.NET service - contact via linkedin)
> > > > > >
> > > > > >
> > > > > > Le lun. 2 févr. 2026 à 09:24, Jean-Baptiste Onofré <
> > jb@nanthrax.net>
> > > a
> > > > > > écrit :
> > > > > >
> > > > > > > Yes I know the change. My point was
> > > > > > > More for context to everyone, in order to understand the
> > > deployment and
> > > > > > > behavior.
> > > > > > >
> > > > > > > Thanks for your work on workspaces. As said, I will take a
> look.
> > > > > > >
> > > > > > > Regards
> > > > > > > JB
> > > > > > >
> > > > > > > Le lun. 2 févr. 2026 à 08:49, artur rakhmatulin <
> > > > > > > artur.rakhmatulin@gmail.com>
> > > > > > > a écrit :
> > > > > > >
> > > > > > > > Hi JB,
> > > > > > > > Thanks for the clarification and for sharing your experience
> —
> > > the
> > > > > > > > distinction between the two approaches is very helpful.
> > > > > > > >
> > > > > > > > Just to clarify the scope of the current PR: it does not
> > > introduce
> > > > > any
> > > > > > > > server-side changes. The workspace concept is purely
> > client-side
> > > and
> > > > > > > > user-scoped, with all configuration stored in browser
> > > LocalStorage.
> > > > > > > >
> > > > > > > > Also, a previous change already removed the strict 1 Console
> =
> > 1
> > > > > server
> > > > > > > > limitation in main.
> > > > > > > > As a result, using a Console with Polaris server now requires
> > > > > explicit
> > > > > > > CORS
> > > > > > > > configuration on the server side.
> > > > > > > > This adds some setup overhead, but keeps the security model
> > > explicit
> > > > > > and
> > > > > > > > controlled by the server.
> > > > > > > >
> > > > > > > > The workspace approach builds on top of this by improving
> > > usability
> > > > > > when
> > > > > > > > working with multiple realms or environments, without
> changing
> > > server
> > > > > > > > assumptions.
> > > > > > > >
> > > > > > > > Thanks again for the context.
> > > > > > > >
> > > > > > > > Best regards, Artur.
> > > > > > > >
> > > > > > > > пн, 2 февр. 2026 г. в 10:44, Jean-Baptiste Onofré <
> > > jb@nanthrax.net>:
> > > > > > > >
> > > > > > > > > Hi
> > > > > > > > >
> > > > > > > > > Fundamentally, it means about two different approaches:
> > > > > > > > > 1. Without workspace, it means one Polaris server == one
> > > Console
> > > > > > > > > 2. With workspaces, it means one Console == several Polaris
> > > servers
> > > > > > > > >
> > > > > > > > > Initially, the intent was (1), but we discussed (2) as
> well.
> > > > > > > > > Personally, when I started the Console, I was more (1) as
> > it's
> > > > > easier
> > > > > > > in
> > > > > > > > > terms of infrastructure (local to the server) and security
> > (no
> > > > > proxy,
> > > > > > > > etc),
> > > > > > > > > and the Console doesn't need any state/storage for the
> access
> > > to
> > > > > the
> > > > > > > > > different servers.
> > > > > > > > >
> > > > > > > > > I'm fine with the workspaces, even if it's a change in the
> > > > > paradigm.
> > > > > > > > >
> > > > > > > > > I will take a look at the workspaces PR.
> > > > > > > > >
> > > > > > > > > Regards
> > > > > > > > > JB
> > > > > > > > >
> > > > > > > > > On Sun, Feb 1, 2026 at 8:24 PM artur rakhmatulin <
> > > > > > > > > artur.rakhmatulin@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > > Hi all,
> > > > > > > > > > I’d like to start a discussion on introducing
> "workspaces"
> > > in the
> > > > > > > > Polaris
> > > > > > > > > > Console UI.
> > > > > > > > > >
> > > > > > > > > > The idea is to move away from environment-variable–based
> > > > > > > configuration
> > > > > > > > > > toward a UI-managed model, where a workspace represents
> an
> > > > > isolated
> > > > > > > > > Polaris
> > > > > > > > > > context (server, realm, and authentication). This allows
> a
> > > single
> > > > > > > > console
> > > > > > > > > > instance to work with multiple realms and Polaris
> > > environments
> > > > > in a
> > > > > > > > clean
> > > > > > > > > > and scalable way.
> > > > > > > > > >
> > > > > > > > > > A preliminary PR is available for review [1]
> > > > > > > > > >
> > > > > > > > > > Thanks, Artur.
> > > > > > > > > >
> > > > > > > > > > [1]: https://github.com/apache/polaris-tools/pull/138
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best regards, Artur Rakhmatulin
> > > > > > > > e-mail: artur.rakhmatulin@gmail.com,
> > > > > > > > telegram: https://t.me/binarycat0
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
>
>
> --
> Best regards, Artur Rakhmatulin
> e-mail: artur.rakhmatulin@gmail.com,
> telegram: https://t.me/binarycat0
>
Re: [DISCUSS] Introducing workspaces in Polaris Console UI
Posted by artur rakhmatulin <ar...@gmail.com>.
Hi all, thanks for the discussion. I'm sorry for the late response, I was
on a vacation.
Let me try to summarize and check alignment:
- The current PR introduces client-side workspaces only (LocalStorage, no
backend changes).
- It is meant as a UX improvement for working with multiple
realms/environments.
- It does NOT aim to implement a full 1 enterprise-grade console or a
centralized backend layer.
One additional context - I originally started working on this while
experimenting with OIDC integration in the UI.
Having workspaces significantly simplifies testing, prototyping, and
integrating the UI with different Polaris servers and auth setups.
Without it, these workflows become a bit complex.
From the discussion, it seems that:
- 1:1 remains the preferred deployment model.
- There is currently no request to embed the UI into the Polaris Server,
and the UI remains a separate component.
If this understanding is correct, I propose to keep the current PR focused
on the client-side use case and proceed with review/merge.
Please let me know if anyone sees blockers for this approach.
Regards,
Artur.
чт, 5 февр. 2026 г. в 16:17, Dmitri Bourlatchkov <di...@apache.org>:
> Hi Alex,
>
> Good point about the front-end service endpoint!
>
> I suppose in real life deployments, the proxy / API gateway can indeed be
> in front of both the UI server and the API server and the Browser will
> observe the same host/port but different URI paths.
>
> I suppose we could simulate that in the UI module by using helm instead of
> plain docker for the getting-started example (i.e. the UI helm will include
> a Polaris Server with some fixed version for its image).
>
> Cheers,
> Dmitri.
>
> On Thu, Feb 5, 2026 at 8:52 AM Alexandre Dutra <ad...@apache.org> wrote:
>
> > Hi all,
> >
> > I think I would prefer to stay on the 1:1 model and I would even
> > advocate for co-locating the UI with the Polaris server.
> >
> > My reasons are:
> >
> > 1) Users would simply direct their browser to the service in front of
> > the Polaris deployment, completely eliminating CORS issues.
> >
> > 2) Quarkus already supports Human-to-Machine flows, such as the
> > authorization code grant. It would transparently redirect users to the
> > IDP login page if necessary.
> >
> > 3) For the internal /token endpoint, indeed a simple login page as
> > suggested by Dmitri could help, if it mimics the authorization code
> > grant flow.
> >
> > The 1:N model is undoubtedly attractive, as it could serve as a
> > central management interface for multiple Polaris deployments.
> > However, it introduces significant complexity, and I'm uncertain if we
> > have the resources to develop and sustain it. Not to mention that I
> > don't think any users have explicitly requested that feature.
> >
> > Thanks,
> > Alex
> >
> > On Mon, Feb 2, 2026 at 6:03 PM Dmitri Bourlatchkov <di...@apache.org>
> > wrote:
> > >
> > > Good point by Romain about 1:1 vs. N:1 between UI and Polaris Servers.
> > >
> > > I do agree that the N:1 model with CORS headers requires Polaris
> Servers
> > to
> > > be aware of all UI instances, which may be very inconvenient in larger
> > > environments.
> > >
> > > From my POV the key negative point about using an API proxy in UI is
> > > passing credentials through it. Otherwise, the proxy is quite valid,
> > IMHO.
> > >
> > > So, in case of OAuth2, the UI should be able to redirect the browser to
> > an
> > > auth page in an IdP (e.g. Keycloak). That is a pure browser-level
> > redirect
> > > and should not cause any CORS issues (although I'm not an expert in
> UI).
> > >
> > > In case of the "internal" Polaris Authentication flow, currently
> someone
> > > has to POST to the /tokens endpoint in Polaris. Doing that via proxy is
> > not
> > > ideal from the security perspective, IMHO. Doing a direct POST from JS
> > code
> > > causes CORS issues. So, how about we host a custom login page in
> Polaris
> > > (no full UI, just the login page), and allow UI to redirect the browser
> > to
> > > it in a manner similar to OAuth2 flows?
> > >
> > > Given that the /token endpoint is already deprecated in the Iceberg
> REST
> > > Catalog API, handling the internal login flow via OAuth2 flows might be
> > > preferable from that POV too. Polaris effectively acts as an IdP for
> > > internal principals anyway.
> > >
> > > WDYT?
> > >
> > > Sorry, if this steers the conversation a bit sideways from the original
> > > topic, but I believe these issues are interconnected.
> > >
> > > Thanks,
> > > Dmitri.
> > >
> > > On Mon, Feb 2, 2026 at 4:12 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> > wrote:
> > >
> > > > Hi Romain
> > > >
> > > > That was my point and the reason why I started the console with 1-1.
> > > > Again for dev it’s totally fine but enterprise grade probably need
> > extra
> > > > work.
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > Le lun. 2 févr. 2026 à 09:55, Romain Manni-Bucau <
> > rmannibucau@gmail.com> a
> > > > écrit :
> > > >
> > > > > Hi,
> > > > >
> > > > > my 2 cts would be that if you switch to 1-N instead of 1-1 you
> can't
> > just
> > > > > rely on the frontend to do the switch since you will desire some
> > sort of
> > > > > centralized security management so specific backend to avoid to
> rely
> > on
> > > > > every backend to be configured the same way to enable smooth
> > workflows
> > > > > (login -> actions) plus sounds like the backend should handle the
> > list of
> > > > > instances it aggregates with security for every level?
> > > > >
> > > > > Indeed it only applies to enterprise grade solution, for dev the
> > current
> > > > > option is perfect.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog
> > > > > <https://dotnetbirdie.github.io/> | Blog <
> > https://rmannibucau.github.io/
> > > > >
> > > > > | Old
> > > > > Blog <http://rmannibucau.wordpress.com> | Github
> > > > > <https://github.com/rmannibucau> | LinkedIn
> > > > > <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > <
> > > > >
> > > >
> >
> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> > > > > >
> > > > > Javaccino founder (Java/.NET service - contact via linkedin)
> > > > >
> > > > >
> > > > > Le lun. 2 févr. 2026 à 09:24, Jean-Baptiste Onofré <
> jb@nanthrax.net>
> > a
> > > > > écrit :
> > > > >
> > > > > > Yes I know the change. My point was
> > > > > > More for context to everyone, in order to understand the
> > deployment and
> > > > > > behavior.
> > > > > >
> > > > > > Thanks for your work on workspaces. As said, I will take a look.
> > > > > >
> > > > > > Regards
> > > > > > JB
> > > > > >
> > > > > > Le lun. 2 févr. 2026 à 08:49, artur rakhmatulin <
> > > > > > artur.rakhmatulin@gmail.com>
> > > > > > a écrit :
> > > > > >
> > > > > > > Hi JB,
> > > > > > > Thanks for the clarification and for sharing your experience —
> > the
> > > > > > > distinction between the two approaches is very helpful.
> > > > > > >
> > > > > > > Just to clarify the scope of the current PR: it does not
> > introduce
> > > > any
> > > > > > > server-side changes. The workspace concept is purely
> client-side
> > and
> > > > > > > user-scoped, with all configuration stored in browser
> > LocalStorage.
> > > > > > >
> > > > > > > Also, a previous change already removed the strict 1 Console =
> 1
> > > > server
> > > > > > > limitation in main.
> > > > > > > As a result, using a Console with Polaris server now requires
> > > > explicit
> > > > > > CORS
> > > > > > > configuration on the server side.
> > > > > > > This adds some setup overhead, but keeps the security model
> > explicit
> > > > > and
> > > > > > > controlled by the server.
> > > > > > >
> > > > > > > The workspace approach builds on top of this by improving
> > usability
> > > > > when
> > > > > > > working with multiple realms or environments, without changing
> > server
> > > > > > > assumptions.
> > > > > > >
> > > > > > > Thanks again for the context.
> > > > > > >
> > > > > > > Best regards, Artur.
> > > > > > >
> > > > > > > пн, 2 февр. 2026 г. в 10:44, Jean-Baptiste Onofré <
> > jb@nanthrax.net>:
> > > > > > >
> > > > > > > > Hi
> > > > > > > >
> > > > > > > > Fundamentally, it means about two different approaches:
> > > > > > > > 1. Without workspace, it means one Polaris server == one
> > Console
> > > > > > > > 2. With workspaces, it means one Console == several Polaris
> > servers
> > > > > > > >
> > > > > > > > Initially, the intent was (1), but we discussed (2) as well.
> > > > > > > > Personally, when I started the Console, I was more (1) as
> it's
> > > > easier
> > > > > > in
> > > > > > > > terms of infrastructure (local to the server) and security
> (no
> > > > proxy,
> > > > > > > etc),
> > > > > > > > and the Console doesn't need any state/storage for the access
> > to
> > > > the
> > > > > > > > different servers.
> > > > > > > >
> > > > > > > > I'm fine with the workspaces, even if it's a change in the
> > > > paradigm.
> > > > > > > >
> > > > > > > > I will take a look at the workspaces PR.
> > > > > > > >
> > > > > > > > Regards
> > > > > > > > JB
> > > > > > > >
> > > > > > > > On Sun, Feb 1, 2026 at 8:24 PM artur rakhmatulin <
> > > > > > > > artur.rakhmatulin@gmail.com> wrote:
> > > > > > > >
> > > > > > > > > Hi all,
> > > > > > > > > I’d like to start a discussion on introducing "workspaces"
> > in the
> > > > > > > Polaris
> > > > > > > > > Console UI.
> > > > > > > > >
> > > > > > > > > The idea is to move away from environment-variable–based
> > > > > > configuration
> > > > > > > > > toward a UI-managed model, where a workspace represents an
> > > > isolated
> > > > > > > > Polaris
> > > > > > > > > context (server, realm, and authentication). This allows a
> > single
> > > > > > > console
> > > > > > > > > instance to work with multiple realms and Polaris
> > environments
> > > > in a
> > > > > > > clean
> > > > > > > > > and scalable way.
> > > > > > > > >
> > > > > > > > > A preliminary PR is available for review [1]
> > > > > > > > >
> > > > > > > > > Thanks, Artur.
> > > > > > > > >
> > > > > > > > > [1]: https://github.com/apache/polaris-tools/pull/138
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best regards, Artur Rakhmatulin
> > > > > > > e-mail: artur.rakhmatulin@gmail.com,
> > > > > > > telegram: https://t.me/binarycat0
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
>
--
Best regards, Artur Rakhmatulin
e-mail: artur.rakhmatulin@gmail.com,
telegram: https://t.me/binarycat0
Re: [DISCUSS] Introducing workspaces in Polaris Console UI
Posted by Dmitri Bourlatchkov <di...@apache.org>.
Hi Alex,
Good point about the front-end service endpoint!
I suppose in real life deployments, the proxy / API gateway can indeed be
in front of both the UI server and the API server and the Browser will
observe the same host/port but different URI paths.
I suppose we could simulate that in the UI module by using helm instead of
plain docker for the getting-started example (i.e. the UI helm will include
a Polaris Server with some fixed version for its image).
Cheers,
Dmitri.
On Thu, Feb 5, 2026 at 8:52 AM Alexandre Dutra <ad...@apache.org> wrote:
> Hi all,
>
> I think I would prefer to stay on the 1:1 model and I would even
> advocate for co-locating the UI with the Polaris server.
>
> My reasons are:
>
> 1) Users would simply direct their browser to the service in front of
> the Polaris deployment, completely eliminating CORS issues.
>
> 2) Quarkus already supports Human-to-Machine flows, such as the
> authorization code grant. It would transparently redirect users to the
> IDP login page if necessary.
>
> 3) For the internal /token endpoint, indeed a simple login page as
> suggested by Dmitri could help, if it mimics the authorization code
> grant flow.
>
> The 1:N model is undoubtedly attractive, as it could serve as a
> central management interface for multiple Polaris deployments.
> However, it introduces significant complexity, and I'm uncertain if we
> have the resources to develop and sustain it. Not to mention that I
> don't think any users have explicitly requested that feature.
>
> Thanks,
> Alex
>
> On Mon, Feb 2, 2026 at 6:03 PM Dmitri Bourlatchkov <di...@apache.org>
> wrote:
> >
> > Good point by Romain about 1:1 vs. N:1 between UI and Polaris Servers.
> >
> > I do agree that the N:1 model with CORS headers requires Polaris Servers
> to
> > be aware of all UI instances, which may be very inconvenient in larger
> > environments.
> >
> > From my POV the key negative point about using an API proxy in UI is
> > passing credentials through it. Otherwise, the proxy is quite valid,
> IMHO.
> >
> > So, in case of OAuth2, the UI should be able to redirect the browser to
> an
> > auth page in an IdP (e.g. Keycloak). That is a pure browser-level
> redirect
> > and should not cause any CORS issues (although I'm not an expert in UI).
> >
> > In case of the "internal" Polaris Authentication flow, currently someone
> > has to POST to the /tokens endpoint in Polaris. Doing that via proxy is
> not
> > ideal from the security perspective, IMHO. Doing a direct POST from JS
> code
> > causes CORS issues. So, how about we host a custom login page in Polaris
> > (no full UI, just the login page), and allow UI to redirect the browser
> to
> > it in a manner similar to OAuth2 flows?
> >
> > Given that the /token endpoint is already deprecated in the Iceberg REST
> > Catalog API, handling the internal login flow via OAuth2 flows might be
> > preferable from that POV too. Polaris effectively acts as an IdP for
> > internal principals anyway.
> >
> > WDYT?
> >
> > Sorry, if this steers the conversation a bit sideways from the original
> > topic, but I believe these issues are interconnected.
> >
> > Thanks,
> > Dmitri.
> >
> > On Mon, Feb 2, 2026 at 4:12 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> >
> > > Hi Romain
> > >
> > > That was my point and the reason why I started the console with 1-1.
> > > Again for dev it’s totally fine but enterprise grade probably need
> extra
> > > work.
> > >
> > > Regards
> > > JB
> > >
> > > Le lun. 2 févr. 2026 à 09:55, Romain Manni-Bucau <
> rmannibucau@gmail.com> a
> > > écrit :
> > >
> > > > Hi,
> > > >
> > > > my 2 cts would be that if you switch to 1-N instead of 1-1 you can't
> just
> > > > rely on the frontend to do the switch since you will desire some
> sort of
> > > > centralized security management so specific backend to avoid to rely
> on
> > > > every backend to be configured the same way to enable smooth
> workflows
> > > > (login -> actions) plus sounds like the backend should handle the
> list of
> > > > instances it aggregates with security for every level?
> > > >
> > > > Indeed it only applies to enterprise grade solution, for dev the
> current
> > > > option is perfect.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog
> > > > <https://dotnetbirdie.github.io/> | Blog <
> https://rmannibucau.github.io/
> > > >
> > > > | Old
> > > > Blog <http://rmannibucau.wordpress.com> | Github
> > > > <https://github.com/rmannibucau> | LinkedIn
> > > > <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > > >
> > >
> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> > > > >
> > > > Javaccino founder (Java/.NET service - contact via linkedin)
> > > >
> > > >
> > > > Le lun. 2 févr. 2026 à 09:24, Jean-Baptiste Onofré <jb...@nanthrax.net>
> a
> > > > écrit :
> > > >
> > > > > Yes I know the change. My point was
> > > > > More for context to everyone, in order to understand the
> deployment and
> > > > > behavior.
> > > > >
> > > > > Thanks for your work on workspaces. As said, I will take a look.
> > > > >
> > > > > Regards
> > > > > JB
> > > > >
> > > > > Le lun. 2 févr. 2026 à 08:49, artur rakhmatulin <
> > > > > artur.rakhmatulin@gmail.com>
> > > > > a écrit :
> > > > >
> > > > > > Hi JB,
> > > > > > Thanks for the clarification and for sharing your experience —
> the
> > > > > > distinction between the two approaches is very helpful.
> > > > > >
> > > > > > Just to clarify the scope of the current PR: it does not
> introduce
> > > any
> > > > > > server-side changes. The workspace concept is purely client-side
> and
> > > > > > user-scoped, with all configuration stored in browser
> LocalStorage.
> > > > > >
> > > > > > Also, a previous change already removed the strict 1 Console = 1
> > > server
> > > > > > limitation in main.
> > > > > > As a result, using a Console with Polaris server now requires
> > > explicit
> > > > > CORS
> > > > > > configuration on the server side.
> > > > > > This adds some setup overhead, but keeps the security model
> explicit
> > > > and
> > > > > > controlled by the server.
> > > > > >
> > > > > > The workspace approach builds on top of this by improving
> usability
> > > > when
> > > > > > working with multiple realms or environments, without changing
> server
> > > > > > assumptions.
> > > > > >
> > > > > > Thanks again for the context.
> > > > > >
> > > > > > Best regards, Artur.
> > > > > >
> > > > > > пн, 2 февр. 2026 г. в 10:44, Jean-Baptiste Onofré <
> jb@nanthrax.net>:
> > > > > >
> > > > > > > Hi
> > > > > > >
> > > > > > > Fundamentally, it means about two different approaches:
> > > > > > > 1. Without workspace, it means one Polaris server == one
> Console
> > > > > > > 2. With workspaces, it means one Console == several Polaris
> servers
> > > > > > >
> > > > > > > Initially, the intent was (1), but we discussed (2) as well.
> > > > > > > Personally, when I started the Console, I was more (1) as it's
> > > easier
> > > > > in
> > > > > > > terms of infrastructure (local to the server) and security (no
> > > proxy,
> > > > > > etc),
> > > > > > > and the Console doesn't need any state/storage for the access
> to
> > > the
> > > > > > > different servers.
> > > > > > >
> > > > > > > I'm fine with the workspaces, even if it's a change in the
> > > paradigm.
> > > > > > >
> > > > > > > I will take a look at the workspaces PR.
> > > > > > >
> > > > > > > Regards
> > > > > > > JB
> > > > > > >
> > > > > > > On Sun, Feb 1, 2026 at 8:24 PM artur rakhmatulin <
> > > > > > > artur.rakhmatulin@gmail.com> wrote:
> > > > > > >
> > > > > > > > Hi all,
> > > > > > > > I’d like to start a discussion on introducing "workspaces"
> in the
> > > > > > Polaris
> > > > > > > > Console UI.
> > > > > > > >
> > > > > > > > The idea is to move away from environment-variable–based
> > > > > configuration
> > > > > > > > toward a UI-managed model, where a workspace represents an
> > > isolated
> > > > > > > Polaris
> > > > > > > > context (server, realm, and authentication). This allows a
> single
> > > > > > console
> > > > > > > > instance to work with multiple realms and Polaris
> environments
> > > in a
> > > > > > clean
> > > > > > > > and scalable way.
> > > > > > > >
> > > > > > > > A preliminary PR is available for review [1]
> > > > > > > >
> > > > > > > > Thanks, Artur.
> > > > > > > >
> > > > > > > > [1]: https://github.com/apache/polaris-tools/pull/138
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards, Artur Rakhmatulin
> > > > > > e-mail: artur.rakhmatulin@gmail.com,
> > > > > > telegram: https://t.me/binarycat0
> > > > > >
> > > > >
> > > >
> > >
>
Re: [DISCUSS] Introducing workspaces in Polaris Console UI
Posted by Alexandre Dutra <ad...@apache.org>.
Hi all,
I think I would prefer to stay on the 1:1 model and I would even
advocate for co-locating the UI with the Polaris server.
My reasons are:
1) Users would simply direct their browser to the service in front of
the Polaris deployment, completely eliminating CORS issues.
2) Quarkus already supports Human-to-Machine flows, such as the
authorization code grant. It would transparently redirect users to the
IDP login page if necessary.
3) For the internal /token endpoint, indeed a simple login page as
suggested by Dmitri could help, if it mimics the authorization code
grant flow.
The 1:N model is undoubtedly attractive, as it could serve as a
central management interface for multiple Polaris deployments.
However, it introduces significant complexity, and I'm uncertain if we
have the resources to develop and sustain it. Not to mention that I
don't think any users have explicitly requested that feature.
Thanks,
Alex
On Mon, Feb 2, 2026 at 6:03 PM Dmitri Bourlatchkov <di...@apache.org> wrote:
>
> Good point by Romain about 1:1 vs. N:1 between UI and Polaris Servers.
>
> I do agree that the N:1 model with CORS headers requires Polaris Servers to
> be aware of all UI instances, which may be very inconvenient in larger
> environments.
>
> From my POV the key negative point about using an API proxy in UI is
> passing credentials through it. Otherwise, the proxy is quite valid, IMHO.
>
> So, in case of OAuth2, the UI should be able to redirect the browser to an
> auth page in an IdP (e.g. Keycloak). That is a pure browser-level redirect
> and should not cause any CORS issues (although I'm not an expert in UI).
>
> In case of the "internal" Polaris Authentication flow, currently someone
> has to POST to the /tokens endpoint in Polaris. Doing that via proxy is not
> ideal from the security perspective, IMHO. Doing a direct POST from JS code
> causes CORS issues. So, how about we host a custom login page in Polaris
> (no full UI, just the login page), and allow UI to redirect the browser to
> it in a manner similar to OAuth2 flows?
>
> Given that the /token endpoint is already deprecated in the Iceberg REST
> Catalog API, handling the internal login flow via OAuth2 flows might be
> preferable from that POV too. Polaris effectively acts as an IdP for
> internal principals anyway.
>
> WDYT?
>
> Sorry, if this steers the conversation a bit sideways from the original
> topic, but I believe these issues are interconnected.
>
> Thanks,
> Dmitri.
>
> On Mon, Feb 2, 2026 at 4:12 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> > Hi Romain
> >
> > That was my point and the reason why I started the console with 1-1.
> > Again for dev it’s totally fine but enterprise grade probably need extra
> > work.
> >
> > Regards
> > JB
> >
> > Le lun. 2 févr. 2026 à 09:55, Romain Manni-Bucau <rm...@gmail.com> a
> > écrit :
> >
> > > Hi,
> > >
> > > my 2 cts would be that if you switch to 1-N instead of 1-1 you can't just
> > > rely on the frontend to do the switch since you will desire some sort of
> > > centralized security management so specific backend to avoid to rely on
> > > every backend to be configured the same way to enable smooth workflows
> > > (login -> actions) plus sounds like the backend should handle the list of
> > > instances it aggregates with security for every level?
> > >
> > > Indeed it only applies to enterprise grade solution, for dev the current
> > > option is perfect.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog
> > > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/
> > >
> > > | Old
> > > Blog <http://rmannibucau.wordpress.com> | Github
> > > <https://github.com/rmannibucau> | LinkedIn
> > > <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> > > >
> > > Javaccino founder (Java/.NET service - contact via linkedin)
> > >
> > >
> > > Le lun. 2 févr. 2026 à 09:24, Jean-Baptiste Onofré <jb...@nanthrax.net> a
> > > écrit :
> > >
> > > > Yes I know the change. My point was
> > > > More for context to everyone, in order to understand the deployment and
> > > > behavior.
> > > >
> > > > Thanks for your work on workspaces. As said, I will take a look.
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > Le lun. 2 févr. 2026 à 08:49, artur rakhmatulin <
> > > > artur.rakhmatulin@gmail.com>
> > > > a écrit :
> > > >
> > > > > Hi JB,
> > > > > Thanks for the clarification and for sharing your experience — the
> > > > > distinction between the two approaches is very helpful.
> > > > >
> > > > > Just to clarify the scope of the current PR: it does not introduce
> > any
> > > > > server-side changes. The workspace concept is purely client-side and
> > > > > user-scoped, with all configuration stored in browser LocalStorage.
> > > > >
> > > > > Also, a previous change already removed the strict 1 Console = 1
> > server
> > > > > limitation in main.
> > > > > As a result, using a Console with Polaris server now requires
> > explicit
> > > > CORS
> > > > > configuration on the server side.
> > > > > This adds some setup overhead, but keeps the security model explicit
> > > and
> > > > > controlled by the server.
> > > > >
> > > > > The workspace approach builds on top of this by improving usability
> > > when
> > > > > working with multiple realms or environments, without changing server
> > > > > assumptions.
> > > > >
> > > > > Thanks again for the context.
> > > > >
> > > > > Best regards, Artur.
> > > > >
> > > > > пн, 2 февр. 2026 г. в 10:44, Jean-Baptiste Onofré <jb...@nanthrax.net>:
> > > > >
> > > > > > Hi
> > > > > >
> > > > > > Fundamentally, it means about two different approaches:
> > > > > > 1. Without workspace, it means one Polaris server == one Console
> > > > > > 2. With workspaces, it means one Console == several Polaris servers
> > > > > >
> > > > > > Initially, the intent was (1), but we discussed (2) as well.
> > > > > > Personally, when I started the Console, I was more (1) as it's
> > easier
> > > > in
> > > > > > terms of infrastructure (local to the server) and security (no
> > proxy,
> > > > > etc),
> > > > > > and the Console doesn't need any state/storage for the access to
> > the
> > > > > > different servers.
> > > > > >
> > > > > > I'm fine with the workspaces, even if it's a change in the
> > paradigm.
> > > > > >
> > > > > > I will take a look at the workspaces PR.
> > > > > >
> > > > > > Regards
> > > > > > JB
> > > > > >
> > > > > > On Sun, Feb 1, 2026 at 8:24 PM artur rakhmatulin <
> > > > > > artur.rakhmatulin@gmail.com> wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > > I’d like to start a discussion on introducing "workspaces" in the
> > > > > Polaris
> > > > > > > Console UI.
> > > > > > >
> > > > > > > The idea is to move away from environment-variable–based
> > > > configuration
> > > > > > > toward a UI-managed model, where a workspace represents an
> > isolated
> > > > > > Polaris
> > > > > > > context (server, realm, and authentication). This allows a single
> > > > > console
> > > > > > > instance to work with multiple realms and Polaris environments
> > in a
> > > > > clean
> > > > > > > and scalable way.
> > > > > > >
> > > > > > > A preliminary PR is available for review [1]
> > > > > > >
> > > > > > > Thanks, Artur.
> > > > > > >
> > > > > > > [1]: https://github.com/apache/polaris-tools/pull/138
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards, Artur Rakhmatulin
> > > > > e-mail: artur.rakhmatulin@gmail.com,
> > > > > telegram: https://t.me/binarycat0
> > > > >
> > > >
> > >
> >
Re: [DISCUSS] Introducing workspaces in Polaris Console UI
Posted by Dmitri Bourlatchkov <di...@apache.org>.
Good point by Romain about 1:1 vs. N:1 between UI and Polaris Servers.
I do agree that the N:1 model with CORS headers requires Polaris Servers to
be aware of all UI instances, which may be very inconvenient in larger
environments.
From my POV the key negative point about using an API proxy in UI is
passing credentials through it. Otherwise, the proxy is quite valid, IMHO.
So, in case of OAuth2, the UI should be able to redirect the browser to an
auth page in an IdP (e.g. Keycloak). That is a pure browser-level redirect
and should not cause any CORS issues (although I'm not an expert in UI).
In case of the "internal" Polaris Authentication flow, currently someone
has to POST to the /tokens endpoint in Polaris. Doing that via proxy is not
ideal from the security perspective, IMHO. Doing a direct POST from JS code
causes CORS issues. So, how about we host a custom login page in Polaris
(no full UI, just the login page), and allow UI to redirect the browser to
it in a manner similar to OAuth2 flows?
Given that the /token endpoint is already deprecated in the Iceberg REST
Catalog API, handling the internal login flow via OAuth2 flows might be
preferable from that POV too. Polaris effectively acts as an IdP for
internal principals anyway.
WDYT?
Sorry, if this steers the conversation a bit sideways from the original
topic, but I believe these issues are interconnected.
Thanks,
Dmitri.
On Mon, Feb 2, 2026 at 4:12 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Romain
>
> That was my point and the reason why I started the console with 1-1.
> Again for dev it’s totally fine but enterprise grade probably need extra
> work.
>
> Regards
> JB
>
> Le lun. 2 févr. 2026 à 09:55, Romain Manni-Bucau <rm...@gmail.com> a
> écrit :
>
> > Hi,
> >
> > my 2 cts would be that if you switch to 1-N instead of 1-1 you can't just
> > rely on the frontend to do the switch since you will desire some sort of
> > centralized security management so specific backend to avoid to rely on
> > every backend to be configured the same way to enable smooth workflows
> > (login -> actions) plus sounds like the backend should handle the list of
> > instances it aggregates with security for every level?
> >
> > Indeed it only applies to enterprise grade solution, for dev the current
> > option is perfect.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://x.com/rmannibucau> | .NET Blog
> > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/
> >
> > | Old
> > Blog <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> > >
> > Javaccino founder (Java/.NET service - contact via linkedin)
> >
> >
> > Le lun. 2 févr. 2026 à 09:24, Jean-Baptiste Onofré <jb...@nanthrax.net> a
> > écrit :
> >
> > > Yes I know the change. My point was
> > > More for context to everyone, in order to understand the deployment and
> > > behavior.
> > >
> > > Thanks for your work on workspaces. As said, I will take a look.
> > >
> > > Regards
> > > JB
> > >
> > > Le lun. 2 févr. 2026 à 08:49, artur rakhmatulin <
> > > artur.rakhmatulin@gmail.com>
> > > a écrit :
> > >
> > > > Hi JB,
> > > > Thanks for the clarification and for sharing your experience — the
> > > > distinction between the two approaches is very helpful.
> > > >
> > > > Just to clarify the scope of the current PR: it does not introduce
> any
> > > > server-side changes. The workspace concept is purely client-side and
> > > > user-scoped, with all configuration stored in browser LocalStorage.
> > > >
> > > > Also, a previous change already removed the strict 1 Console = 1
> server
> > > > limitation in main.
> > > > As a result, using a Console with Polaris server now requires
> explicit
> > > CORS
> > > > configuration on the server side.
> > > > This adds some setup overhead, but keeps the security model explicit
> > and
> > > > controlled by the server.
> > > >
> > > > The workspace approach builds on top of this by improving usability
> > when
> > > > working with multiple realms or environments, without changing server
> > > > assumptions.
> > > >
> > > > Thanks again for the context.
> > > >
> > > > Best regards, Artur.
> > > >
> > > > пн, 2 февр. 2026 г. в 10:44, Jean-Baptiste Onofré <jb...@nanthrax.net>:
> > > >
> > > > > Hi
> > > > >
> > > > > Fundamentally, it means about two different approaches:
> > > > > 1. Without workspace, it means one Polaris server == one Console
> > > > > 2. With workspaces, it means one Console == several Polaris servers
> > > > >
> > > > > Initially, the intent was (1), but we discussed (2) as well.
> > > > > Personally, when I started the Console, I was more (1) as it's
> easier
> > > in
> > > > > terms of infrastructure (local to the server) and security (no
> proxy,
> > > > etc),
> > > > > and the Console doesn't need any state/storage for the access to
> the
> > > > > different servers.
> > > > >
> > > > > I'm fine with the workspaces, even if it's a change in the
> paradigm.
> > > > >
> > > > > I will take a look at the workspaces PR.
> > > > >
> > > > > Regards
> > > > > JB
> > > > >
> > > > > On Sun, Feb 1, 2026 at 8:24 PM artur rakhmatulin <
> > > > > artur.rakhmatulin@gmail.com> wrote:
> > > > >
> > > > > > Hi all,
> > > > > > I’d like to start a discussion on introducing "workspaces" in the
> > > > Polaris
> > > > > > Console UI.
> > > > > >
> > > > > > The idea is to move away from environment-variable–based
> > > configuration
> > > > > > toward a UI-managed model, where a workspace represents an
> isolated
> > > > > Polaris
> > > > > > context (server, realm, and authentication). This allows a single
> > > > console
> > > > > > instance to work with multiple realms and Polaris environments
> in a
> > > > clean
> > > > > > and scalable way.
> > > > > >
> > > > > > A preliminary PR is available for review [1]
> > > > > >
> > > > > > Thanks, Artur.
> > > > > >
> > > > > > [1]: https://github.com/apache/polaris-tools/pull/138
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best regards, Artur Rakhmatulin
> > > > e-mail: artur.rakhmatulin@gmail.com,
> > > > telegram: https://t.me/binarycat0
> > > >
> > >
> >
>
Re: [DISCUSS] Introducing workspaces in Polaris Console UI
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Romain
That was my point and the reason why I started the console with 1-1.
Again for dev it’s totally fine but enterprise grade probably need extra
work.
Regards
JB
Le lun. 2 févr. 2026 à 09:55, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
> Hi,
>
> my 2 cts would be that if you switch to 1-N instead of 1-1 you can't just
> rely on the frontend to do the switch since you will desire some sort of
> centralized security management so specific backend to avoid to rely on
> every backend to be configured the same way to enable smooth workflows
> (login -> actions) plus sounds like the backend should handle the list of
> instances it aggregates with security for every level?
>
> Indeed it only applies to enterprise grade solution, for dev the current
> option is perfect.
>
> Romain Manni-Bucau
> @rmannibucau <https://x.com/rmannibucau> | .NET Blog
> <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/>
> | Old
> Blog <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> >
> Javaccino founder (Java/.NET service - contact via linkedin)
>
>
> Le lun. 2 févr. 2026 à 09:24, Jean-Baptiste Onofré <jb...@nanthrax.net> a
> écrit :
>
> > Yes I know the change. My point was
> > More for context to everyone, in order to understand the deployment and
> > behavior.
> >
> > Thanks for your work on workspaces. As said, I will take a look.
> >
> > Regards
> > JB
> >
> > Le lun. 2 févr. 2026 à 08:49, artur rakhmatulin <
> > artur.rakhmatulin@gmail.com>
> > a écrit :
> >
> > > Hi JB,
> > > Thanks for the clarification and for sharing your experience — the
> > > distinction between the two approaches is very helpful.
> > >
> > > Just to clarify the scope of the current PR: it does not introduce any
> > > server-side changes. The workspace concept is purely client-side and
> > > user-scoped, with all configuration stored in browser LocalStorage.
> > >
> > > Also, a previous change already removed the strict 1 Console = 1 server
> > > limitation in main.
> > > As a result, using a Console with Polaris server now requires explicit
> > CORS
> > > configuration on the server side.
> > > This adds some setup overhead, but keeps the security model explicit
> and
> > > controlled by the server.
> > >
> > > The workspace approach builds on top of this by improving usability
> when
> > > working with multiple realms or environments, without changing server
> > > assumptions.
> > >
> > > Thanks again for the context.
> > >
> > > Best regards, Artur.
> > >
> > > пн, 2 февр. 2026 г. в 10:44, Jean-Baptiste Onofré <jb...@nanthrax.net>:
> > >
> > > > Hi
> > > >
> > > > Fundamentally, it means about two different approaches:
> > > > 1. Without workspace, it means one Polaris server == one Console
> > > > 2. With workspaces, it means one Console == several Polaris servers
> > > >
> > > > Initially, the intent was (1), but we discussed (2) as well.
> > > > Personally, when I started the Console, I was more (1) as it's easier
> > in
> > > > terms of infrastructure (local to the server) and security (no proxy,
> > > etc),
> > > > and the Console doesn't need any state/storage for the access to the
> > > > different servers.
> > > >
> > > > I'm fine with the workspaces, even if it's a change in the paradigm.
> > > >
> > > > I will take a look at the workspaces PR.
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > On Sun, Feb 1, 2026 at 8:24 PM artur rakhmatulin <
> > > > artur.rakhmatulin@gmail.com> wrote:
> > > >
> > > > > Hi all,
> > > > > I’d like to start a discussion on introducing "workspaces" in the
> > > Polaris
> > > > > Console UI.
> > > > >
> > > > > The idea is to move away from environment-variable–based
> > configuration
> > > > > toward a UI-managed model, where a workspace represents an isolated
> > > > Polaris
> > > > > context (server, realm, and authentication). This allows a single
> > > console
> > > > > instance to work with multiple realms and Polaris environments in a
> > > clean
> > > > > and scalable way.
> > > > >
> > > > > A preliminary PR is available for review [1]
> > > > >
> > > > > Thanks, Artur.
> > > > >
> > > > > [1]: https://github.com/apache/polaris-tools/pull/138
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best regards, Artur Rakhmatulin
> > > e-mail: artur.rakhmatulin@gmail.com,
> > > telegram: https://t.me/binarycat0
> > >
> >
>
Re: [DISCUSS] Introducing workspaces in Polaris Console UI
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
my 2 cts would be that if you switch to 1-N instead of 1-1 you can't just
rely on the frontend to do the switch since you will desire some sort of
centralized security management so specific backend to avoid to rely on
every backend to be configured the same way to enable smooth workflows
(login -> actions) plus sounds like the backend should handle the list of
instances it aggregates with security for every level?
Indeed it only applies to enterprise grade solution, for dev the current
option is perfect.
Romain Manni-Bucau
@rmannibucau <https://x.com/rmannibucau> | .NET Blog
<https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old
Blog <http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064>
Javaccino founder (Java/.NET service - contact via linkedin)
Le lun. 2 févr. 2026 à 09:24, Jean-Baptiste Onofré <jb...@nanthrax.net> a
écrit :
> Yes I know the change. My point was
> More for context to everyone, in order to understand the deployment and
> behavior.
>
> Thanks for your work on workspaces. As said, I will take a look.
>
> Regards
> JB
>
> Le lun. 2 févr. 2026 à 08:49, artur rakhmatulin <
> artur.rakhmatulin@gmail.com>
> a écrit :
>
> > Hi JB,
> > Thanks for the clarification and for sharing your experience — the
> > distinction between the two approaches is very helpful.
> >
> > Just to clarify the scope of the current PR: it does not introduce any
> > server-side changes. The workspace concept is purely client-side and
> > user-scoped, with all configuration stored in browser LocalStorage.
> >
> > Also, a previous change already removed the strict 1 Console = 1 server
> > limitation in main.
> > As a result, using a Console with Polaris server now requires explicit
> CORS
> > configuration on the server side.
> > This adds some setup overhead, but keeps the security model explicit and
> > controlled by the server.
> >
> > The workspace approach builds on top of this by improving usability when
> > working with multiple realms or environments, without changing server
> > assumptions.
> >
> > Thanks again for the context.
> >
> > Best regards, Artur.
> >
> > пн, 2 февр. 2026 г. в 10:44, Jean-Baptiste Onofré <jb...@nanthrax.net>:
> >
> > > Hi
> > >
> > > Fundamentally, it means about two different approaches:
> > > 1. Without workspace, it means one Polaris server == one Console
> > > 2. With workspaces, it means one Console == several Polaris servers
> > >
> > > Initially, the intent was (1), but we discussed (2) as well.
> > > Personally, when I started the Console, I was more (1) as it's easier
> in
> > > terms of infrastructure (local to the server) and security (no proxy,
> > etc),
> > > and the Console doesn't need any state/storage for the access to the
> > > different servers.
> > >
> > > I'm fine with the workspaces, even if it's a change in the paradigm.
> > >
> > > I will take a look at the workspaces PR.
> > >
> > > Regards
> > > JB
> > >
> > > On Sun, Feb 1, 2026 at 8:24 PM artur rakhmatulin <
> > > artur.rakhmatulin@gmail.com> wrote:
> > >
> > > > Hi all,
> > > > I’d like to start a discussion on introducing "workspaces" in the
> > Polaris
> > > > Console UI.
> > > >
> > > > The idea is to move away from environment-variable–based
> configuration
> > > > toward a UI-managed model, where a workspace represents an isolated
> > > Polaris
> > > > context (server, realm, and authentication). This allows a single
> > console
> > > > instance to work with multiple realms and Polaris environments in a
> > clean
> > > > and scalable way.
> > > >
> > > > A preliminary PR is available for review [1]
> > > >
> > > > Thanks, Artur.
> > > >
> > > > [1]: https://github.com/apache/polaris-tools/pull/138
> > > >
> > >
> >
> >
> > --
> > Best regards, Artur Rakhmatulin
> > e-mail: artur.rakhmatulin@gmail.com,
> > telegram: https://t.me/binarycat0
> >
>
Re: [DISCUSS] Introducing workspaces in Polaris Console UI
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Yes I know the change. My point was
More for context to everyone, in order to understand the deployment and
behavior.
Thanks for your work on workspaces. As said, I will take a look.
Regards
JB
Le lun. 2 févr. 2026 à 08:49, artur rakhmatulin <ar...@gmail.com>
a écrit :
> Hi JB,
> Thanks for the clarification and for sharing your experience — the
> distinction between the two approaches is very helpful.
>
> Just to clarify the scope of the current PR: it does not introduce any
> server-side changes. The workspace concept is purely client-side and
> user-scoped, with all configuration stored in browser LocalStorage.
>
> Also, a previous change already removed the strict 1 Console = 1 server
> limitation in main.
> As a result, using a Console with Polaris server now requires explicit CORS
> configuration on the server side.
> This adds some setup overhead, but keeps the security model explicit and
> controlled by the server.
>
> The workspace approach builds on top of this by improving usability when
> working with multiple realms or environments, without changing server
> assumptions.
>
> Thanks again for the context.
>
> Best regards, Artur.
>
> пн, 2 февр. 2026 г. в 10:44, Jean-Baptiste Onofré <jb...@nanthrax.net>:
>
> > Hi
> >
> > Fundamentally, it means about two different approaches:
> > 1. Without workspace, it means one Polaris server == one Console
> > 2. With workspaces, it means one Console == several Polaris servers
> >
> > Initially, the intent was (1), but we discussed (2) as well.
> > Personally, when I started the Console, I was more (1) as it's easier in
> > terms of infrastructure (local to the server) and security (no proxy,
> etc),
> > and the Console doesn't need any state/storage for the access to the
> > different servers.
> >
> > I'm fine with the workspaces, even if it's a change in the paradigm.
> >
> > I will take a look at the workspaces PR.
> >
> > Regards
> > JB
> >
> > On Sun, Feb 1, 2026 at 8:24 PM artur rakhmatulin <
> > artur.rakhmatulin@gmail.com> wrote:
> >
> > > Hi all,
> > > I’d like to start a discussion on introducing "workspaces" in the
> Polaris
> > > Console UI.
> > >
> > > The idea is to move away from environment-variable–based configuration
> > > toward a UI-managed model, where a workspace represents an isolated
> > Polaris
> > > context (server, realm, and authentication). This allows a single
> console
> > > instance to work with multiple realms and Polaris environments in a
> clean
> > > and scalable way.
> > >
> > > A preliminary PR is available for review [1]
> > >
> > > Thanks, Artur.
> > >
> > > [1]: https://github.com/apache/polaris-tools/pull/138
> > >
> >
>
>
> --
> Best regards, Artur Rakhmatulin
> e-mail: artur.rakhmatulin@gmail.com,
> telegram: https://t.me/binarycat0
>
Re: [DISCUSS] Introducing workspaces in Polaris Console UI
Posted by artur rakhmatulin <ar...@gmail.com>.
Hi JB,
Thanks for the clarification and for sharing your experience — the
distinction between the two approaches is very helpful.
Just to clarify the scope of the current PR: it does not introduce any
server-side changes. The workspace concept is purely client-side and
user-scoped, with all configuration stored in browser LocalStorage.
Also, a previous change already removed the strict 1 Console = 1 server
limitation in main.
As a result, using a Console with Polaris server now requires explicit CORS
configuration on the server side.
This adds some setup overhead, but keeps the security model explicit and
controlled by the server.
The workspace approach builds on top of this by improving usability when
working with multiple realms or environments, without changing server
assumptions.
Thanks again for the context.
Best regards, Artur.
пн, 2 февр. 2026 г. в 10:44, Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Hi
>
> Fundamentally, it means about two different approaches:
> 1. Without workspace, it means one Polaris server == one Console
> 2. With workspaces, it means one Console == several Polaris servers
>
> Initially, the intent was (1), but we discussed (2) as well.
> Personally, when I started the Console, I was more (1) as it's easier in
> terms of infrastructure (local to the server) and security (no proxy, etc),
> and the Console doesn't need any state/storage for the access to the
> different servers.
>
> I'm fine with the workspaces, even if it's a change in the paradigm.
>
> I will take a look at the workspaces PR.
>
> Regards
> JB
>
> On Sun, Feb 1, 2026 at 8:24 PM artur rakhmatulin <
> artur.rakhmatulin@gmail.com> wrote:
>
> > Hi all,
> > I’d like to start a discussion on introducing "workspaces" in the Polaris
> > Console UI.
> >
> > The idea is to move away from environment-variable–based configuration
> > toward a UI-managed model, where a workspace represents an isolated
> Polaris
> > context (server, realm, and authentication). This allows a single console
> > instance to work with multiple realms and Polaris environments in a clean
> > and scalable way.
> >
> > A preliminary PR is available for review [1]
> >
> > Thanks, Artur.
> >
> > [1]: https://github.com/apache/polaris-tools/pull/138
> >
>
--
Best regards, Artur Rakhmatulin
e-mail: artur.rakhmatulin@gmail.com,
telegram: https://t.me/binarycat0
Re: [DISCUSS] Introducing workspaces in Polaris Console UI
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi
Fundamentally, it means about two different approaches:
1. Without workspace, it means one Polaris server == one Console
2. With workspaces, it means one Console == several Polaris servers
Initially, the intent was (1), but we discussed (2) as well.
Personally, when I started the Console, I was more (1) as it's easier in
terms of infrastructure (local to the server) and security (no proxy, etc),
and the Console doesn't need any state/storage for the access to the
different servers.
I'm fine with the workspaces, even if it's a change in the paradigm.
I will take a look at the workspaces PR.
Regards
JB
On Sun, Feb 1, 2026 at 8:24 PM artur rakhmatulin <
artur.rakhmatulin@gmail.com> wrote:
> Hi all,
> I’d like to start a discussion on introducing "workspaces" in the Polaris
> Console UI.
>
> The idea is to move away from environment-variable–based configuration
> toward a UI-managed model, where a workspace represents an isolated Polaris
> context (server, realm, and authentication). This allows a single console
> instance to work with multiple realms and Polaris environments in a clean
> and scalable way.
>
> A preliminary PR is available for review [1]
>
> Thanks, Artur.
>
> [1]: https://github.com/apache/polaris-tools/pull/138
>