Thanks a lot, JB, for reiterating the onboarding UX experience! It's a great and necessary effort for the Polaris project.
The onboarding experience for other catalogs often involves only minimal setup to configure the backend database (or a 0-config in-memory backend). Then users are ready to go. If the realm and catalog are created (if they don't already exist) and configured to use an object storage's standard mechanism for providing necessary credentials (e.g., exporting 'AWS_ACCESS_KEY_ID'), the configuration effort is minimal. One other thing that would be nice is for example the Iceberg REST base-URI of the created catalog - avoiding the effort to manually construct the base URI from the server's root URI. For experimentation, evaluation, or testing, I fully agree with Dmitri that it is IMO fine to not even require authN/Z - it should be prominently presented as insecure and be a deliberate user choice. Maybe we could even bundle the web UI with the server (the Console is essentially a collection of static files) and prominently present the link to the console on startup. Users could then inspect and interact with Polaris using their browser. I think this "no-auth mode" is doable even with the existing Docker image approach, perhaps with a clear flag like `docker run --rm -ti apache/polaris:latest --insecure-non-production-demo-mode`. Or maybe we provide a shell script like `./run-polaris-insecure-non-production-demo-mode` that also performs some pre-checks, tells what it does and configures, and provides actionable messages. And finally, the Console and such a script could provide hints to the CLI, which recently received quite valuable improvements, for more advanced operations. Actually, the Console and/or the script could show people how to connect to Polaris from Spark or Trino. Best, Robert On Thu, Apr 16, 2026 at 3:33 AM Yufei Gu <[email protected]> wrote: > +1 on adding an option to make the end result look nice. > > Thanks Yong and other folks for continuing to improve the CLI. We are also > working on the last mile, which publishes the CLI package to pypi.org, so > that users don't have to build it. > > +1 on most onboarding ideas mentioned above. Here are a few extra ideas: > > 1. Improve the front page of the Polaris website. > 2. Write a skill to set up Polaris. Here is a draft PR: > https://github.com/apache/polaris/pull/4217. > > Yufei > > > On Wed, Apr 15, 2026 at 2:49 PM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi Yong, > > > > I fully support refactoring (or even rewriting) the CLI using modern > > libraries with better UX. > > > > I'm sure, from the user's perspective it would be preferable to endure > > minor inconvenience with command/option changes to receive a nicer end > > result with the new CLI. > > > > Cheers, > > Dmitri. > > > > On Wed, Apr 15, 2026 at 3: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 > > > > > >
