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
