+1
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 mar. 2 juin 2026, 13:22, Jean-Baptiste Onofré <[email protected]> a écrit : > 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 > > > > >>>>>>>>> > > > > >>>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > >
