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 > >>>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> >
