Thanks for revisiting this discussion. I'm trying to understand why PR #260 changes the architectural conclusion. My understanding is that the Console is still fundamentally a REST client. Supporting an additional authentication flow for a different deployment model changes the client implementation, but I'm not sure it changes the overall architecture.
In particular, I'm not yet seeing why adding proxy authentication means the Console should now be served from polaris-server or why Quarkus should own the authentication logic. Many standalone web clients support multiple authentication mechanisms while remaining independently deployable. Could you elaborate on what specific architectural or security concern PR #260 introduces that cannot be addressed while keeping the Console as a separate client? Is the concern duplicated authentication logic, a particular security risk, operational complexity, or something else? Besides, I also wanted to bring up a point from the previous discussion. One of the arguments[1] against moving client side components into the main Polaris repository was the additional LICENSE/NOTICE overhead and, more importantly, maintaining a clear separation of concerns. If the Console is still an independently deployed REST client, the same reasoning still applies. However, it feels like we've been deciding whether a tool belongs in the main Polaris repository on a case-by-case basis. I'd be supportive of defining a clearer set of principles so future tools can be evaluated consistently. For example, we could consider questions such as whether a component interacts with Polaris purely through the public REST APIs, or whether there is a strong downstream need for it to ship together with the Polaris server. These are just examples, more thoughts are welcome if we want to go that direction. In general, having explicit criteria like these would make the decisions more consistent than evaluating each tool independently. Understanding why PR #260 changes the answer under those criteria would help me better understand why it's worth revisiting the previous conclusion. 1. https://lists.apache.org/thread/539p26bwk7zh1p4d1jqyhh2pqkkh0n36 Thanks, Yufei On Wed, Jul 29, 2026 at 6:33 AM Jean-Baptiste Onofré <[email protected]> wrote: > Hi > > Thanks Robert for updating this thread. > > It was also my first preference but I was to open to others proposals. > I agree that things changed and we can revisit. > > I will come with a proposal to have console as part of Polaris-server > (maybe in two steps). > > Thanks! > > Regards > JB > > Le mer. 29 juil. 2026 à 13:00, Robert Stupp <[email protected]> a écrit : > > > 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 > > >> > > > > > > >>>>>>>>> > > >> > > > > > > >>>>>>> > > >> > > > > > > >>>>>> > > >> > > > > > > >>>>> > > >> > > > > > > >>>> > > >> > > > > > > >>> > > >> > > > > > > >> > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > > > >
