Hi all, I fully agree that we need to focus on improving the onboarding experience.
I've seen some frustration in the past due to the bootstrap requirement: I know we have some setup tools, but would it be possible to enhance the process and add the possibility to populate the realm with a few objects by default: a principal, a role, a catalog role and a demo catalog with in-memory (or filesystem) storage? (I know, the devil is the details...) This imho would make a fresh Polaris installation ready to use from the first launch. As for the all-in-one Docker image, I'm dubitative: I'd rather see a docker-compose file in this case, but I think we already have a few good ones in the getting-started folder. If the getting-started guides are deemed too difficult for newcomers, we definitely need to do something about them. It is true that our guides section: https://polaris.apache.org/guides/ looks a bit intimidating at first glance; it doesn't have a simple "start here" page. This could be improved. Thanks, Alex 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 > > > > >
