-
Notifications
You must be signed in to change notification settings - Fork 52
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
Experimental arm64 support for Cassandra 3.11.6 #36
Experimental arm64 support for Cassandra 3.11.6 #36
Conversation
…etty" This reverts commit 8039c7c.
@@ -0,0 +1,115 @@ | |||
FROM --platform=$BUILDPLATFORM maven:3.6.3-jdk-8-slim as builder |
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.
When using buildx, there isn't a way to make a build of an image in one invocation of buildx available to a subsequent invocation of buildx without the use of a registry. This means our traditional approach of having a 'build' docker image that we then reference in subsequent docker files will not work (unless we push it to a registry). To get around this, we use one multi-stage docker file that contains the build stages. A further discussion of this issue in buildx can be found here: docker/buildx#156
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.
Also, note the --platform=$BUILDPLATFORM
. This is because we don't have to build the jar for each arch we support since its java. This indicates that this stage should only be built on whatever the build platform is (probably linux-amd64).
# Netty arm64 epoll support was not added until 4.1.50 (https://github.com/netty/netty/pull/9804) | ||
# Only replace this dependency for arm64 to avoid regressions | ||
RUN rm /opt/cassandra/lib/netty-all-*.jar | ||
COPY --from=netty4150 /root/.m2/repository/io/netty/netty-all/4.1.50.Final/netty-all-4.1.50.Final.jar /opt/cassandra/lib/netty-all-4.1.50.Final.jar |
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.
The better way to do this is probably to have the management api agent contain a shaded version of netty at the appropriate version. That will take further experimentation. However, we are only swapping out this jar for arm64, so this should not impact any existing users.
COPY --from=builder /build/management-api-shim-4.x/target/datastax-mgmtapi-shim-4.x-0.1.0-SNAPSHOT.jar /opt/mgmtapi/ | ||
|
||
ENV TINI_VERSION v0.18.0 | ||
ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-${TARGETARCH} /tini |
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.
Note the change here to get tini for the appropriate architecture.
# NOTE: Presently, OSS doesn't have official Cassandra 4.0 builds on dockerhub | ||
# and our build at datastax/cassandra:4.0 is not a multiarch image like the | ||
# official ones. Once one of those issues is fixed, the following targets can | ||
# be used to build Cassandra 4.0 with Management API. |
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.
Half way through this I realized we didn't have an appropriate multiarch cassandra 4.0 image. We could just remove all of this for now instead of commenting out. I thought it might be useful for reference, but I have no strong feelings either way.
@@ -14,7 +14,7 @@ | |||
<properties> | |||
<slf4j.version>1.7.25</slf4j.version> | |||
<logback.version>1.2.3</logback.version> | |||
<netty.version>4.1.45.Final</netty.version> | |||
<netty.version>4.1.50.Final</netty.version> |
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.
This one provides a build of epoll for arm64.
_metrics_collector_supported() { | ||
# currently, metrics collector does not work on arm64 | ||
[ "$(uname -m)" != "aarch64" ] | ||
} |
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 don't know the best way to handle this. Somehow we need to disable the metrics collector for arm64. This appears to be working, but I'm open to suggestions.
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.
Could you push the branch to this repo so the CI can run and open a new PR?
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.
Seems like it running now.
@tjake yeah, I created the branch in the datastax repo, and since both branches pointed to the same commit, the jobs just started running. Tests are passing now, but I'm putting this back into draft briefly to test something. |
.github/workflows/ci.yaml
Outdated
--tag mgmtapi-3_11 \ | ||
--file Dockerfile-oss \ | ||
--target oss311 \ | ||
--platform linux/amd64 . |
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.
Only building here for "linux/amd64" as a multiarch image cannot be loaded into the local docker images. This should be good enough for running the integration tests.
@tjake The ci tests are passing now, but that's a bit deceptive. I just noticed that we use a docker-java library to build the image in our integration tests: Currently, this is using the Dockerfile-3_11 docker file. However, I updated the build to use Dockerfile-oss to create the multiarch images: This dockerfile requires the use of buildkit, which one can use by either using buildx (as is done to generate the multiarch images) or by setting the environment variable Is there any reason why we cannot just invoke the docker executable to do the build instead of using this library? |
That should be fine, can you do that? |
Yes, I'll take care of it. Just wanted to make sure it was palatable first. Thanks for the feedback! |
@tjake Okay, integration tests are now passing! My Java is a little rusty, so let me know if I should be doing anything differently there. |
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.
Awesome job! Thanks for this
Turns the Cassandra 3.11.6 w/ Management API built into a multiarch build supporting both arm64 and amd64. Currently, disables metrics collector on arm64 as our collectd fork does not presently support arm64.
Closes #35