Add natives for ARM64 to Wildfly distro
by Julien Faye
Hello Wildfly devs,
At my job we want to move to Linux ARM64 machines for our deployments.
The issue we see is that the current (22.0.1) distribution does not include
native binaries for linux-aarch64 architecture :-/
$ find ./ -name "*.so"
./modules/system/layers/base/org/apache/activemq/artemis/journal/main/lib/linux-i686/libartemis-native-32.so
./modules/system/layers/base/org/apache/activemq/artemis/journal/main/lib/linux-x86_64/libartemis-native-64.so
./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-x86_64/libwfssl.so
./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-s390x/libwfssl.so
I've found https://issues.redhat.com/browse/WFLY-13302 (and
https://issues.redhat.com/browse/WFSSL-32 and
https://issues.apache.org/jira/browse/ARTEMIS-2705) but those are opened
almost an year ago and it is not clear whether they will be resolved any
time soon.
As far as I understand your recommendation is to build the binaries
locally. This is OK but it adds some extra complexity to the deployment and
upgrade processes.
Since ARM64 becomes more and more popular for server side deployments I
would like to ask you whether those tickets could be resolved in near
future ?
Thank you!
Regards,
Julien
3 years
WildFly 26 Feature Freeze
by Darran Lofthouse
Just a quick reminder that the feature freeze for WildFly is Tuesday the
30th November with the feature freeze for WildFly Core being tomorrow
Friday the 26th November.
I am running through both sets of PR queue to get as many in as I can for
Beta if they are ready to be merged and reviewed.
After the Beta we anticipate the final code freeze for WildFly Core for any
bug fixes to be Friday the 10th December, ideally WildFly changes should
also be ready for the 10th so we can perform our final test runs before
release.
If you have any questions or issues you are trying to get into these
releases please let me know.
--
Darran Lofthouse
Red Hat <https://www.redhat.com/>
darran.lofthouse(a)jboss.com
<https://www.redhat.com/>
3 years
Future of WildFly Docker image
by Jean-Frederic Mesnil
Hi,
As you know, WildFly is providing a Docker image for each release of WildFly from the jboss organization at https://hub.docker.com/r/jboss/wildfly/tags.
However hub.docker.com has recently changes their features and we are no longer able to automate new images whenever we tag our GitHub project at https://github.com/jboss-dockerfiles/wildfly. This is becoming a manual task that only a few people in jboss organization can do.
We are trying to find a new way to deliver these images in a sustainable fashion.
One approach would be to move the Docker images to quay.io which provides the basic features we need to build images from our GitHub repo.
We already have a wildfly organization on Quay.io (that provides our S2I images as well as the WildFly operator): https://quay.io/organization/wildfly
This would affect users that pulls our images as they would have to
use
FROM quay.io/wildfly/wildfly
instead of
FROM jboss/wildfly
Internally, there would be no changes: we would continue to build these Docker images from tags in https://github.com/jboss-dockerfiles/wildfly
The latest release for our Docker image was the 25.0 tag.
A transition would be:
0. Advertise that we will stop delivering images from hub.docker.com. At this point, the jboss/wildfly:latest tag will point to 25.0 and will no longer be in sync with new WildFly releases.
1. Set up the quay.io/wildfly/wildfly repo and push the 25.0 tag to it.
-> users can switch from "jboss/wildfly” to "quay.io/wildfly/wildfly” without any impact for their applications
1.a If we eventually release images for 25.0.x versions, we will push images to both hub.docker and quay.io repositories
2. When we release the next major version of WildFly (WildFly 26), the image will be made available only from "quay.io/wildfly/wildfly” with the 26.0 and latest tag
Does that approach sounds sensible?
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
3 years
