Hi all, I'd like to revive this discussion because the proxy-authentication work in `polaris-tools` PR #260 makes the server-integration question more concrete.
In June I was fine with keeping the first Console release in `polaris-tools`, but explicitly left the main-repository and server-bundling question open. The Console already implements a browser-side PKCE flow. PR #260 now starts adding a second, proxy-specific model for user information, session failures, logout, and reauthentication. I think that is too much security-sensitive behavior for a mostly static UI. My preference is to serve the static Console assets from `polaris-server` and let Quarkus own the browser-facing OAuth/OIDC flow and session. The Console would then only consume the authenticated identity and APIs. This is independent of whether the Console is enabled or exposed by default. Could we revisit that architecture now? Cheers, Robert [260] https://github.com/apache/polaris-tools/pull/260 On Wed, Jun 3, 2026 at 9:37 AM Robert Stupp <[email protected]> wrote: > Hi, > > I am fine with keeping the first Console release in polaris-tools if that > helps move the release forward. > > I just like to avoid treating this as a conclusion on the broader > repository/artifact question. > To me, "the Console is a REST client" is a useful deployment observation, > but not a deciding argument for repository location or future artifact > shape. > > So from my side, polaris-tools for the first release sounds fine as a > pragmatic step. > However, I expect the main-repo/server-bundling question to remain open > for a follow-up discussion after that initial release. > > For that follow-up, I think we should come back to JB's original goals: > * Improving Console visibility > * Making contributions easier > * Keeping releases aligned with Polaris API changes > * Ensuring docs and deployment examples stay in sync with the server > > Robert > > On Tue, Jun 2, 2026 at 7:10 PM Jean-Baptiste Onofré <[email protected]> > wrote: > >> Hi >> >> I agree with the isolation. However the original discussion focused more >> on >> contributions and visibility, not technical/packaging isolation. >> >> I also think that the website can give more space to the "clients" ( >> https://polaris.apache.org/tools/ can be emphasized). >> Also, a composable docker/sidecar documenting how to enable the console >> should probably give more visibility. >> >> So, here's my consensus proposal: >> 1. For now, let's keep the console in the polaris-tools repo >> 2. Move forward quickly on a first release and update our >> documentation/docker-compose to easily give users the option to enable the >> console >> 3. Give more space to "clients" on the website >> >> I will work on these items. >> >> Regards >> JB >> >> On Tue, Jun 2, 2026 at 7:02 PM Yufei Gu <[email protected]> wrote: >> >> > Given this discussion [1], I don't think putting the UI in the server >> image >> > makes sense at this point. We could revisit that decision in the future >> if >> > the Console evolves into a multi tenant web application. >> > >> > If we continue to treat the Console as a separately deployed REST >> client, >> > I'm not convinced there is a strong reason to move it into the main >> repo. >> > This seems consistent with the position taken in the earlier MCP >> discussion >> > [2][3]: >> > >> > If MCP server goes in polaris main repo, than other tools could be >> > > there too (console, catalog migrator, etc). But I don't think it's a >> > > good idea due to the LICENSE/NOTICE overhead and also clear separation >> > > of concerns. >> > >> > >> > I think the MCP server is a "client" for the Polaris server, like the >> > > CLI or the Console (UI). >> > > So, maybe it's worth considering polaris-tools as a host (it's what >> > > I'm doing to the Polaris Console). >> > >> > >> > To me, the same reasoning still applies. If the Console remains an >> > independent client that interacts with Polaris exclusively through REST >> > APIs, keeping it separate preserves a clear separation of concerns and >> > allows it to evolve independently. Moving it into the main repo would >> > therefore require a stronger justification. >> > >> > 1. https://lists.apache.org/thread/v4jqvfdw0myxkgfzb01t2787nz7oyzbw >> > 2. https://lists.apache.org/thread/539p26bwk7zh1p4d1jqyhh2pqkkh0n36 >> > 3. https://lists.apache.org/thread/yj98vol73dhpvygmyxm23sgjbnf7zfsd >> > >> > Yufei >> > >> > >> > On Tue, Jun 2, 2026 at 7:59 AM Dmitri Bourlatchkov <[email protected]> >> > wrote: >> > >> > > Hi JB, >> > > >> > > This plan sounds good to me. >> > > >> > > While packaging the UI in the same image as the server may help fresh >> > > users, keeping a separate UI image will likely have less impact on >> > existing >> > > deployments. Docker compose profiles seem like a good middle ground >> from >> > > the UX perspective. >> > > >> > > Cheers, >> > > Dmitri. >> > > >> > > On Tue, Jun 2, 2026 at 7:22 AM Jean-Baptiste Onofré <[email protected]> >> > > wrote: >> > > >> > > > Hi, >> > > > >> > > > To provide some perspective based on my experience with other Apache >> > > > projects that include a UI by default (such as ActiveMQ, NiFi, >> Druid, >> > and >> > > > Hop), I don't believe the console necessarily needs to be enabled by >> > > > default. While a seamless out-of-the-box user experience is key for >> > > getting >> > > > started quickly with Polaris, we must also recognize that console >> > > > requirements vary depending on the deployment. >> > > > >> > > > I propose keeping the Polaris server distribution and Docker image >> > > focused >> > > > solely on the server as they are today. We can then offer the >> console >> > > (and >> > > > potentially other REST clients) as a sidecar or composable >> container. >> > > Using >> > > > Docker Compose profiles, we could structure it like this: >> > > > >> > > > services: >> > > > console: >> > > > image: polaris-console... >> > > > profiles: [console] >> > > > server: >> > > > image: polaris-server... >> > > > >> > > > Users could then simply run docker compose --profile console up to >> > > include >> > > > the UI. >> > > > >> > > > In summary, I propose: >> > > > >> > > > 1. Moving the console code to a module within the main repository >> to >> > > > improve visibility and contributions. >> > > > 2. Providing a Docker Compose setup with profiles and updating the >> > Helm >> > > > chart to include the console as an optional component. >> > > > >> > > > Thoughts? >> > > > >> > > > Regards, >> > > > JB >> > > > >> > > > >> > > > >> > > > On Tue, Jun 2, 2026 at 3:21 AM Yufei Gu <[email protected]> >> wrote: >> > > > >> > > > > I think the Console is essentially a REST client, so I’m not sure >> it >> > > > should >> > > > > belong to the server Docker image by default. >> > > > > >> > > > > Could we publish it as a separate client artifact instead, for >> > example >> > > to >> > > > > PyPI or a similar distribution channel, depending on the >> > > implementation? >> > > > > That would keep the server image focused on serving the API, while >> > > still >> > > > > making the Console easy to install, release, and consume. >> > > > > >> > > > > We can still keep it in the main repo, but I didn't see much >> benefit >> > of >> > > > > doing so when we treat it as a separate deployable component. >> > > > > >> > > > > Yufei >> > > > > >> > > > > >> > > > > On Mon, Jun 1, 2026 at 12:02 PM Romain Manni-Bucau < >> > > > [email protected]> >> > > > > wrote: >> > > > > >> > > > > > I like the on by default in docker, off by default in helm >> > > compromise - >> > > > > > that said it still makes sense to split it for prod if desired >> > cause >> > > it >> > > > > > will not use the same service/httproute at all IMHO, one will be >> > > public >> > > > > > like versus the other can stay internal most of the time. >> > > > > > >> > > > > > 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. 1 juin 2026 à 20:14, Yong Zheng < >> [email protected]> >> > a >> > > > > écrit >> > > > > > : >> > > > > > >> > > > > > > Hello, >> > > > > > > >> > > > > > > Why not put them in the same repo but keep them separate >> (similar >> > > to >> > > > > > spark >> > > > > > > plugin which doesn’t get include automatically). Same apply to >> > helm >> > > > as >> > > > > > > people can decide on what to deploy and avoid UI component if >> > > > desired. >> > > > > > > >> > > > > > > As the UI is SPA, the actually calls are from client browser >> as >> > > > opposed >> > > > > > to >> > > > > > > UI pod, the usability may be limited there in certain use >> cases. >> > I >> > > > > would >> > > > > > > start a different ML for this topic. >> > > > > > > >> > > > > > > Thanks, >> > > > > > > Yong Zheng >> > > > > > > >> > > > > > > > On Jun 1, 2026, at 11:52 AM, Dmitri Bourlatchkov < >> > > [email protected] >> > > > > >> > > > > > > wrote: >> > > > > > > > >> > > > > > > > Hi All, >> > > > > > > > >> > > > > > > > The idea of moving the UI to the main repo SGTM. >> > > > > > > > >> > > > > > > > I tend to agree with Romain, that the UI should be easy to >> > > > _disable_ >> > > > > > > > because in production environments it may not be intended to >> > run >> > > at >> > > > > > all, >> > > > > > > or >> > > > > > > > perhaps not on the same nodes as the main Polaris server. >> The >> > > > > > simplicity >> > > > > > > of >> > > > > > > > the UI (static pages + REST API via JS) may not justify >> always >> > > > > running >> > > > > > it >> > > > > > > > from the SRE perspective, I guess. >> > > > > > > > >> > > > > > > > I'm sure there are multiple ways to tackle this in helm. >> For a >> > > > > start, a >> > > > > > > > simple on/off helm value might be sufficient, though. >> > > > > > > > >> > > > > > > > Regarding defaults, how about ON by default in plain docker >> > (for >> > > > > local >> > > > > > > > runs), but OFF by default in helm (mostly for "prod" >> > > environments)? >> > > > > > > > >> > > > > > > > Cheers, >> > > > > > > > Dmitri. >> > > > > > > > >> > > > > > > >> On Mon, Jun 1, 2026 at 11:44 AM Romain Manni-Bucau < >> > > > > > > [email protected]> >> > > > > > > >> wrote: >> > > > > > > >> >> > > > > > > >>> Le lun. 1 juin 2026 à 17:35, Robert Stupp <[email protected]> >> a >> > > > > écrit : >> > > > > > > >>> >> > > > > > > >>> But isn't the concern solved with the configuration option >> > > > "enable >> > > > > > web >> > > > > > > >> UI = >> > > > > > > >>> true|false"? >> > > > > > > >>> >> > > > > > > >> >> > > > > > > >> if default is false it does but breaks the easy by default >> no? >> > > > > > > >> >> > > > > > > >> >> > > > > > > >>> >> > > > > > > >>> With a standalone web UI, as it exists today, everybody >> can >> > run >> > > > it >> > > > > > and >> > > > > > > >>> perform "click-ops." >> > > > > > > >>> Similar for custom built web UIs. >> > > > > > > >>> Or if some user extracts the static files and serves their >> > own >> > > > > > instance >> > > > > > > >>> using a local http daemon. >> > > > > > > >>> >> > > > > > > >>> The web UI doesn't allow anything that cannot be done via >> > > another >> > > > > > > >>> interface, such as a terminal and `curl`. >> > > > > > > >>> >> > > > > > > >> >> > > > > > > >> yes but it is less tempting enough to be sufficient for me >> > > > > > > >> >> > > > > > > >> >> > > > > > > >>> >> > > > > > > >>> With that, I'm not sure maintaining multiple different >> > > > > distributions >> > > > > > > >> really >> > > > > > > >>> helps lock people out of web UIs ("click-ops"). >> > > > > > > >>> >> > > > > > > >> >> > > > > > > >> from my windows integrating the ui is not helping since you >> > need >> > > > the >> > > > > > > >> database anyway so maybe the ui outside is sufficient too >> else >> > > the >> > > > > all >> > > > > > > in >> > > > > > > >> one with h2 or pg will help, i'm not clear on it >> > > > > > > >> >> > > > > > > >> >> > > > > > > >>> >> > > > > > > >>> Robert >> > > > > > > >>> >> > > > > > > >>> >> > > > > > > >>> On Mon, Jun 1, 2026 at 5:15 PM Romain Manni-Bucau < >> > > > > > > [email protected] >> > > > > > > >>> >> > > > > > > >>> wrote: >> > > > > > > >>> >> > > > > > > >>>> Le lun. 1 juin 2026 à 17:12, Robert Stupp < >> [email protected]> >> > a >> > > > > écrit >> > > > > > : >> > > > > > > >>>> >> > > > > > > >>>>> Hi Romain, >> > > > > > > >>>>> >> > > > > > > >>>>> Disabling the console (web UI) is easy once it becomes >> part >> > > of >> > > > > the >> > > > > > > >>>>> polaris-server. >> > > > > > > >>>>> >> > > > > > > >>>>> To clarify, the web UI is a static web resource, it >> doesn't >> > > > > execute >> > > > > > > >>>> web-UI >> > > > > > > >>>>> code in Quarkus. >> > > > > > > >>>>> The UI uses the same authentication and authorization >> > > > mechanisms >> > > > > > that >> > > > > > > >>> any >> > > > > > > >>>>> REST client uses; it is just a UI on top of that. >> > > > > > > >>>>> >> > > > > > > >>>> >> > > > > > > >>>> >> > > > > > > >>>> Yep, this is my issue, it is trivial to use and break the >> > "all >> > > > as >> > > > > > > code" >> > > > > > > >>>> pattern and get back to click-ops pattern. >> > > > > > > >>>> Being API only is less tempting so I'm trying to stick to >> > > that. >> > > > > > > >>>> >> > > > > > > >>>> *Still thinking out loud* but having 3 images sounds the >> > best >> > > of >> > > > > all >> > > > > > > >>>> worlds: >> > > > > > > >>>> >> > > > > > > >>>> * server >> > > > > > > >>>> * frontend/ui >> > > > > > > >>>> * all-in-one (== demo) >> > > > > > > >>>> >> > > > > > > >>>> It is the pattern used by most products (all in one can >> even >> > > > embed >> > > > > > > >>> postgres >> > > > > > > >>>> to really be ready to use) and everybody will be happy >> at a >> > > very >> > > > > low >> > > > > > > >> cost >> > > > > > > >>>> in terms of dev/maintenance and infra IMHO. >> > > > > > > >>>> >> > > > > > > >>>> Hope it makes sense. >> > > > > > > >>>> >> > > > > > > >>>> >> > > > > > > >>>>> >> > > > > > > >>>>> Hope this helps, >> > > > > > > >>>>> >> > > > > > > >>>>> Robert >> > > > > > > >>>>> >> > > > > > > >>>>> >> > > > > > > >>>>> On Mon, Jun 1, 2026 at 4:33 PM Romain Manni-Bucau < >> > > > > > > >>> [email protected] >> > > > > > > >>>>> >> > > > > > > >>>>> wrote: >> > > > > > > >>>>> >> > > > > > > >>>>>> Hi, >> > > > > > > >>>>>> >> > > > > > > >>>>>> as an user I have a small request: can it be disabled >> by >> > > > default >> > > > > > > >> (or >> > > > > > > >>>> made >> > > > > > > >>>>>> unusable by disabling the authn) or at least be made >> easy >> > to >> > > > > > > >> disable >> > > > > > > >>>>>> (corrollar being: can we get a headless docker image, >> > solves >> > > > my >> > > > > > > >>> concern >> > > > > > > >>>>>> too)? >> > > > > > > >>>>>> rational is that when you have everything automated >> around >> > > > > polaris >> > > > > > > >>> you >> > > > > > > >>>>>> don't want the UI to be able to mess up things nor >> render >> > a >> > > > > > > >> different >> > > > > > > >>>>> view. >> > > > > > > >>>>>> not my usage but an in between readonly enforced mode - >> > even >> > > > for >> > > > > > > >>> admin >> > > > > > > >>>>>> users - can be useful I think so maybe 3 modes in >> terms of >> > > > > toggle: >> > > > > > > >>>> Full, >> > > > > > > >>>>>> ReadOnly, Off or alike. >> > > > > > > >>>>>> >> > > > > > > >>>>>> Shouldn't be crazy to do with quarkus but think it is >> an >> > > > > important >> > > > > > > >>>>> feature >> > > > > > > >>>>>> to integrate it cleanly as a global solution. >> > > > > > > >>>>>> >> > > > > > > >>>>>> the tricky part is to make the prod and dev defaults >> > > > converging >> > > > > > but >> > > > > > > >>>>> quarkus >> > > > > > > >>>>>> has a profile option by default which can be the way to >> > > solve >> > > > > it. >> > > > > > > >>>>>> >> > > > > > > >>>>>> hope it makes sense. >> > > > > > > >>>>>> >> > > > > > > >>>>>> 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. 1 juin 2026 à 15:28, Jean-Baptiste Onofré < >> > > > > > [email protected] >> > > > > > > >>> >> > > > > > > >>> a >> > > > > > > >>>>>> écrit : >> > > > > > > >>>>>> >> > > > > > > >>>>>>> Hi, >> > > > > > > >>>>>>> >> > > > > > > >>>>>>> Yes, that is indeed part of the proposal. >> > > > > > > >>>>>>> >> > > > > > > >>>>>>> The goal is to provide the UI as soon as the Polaris >> > server >> > > > > > > >> starts >> > > > > > > >>> to >> > > > > > > >>>>>>> ensure a better experience for our users. >> > > > > > > >>>>>>> >> > > > > > > >>>>>>> Regards, >> > > > > > > >>>>>>> JB >> > > > > > > >>>>>>> >> > > > > > > >>>>>>> On Mon, Jun 1, 2026 at 3:12 PM Robert Stupp < >> > > [email protected]> >> > > > > > > >>> wrote: >> > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> +1 >> > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> Could we then bundle the Console with the Polaris >> > server? >> > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> On Mon, Jun 1, 2026 at 8:01 AM Jean-Baptiste Onofré < >> > > > > > > >>>> [email protected] >> > > > > > > >>>>>> >> > > > > > > >>>>>>> wrote: >> > > > > > > >>>>>>>> >> > > > > > > >>>>>>>>> Hi everyone, >> > > > > > > >>>>>>>>> >> > > > > > > >>>>>>>>> As mentioned on the dev mailing list a few days >> ago, I >> > am >> > > > > > > >>>> currently >> > > > > > > >>>>>>>>> preparing the first release of the Polaris Console. >> > There >> > > > is >> > > > > > > >>>>>>>>> significant interest in the Console, and it is a key >> > > > > > > >> component >> > > > > > > >>> of >> > > > > > > >>>>> our >> > > > > > > >>>>>>>>> efforts to improve the onboarding experience. >> > > > > > > >>>>>>>>> >> > > > > > > >>>>>>>>> After discussing this with Yong, who started to help >> > with >> > > > the >> > > > > > > >>>>>> console, >> > > > > > > >>>>>>>>> we believe that moving the Console into the main >> > Polaris >> > > > > > > >>>> repository >> > > > > > > >>>>>>>>> would provide better visibility and encourage >> further >> > > > > > > >>>>> contributions. >> > > > > > > >>>>>>>>> This would also allow it to be released as part of >> the >> > > main >> > > > > > > >>>> Polaris >> > > > > > > >>>>>>>>> release cycle. Additionally, the Console could be >> > > included >> > > > as >> > > > > > > >>> an >> > > > > > > >>>>>>>>> optional component in the main Helm chart, allowing >> > users >> > > > to >> > > > > > > >>>> choose >> > > > > > > >>>>>>>>> whether to enable it. >> > > > > > > >>>>>>>>> >> > > > > > > >>>>>>>>> Thoughts? >> > > > > > > >>>>>>>>> >> > > > > > > >>>>>>>>> Regards, >> > > > > > > >>>>>>>>> JB >> > > > > > > >>>>>>>>> >> > > > > > > >>>>>>> >> > > > > > > >>>>>> >> > > > > > > >>>>> >> > > > > > > >>>> >> > > > > > > >>> >> > > > > > > >> >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> >
