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 <[email protected]> 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 < > [email protected]> 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 <[email protected]>: > > > > > 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 <[email protected]> > > 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 <[email protected] > > > > > > 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é < > [email protected] > > > > > > > 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 < > > > > [email protected]> 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é < > > > [email protected]> > > > > 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 < > > > > > > > > [email protected]> > > > > > > > > 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é < > > > > [email protected]>: > > > > > > > > > > > > > > > > > > > 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 < > > > > > > > > > > [email protected]> 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: [email protected], > > > > > > > > > telegram: https://t.me/binarycat0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Best regards, Artur Rakhmatulin > > e-mail: [email protected], > > telegram: https://t.me/binarycat0 > > >
