I have to disagree here.
In this thread, we discuss that *Polaris ships as a binary bundle, not a
pre-built Kubernetes chart.*
That bundle includes both the server and the admin tool for a reason: it
guarantees version compatibility and gives every user a friction-free way
to bootstrap a catalog, no matter where they run. If an operator wants the
leanest possible container image for production, nothing stops them from
building two images—one “server-only,” one “admin-only”—from the same
bundle. That split is straightforward and entirely under the deployer’s
control.
The admin binary adds a few megabytes, noise compared with the JRE and
native libraries we ship anyway. The gain in operational simplicity
outweighs that marginal footprint.
If an attacker can already execute arbitrary binaries inside the server
container, the cluster is compromised with or without admin-tool. They can
run "rm -rf *", etc.
There are multiple precedents like Spark, Kafka, ZooKeeper, Flink, and even
PostgreSQL all ship “server + tools” in the same distribution tarball. SRE
or operators can strip or relocate what they don’t need for their runtime
images.
So let’s keep the all-in-one distribution. Those who deploy into strict
environments can (and should) build slimmer images, but that’s a packaging
choice best left to the operator, not an upstream fragmentation of our
release artifacts.
Yufei
On Mon, May 19, 2025 at 5:17 AM Robert Stupp <sn...@snazy.de> wrote:
> Polaris-server and the admin-tool are separate things. You deploy the
> /server/ and let it run in k8s (or whatever). Bootstrapping via the
> admin-tools happens rarely (once) and is rather performed from an
> administrator's machine, whereas the server(s) run elsewhere. So server
> and admin-tool are run in very different ways.
>
> The admin-tool is (at best) just overhead in a server and increases the
> size of the image + container. Playing devil's advocate here, having the
> admin-tool executable accessible from the server gives easy access to
> the purge functionality.
>
> I also see issues in how users interact with a single image containing
> both the server and admin-tool w/o accidentally starting another Polaris
> server instance. Starting the server on an administrator's machine can
> likely start running tasks, which can run into failures, because you may
> not have the necessary object-stores' credentials.
>
> Configuration settings are pushed to the admin-tool and server in the
> same way. So you're probably already using the same (k8s) values.yaml.
>
> Overall I'm not sure whether this approach really simplifies things or
> rather introduces more complexity and potentially risks.
>
>
> On 15.05.25 07:00, Yufei Gu wrote:
> > Not at all. Thanks for the review, actually!
> >
> > I think it's a good idea to name it polaris-bin-{version}.tgz or
> > polaris-{version}-bin.tgz, which indicates that it's a binary
> > distribution, not a source distribution. Let me make the change.
> >
> > Yufei
> >
> >
> > On Wed, May 14, 2025 at 2:31 PM Dmitri Bourlatchkov<di...@apache.org>
> > wrote:
> >
> >> Thanks, Yufei! I added some comments in GH despite the "draft" PR
> status. I
> >> hope you do not mind :)
> >>
> >> Overall, using one distribution archive both for the server and the
> admin
> >> tool makes sense to me.
> >>
> >> 4. Standardized the binary distribution package naming to
> >> polaris-{version}.tgz and polaris-{version}.zip, following common
> >> conventions used by other projects (e.g.,
> spark-3.5.5-bin-hadoop3.tgz).
> >>
> >>
> >> Would it make sense to use archive names like polaris-1.0.0-bin.tgz (to
> >> follow Spark's example closer)?
> >>
> >> Thanks,
> >> Dmitri.
> >>
> >> On Wed, May 14, 2025 at 2:32 PM Yufei Gu<flyrain...@gmail.com> wrote:
> >>
> >>> Hi Folk,
> >>> Thanks a lot for the discussion. Here is the PR(
> >>> https://github.com/apache/polaris/pull/1589) to merge the binary
> >>> distribution while still keeping module polaris-quarkus-admin and
> >>> polaris-quarkus-server separately.
> >>>
> >>> *What’s included in thePR:*
> >>>
> >>> 1. Introduced a new module that combines binary distribution for
> both
> >>> Admin Tools and Server. Please note that source and jar are still
> >>> separated. Please refer to my original email for the motivation
> behind
> >>> this
> >>> change.
> >>> 2. Removed the now-redundant run-scripts module.
> >>> 3. Consolidated the README to reflect the unified binary
> distribution.
> >>> 4. Standardized the binary distribution package naming to
> >>> polaris-{version}.tgz and polaris-{version}.zip, following common
> >>> conventions used by other projects (e.g.,
> >> spark-3.5.5-bin-hadoop3.tgz).
> >>> *TODOs*:
> >>>
> >>> 1. Consolidate LICENSE and NOTICE files from both Admin Tools and
> >>> Server.
> >>> 2. Remove the distribution tasks in each of the original modules.
> >>>
> >>> The PR is technically ready, but I plan to wait until the 0.10 release
> is
> >>> finalized to avoid disrupting the release process.
> >>>
> >>>
> >>> Yufei
> >>>
> >>>
> >>> On Tue, May 6, 2025 at 9:31 AM Yufei Gu<flyrain...@gmail.com> wrote:
> >>>
> >>>> Other than duplicated downloads for shared jars, the big problem is
> >> that
> >>>> the configuration difference between admin tool and server may cause
> >>> server
> >>>> issues, e.g., the admin tool may bootstrap a realm in a wrong
> database.
> >>>>
> >>>> Let's move them into the same distribution package first. Then we can
> >>>> consider merging the modules, as we discussed the separation makes the
> >>>> development and release unnecessary cumbersome.
> >>>>
> >>>> Yufei
> >>>>
> >>>>
> >>>> On Tue, May 6, 2025 at 5:57 AM Dmitri Bourlatchkov<di...@apache.org>
> >>>> wrote:
> >>>>
> >>>>> Thanks for the clarification, JB!
> >>>>>
> >>>>> Packaging both the server and the admin tool in the same distribution
> >>>>> (archive) is certainly a good idea.
> >>>>>
> >>>>> Cheers,
> >>>>> Dmitri.
> >>>>>
> >>>>> On Tue, May 6, 2025 at 2:33 AM Jean-Baptiste Onofré<j...@nanthrax.net>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi
> >>>>>>
> >>>>>> We can see two aspects here:
> >>>>>> - the merge of the applications
> >>>>>> - gather applications in one package/distribution (tar.gz/zip)
> >>>>>>
> >>>>>> I'm in favor of the later because:
> >>>>>> - admin and server distributions share 80% of the same artifacts
> >>>>>> - users have to download to "big" packages
> >>>>>>
> >>>>>> We should keep the Quarkus applications separated but we can gather
> >>>>>> both in one distribution, with this kind of layout:
> >>>>>> - admin/run.sh
> >>>>>> - admin/lib/boot
> >>>>>> - admin/lib/main
> >>>>>> - server/run.sh
> >>>>>> - server/lib/boot
> >>>>>> - server/lib/main
> >>>>>> - lib/common
> >>>>>> I don't see why it could not work with Quarkus (I already did
> >>>>>> something similar for other Quarkus application, using maven
> >> assembly
> >>>>>> plugin).
> >>>>>>
> >>>>>> Regards
> >>>>>> JB
> >>>>>>
> >>>>>> On Tue, May 6, 2025 at 2:54 AM Dmitri Bourlatchkov <
> >> di...@apache.org>
> >>>>>> wrote:
> >>>>>>> Hi Yufei,
> >>>>>>>
> >>>>>>> Please note that the admin tool is a CLI application, while the
> >>>>> quarkus
> >>>>>>> "server" is a REST application.
> >>>>>>>
> >>>>>>> How do you envision supporting both CLI and REST API in the same
> >>>>> module?
> >>>>>>> Thanks,
> >>>>>>> Dmitri.
> >>>>>>>
> >>>>>>> On Mon, May 5, 2025 at 2:49 PM Yufei Gu<flyrain...@gmail.com>
> >>> wrote:
> >>>>>>>> Hi folks,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I’d like to propose merging the polaris-quarkus-admin and
> >>>>>>>> polaris-quarkus-server modules. While modularization can bring
> >>>>> benefits
> >>>>>>>> like clearer separation of concerns, in this case, the split
> >> seems
> >>>>> to
> >>>>>> cause
> >>>>>>>> more friction than value. Here’s why I think merging makes
> >> sense:
> >>>>>>>> 1. Improved usability: Users can find all tools in one place,
> >>>>>> making it
> >>>>>>>> easier to use and onboard. Just try out the new 0.10.0-beta
> >>>>> binary
> >>>>>>>> releases, you will find out the inconvenience of the
> >>> separation.
> >>>>>> Plus, I
> >>>>>>>> don’t think anyone will use the admin tool without Polaris
> >>>>> server.
> >>>>>> We
> >>>>>>>> don't have to merge the module to archive a single binary
> >>> release
> >>>>>>>> package,
> >>>>>>>> but merging two modules will make it really easy.
> >>>>>>>> 2. Simpler development: The split has led to small utility
> >>>>> modules
> >>>>>> like
> >>>>>>>> “test-common” and “run-script” that only exist to bridge the
> >>>>>> separation.
> >>>>>>>> Merging the two will reduce duplication and save time for
> >>>>> everyone.
> >>>>>>>> 3. Easier releases: We’d no longer need to generate separate
> >>>>>>>> LICENSE/NOTICE files or maintain two binary packages.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I’ve talked to folks like JB and Prashant about this offline,
> >> and
> >>>>> the
> >>>>>>>> feedback so far has been positive.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> If there are no objections, I’ll file a PR to merge the two and
> >>> aim
> >>>>> to
> >>>>>>>> package them together starting with the 1.0 release.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Yufei
> >>>>>>>>
> --
> Robert Stupp
> @snazy
>
