Hi Vignesh, Thank you very much for your contribution. Much appreciated!
I saw your PR, but I haven't had a chance to review it yet as I was traveling back from the Iceberg Summit. I plan to review it later today or tomorrow. Thanks again! Regards, JB On Wed, Apr 15, 2026 at 2:33 PM vignesh nayak <[email protected]> wrote: > Hi JB, > > I had raised a PR[1] few days ago for quick setup feature in console. Would > this help to improve the onboarding experience? > > 1. https://github.com/apache/polaris-tools/pull/209 > > Regards, > Vignesh Nayak Manel > > On Wed, 15 Apr, 2026, 3:16 pm Jean-Baptiste Onofré, <[email protected]> > wrote: > > > Hi Yong, > > > > I agree with you regarding Docker Compose. The primary advantage of a > > standalone Docker image is that it can be pulled in a single step from a > > repository. I am also considering providing an archive that users can run > > without requiring Docker. > > > > Regarding the CLI, thank you again for your excellent work. It has > improved > > significantly, and I agree we can continue to refine the user > experience. I > > believe the CLI is a vital alternative to an MCP server, as tools like > > Claude Code can leverage it directly without needing a local MCP server. > I > > think improving the CLI is an important initiative. > > > > For bootstrapping, I am considering a "response file" with default > entries > > that the server, CLI, or Console can use to set up a default catalog. The > > goal is to get users up and running in seconds. > > > > To clarify on the Helm Chart, I haven't heard of specific issues; it's > > simply that a full Helm deployment is often overkill for users who just > > want to test or evaluate Polaris. > > > > Regards, > > JB > > > > On Wed, Apr 15, 2026 at 9:33 AM Yong Zheng <[email protected]> > > wrote: > > > > > Hello JB, > > > > > > Thanks for bring this up. For sure I had been seeing many people > reported > > > some basic stuff in the slack over time (maybe due to docs are hard to > > > follow?). > > > > > > Having an all-in-one docker file will solve the usability problem, > > > however, this docker image will be large large in size as spark itself > is > > > 600-800MB already and Trino is in similar size range if I recalled). In > > > this case, this will no not much difference compare to a docker > compose I > > > think? > > > > > > Regarding the CLI, we are currently using the custom parser (it works > but > > > a bit different compared to more standard things such as click > library). > > I > > > paused the better UI/UX work a bit for CLI as I also felt this is a bit > > > hard to maintain and wondering if we should make more refactor on > this. I > > > haven’t get a chance to review the last community sync due to conflict > of > > > time and work. I will catch up on those over weekends. Any feedback on > > this > > > regarding CLI if we should move towards to more standard libraries etc > > and > > > better UX (start with plaintext first). > > > > > > Regarding multiple entries had to be created before system been > useable, > > > one possibility solution is define the basic scopes then have a config > > file > > > then just provide one liner instruction to “bootstrap” it via setup > > > command? But I am not sure how useful this basic setup would be. Taking > > > airflow RBAC as an example, out of box, there is no accounts created > > after > > > enabled RBAC and users would need to run the commands to create those > > > entries regardless. Thus, I am not sure about how useful the default > > > entities would be. > > > > > > Regarding helm chart piece, I am assuming users are compliant about the > > > length of values files? If that is the case, we can always give them > > > reference for the overwrite value file while the length one will be > > > packaged with the chart. > > > > > > Thanks, > > > Yong Zheng > > > > > > > On Apr 15, 2026, at 12:28 AM, Jean-Baptiste Onofré <[email protected]> > > > wrote: > > > > > > > > Hi folks, > > > > > > > > During last week’s Iceberg Summit, I had several discussions > regarding > > > > Apache Polaris. While users are generally satisfied with its features > > and > > > > performance, a recurring piece of feedback is that Polaris is > difficult > > > to > > > > get started with compared to other catalogs. Specific pain points > > > include: > > > > > > > > - The CLI is not intuitive. > > > > - There is no UI by default. > > > > - Multiple entities (catalogs, roles, etc.) must be created before > the > > > > system is ready. > > > > - The Helm Chart is suitable for production but overkill for > > evaluation. > > > > - The Docker image is currently insufficient for quick starts. > > > > - The Getting Started guide and documentation are difficult to follow > > for > > > > new users. > > > > > > > > I previously started a proposal to address this (last year, > "[PROPOSAL] > > > > User onboard..."). While we have since improved the CLI and > introduced > > > the > > > > Polaris Console, I believe we need to push further on this > initiative. > > > > > > > > I have a follow-up proposal with two main points: > > > > > > > > 1. I will move forward with the Polaris Console release. > > > > 2. I propose creating a "standalone" Docker image (e.g. > > > > polaris-standalone). This would be a ready-to-use image including > > > > PostgreSQL, Polaris Server, Polaris Console, Polaris CLI, and > > > potentially a > > > > notebook and query engine/Spark. > > > > > > > > The goal is to provide an easy-to-start image that works for small > > > > production environments and allows users to evolve their deployment > > > > incrementally. > > > > > > > > What are your thoughts? > > > > > > > > Regards, > > > > JB > > > > > >
