Skip to content

Conversation

@jbonofre
Copy link
Member

No description provided.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the machine's requirements for "buildx"? Docker? Podman?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docker (we use quarkus-container-image-docker dependency by default).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, not sure Docker's a great implied requirement due to the licensing implications that it brings for most devs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Podman also supports multi-platform images "natively" (without buildx). If we want to use podman, we should update the dependency here: https://github.com/apache/polaris/blob/main/runtime/server/build.gradle.kts#L55 (to use podman instead of docker).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI, last time I tried multi-arch builds with podman, the resulting manifests were corrupted. But, maybe it's fixed/improved now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect, it's not an issue (license wise) to use Docker buildx in ASF GH workflows. Just for potentially for devs locally.

Copy link
Contributor

@MonkeyCanCode MonkeyCanCode Jul 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. podman can do multi-arch build without buildx now a day (I used it at work as well). Due to the above concern with licensing around docker, does it makes sense to deprecate docker and promo podman instead? Also, for buildx on docker with Mac/Windows, additional steps are needed on the build machines other than the additional parameters specify above.

One more catch with podman is it will add container registry info (by default docker.io) to the image name. When building with docker, we will get apache/polaris:xxxx. However, if we build with podman, it will then become docker.io/apache/polaris:xxxx. In case if we want to promo podman as oppose to docker, we shoild container add additional parameter to set registry info as part of the image build (so both docke/podman will produce same images name) then update our docs accordingly.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I propose to move forward with Docker for now, we can switch to podman in another PR. Thoughts ?

@jbonofre jbonofre force-pushed the release-guide-docker-publish branch from cca3573 to 743f1d4 Compare July 21, 2025 14:57
@jbonofre
Copy link
Member Author

@MonkeyCanCode @snazy @adutra I propose to move forward and merge this PR (to update the release guide). I would like to create another PR for release guide based on this one. Wdyt ?

@github-project-automation github-project-automation bot moved this from PRs In Progress to Ready to merge in Basic Kanban Board Jul 24, 2025
@adutra
Copy link
Contributor

adutra commented Jul 24, 2025

@MonkeyCanCode @snazy @adutra I propose to move forward and merge this PR (to update the release guide). I would like to create another PR for release guide based on this one. Wdyt ?

LGTM

@jbonofre
Copy link
Member Author

Thanks guys ! Much appreciated !

@jbonofre jbonofre merged commit 68d0e26 into apache:main Jul 24, 2025
12 checks passed
@github-project-automation github-project-automation bot moved this from Ready to merge to Done in Basic Kanban Board Jul 24, 2025
snazy added a commit to snazy/polaris that referenced this pull request Nov 20, 2025
* Extract ResolverFactory from PolarisEntityManager (apache#2148)

`PolarisEntityManager.prepareResolver` was the only place that used the `EntityCache`. By introducing an application-scoped `ResolverFactory` the creation of an `EntityCache` is decided only once in `QuarkusProducers`, which will become the only place where `MetaStoreManagerFactory.getOrCreateEntityCache` gets called.

Note that the little left-over functionality of `PolarisEntityManager` can
be split out to more dedicated interfaces in a follow-up most likely.

* Run standard (sharable) REST Catalog integrations tests with MinIO (apache#2158)

* Run standard (sharable) REST Catalog integrations tests with MinIO

Keep special edge case tests (path style, STS endpoint and
client-side FileIO) in `QuarkusRestCatalogMinIoSpecialIT`.

* fix(deps): update quarkus platform and group (apache#2166)

* fix(deps): update dependency io.smallrye.config:smallrye-config-core to v3.13.4 (apache#2165)

* Simplify checkPolarisServiceBootstrappedForRealm (apache#2162)

* fix(deps): update dependency boto3 to v1.39.12 (apache#2169)

* Improve Realm ID resolution for Quarkus 3.24+ (apache#2163)

In Quarkus 3.24, it is now possible to retrieve context locals inside HttpServerMetricsTagsContributor. This greatly simplifies our RealmIdTagContributor implementation.

It is also now possible to return null from ValueExpressionResolver. This is not a big deal, but still better than returning "".

* chore(deps): update plugin jandex to v2.2.0 (apache#2175)

* Add muti-platform Docker images staging in the release guide (apache#2039)

* fix(deps): update dependency org.apache.commons:commons-text to v1.14.0 (apache#2178)

* Rework getOrCreateSessionSupplier (apache#2161)

note how all the caller immediately called `get` on the returned `Supplier`.
it seems like the `Supplier` was an leaking implementation detail of the
`MetaStoreManagerFactor` implementations.

* Respond with 409 in case of concurrent Namespace update failures instead of 500 (apache#1989)

* NoSQL adoptions

* Last merged commit e9267b6

---------

Co-authored-by: Christopher Lambert <xn137@gmx.de>
Co-authored-by: Dmitri Bourlatchkov <dmitri.bourlatchkov@gmail.com>
Co-authored-by: Mend Renovate <bot@renovateapp.com>
Co-authored-by: Alexandre Dutra <adutra@apache.org>
Co-authored-by: JB Onofré <jbonofre@apache.org>
Co-authored-by: fabio-rizzo-01 <fabio.rizzocascio@jpmorgan.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants