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