-
Notifications
You must be signed in to change notification settings - Fork 332
Add muti-platform Docker images staging in the release guide #2039
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
site/content/release-guide.md
Outdated
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 ?
cca3573 to
743f1d4
Compare
|
@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 |
|
Thanks guys ! Much appreciated ! |
* 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>
No description provided.