9:13 p.m.
Hi,
To run WildFly on a Cloud with a container image, you have 2 approaches:
* Use the “docker” image that provides a downloaded installation of WildFly, put your
deployment in it and deploy on your container platform.
* Use the “s2i” images to build an application with S2I (Source-to-image) on OpenShift,
put it in a runtime image and deploy it on OpenShift.
Both approaches have their own strength and weaknesses and evolved at their own pace
without any coordination.
However in the last few months, the activity on the docker image slowed down due to
external factor (hub.docker constraints) and our lack of attention to it…
Meanwhile, we have ramped up the activity on the S2I images and provided a whole new
architecture that relies on Maven to assemble the application runtime (WildFly +
deployments) instead of hiding that assembly in the S2I process.
I just wrote down an article on wildfly.org explaining how WildFly users that uses the
“docker” image can adapt their workflow to the new architecture (without having to switch
to S2I!)
https://www.wildfly.org/news/2022/08/04/wildfly-maven-docker/
The target audience for this article is the “docker” users so that they can keep their
workflow (I build my deployment, I create a container image from a Dockerfile) and benefit
from all the work done around WildFly provisioning (feature packs, layers, packaging
scripts, etc.)
While writing this article and looking at the issues for the docker image, I spotted a few
themes shared between all these images:
* We want to consume more recent versions of JDK (17 in particular)
* We want to run on linux/arm64 (in addition to Intel arch)
* We want to trim the image size / reduce the surface area of security attacks
* We want better image health index
I think the investment we made on the S2I bundler and runtime images can benefit to the
docker image and vice versa.
In particular, we are dedicated to provide a runtime image that contains all it needs to
run WildFly (ie OpenJDK + a few more bits) with a good health index.
On the docker image, the base-jdk image we are using is lagging behind and I wonder if we
should not take the opportunity to use the WildFly runtime image as the base for the
docker image (after all, its sole purpose is to run WildFly!)
I’ve started a Board to list the synergies and feature gap we have in our images:
https://trello.com/b/QGnEci3i/willdfly-image-alignments
I think that using the runtime image as the base image for the docker image would be an
enabler for a lot of this work and would ensure that WildFly is in better shape to run on
containers.
As I wrote in the article, we will continue to deliver the Docker image for WildFly but we
are focusing on the new architecture and the new images to expand the capabilities of
WildFly.
We are looking forward to our users trying this new approach and validates how it improves
their workflow.
I’ve opened this thread to gather input on this alignment to make sure we get all the
requirement in place before putting this in action.
I’m looking forward to hearing your ideas on it.
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
4:10 a.m.
Thanks, Jeff. So AIUI the idea is to support multiarch and linux/arm64 on
the runtime image, and thus on the docker image that would now be based
upon it instead of the base-jdk image. And since we have both SE 11 and 17
runtime images it's trivial to produce an SE 17 docker image. That all
sounds reasonable; more in-line.
On Fri, Aug 5, 2022 at 7:13 AM Jean-Frederic Mesnil <jmesnil(a)redhat.com>
wrote:
Hi,
To run WildFly on a Cloud with a container image, you have 2 approaches:
* Use the “docker” image that provides a downloaded installation of
WildFly, put your deployment in it and deploy on your container platform.
* Use the “s2i” images to build an application with S2I (Source-to-image)
on OpenShift, put it in a runtime image and deploy it on OpenShift.
Both approaches have their own strength and weaknesses and evolved at
their own pace without any coordination.
However in the last few months, the activity on the docker image slowed
down due to external factor (hub.docker constraints) and our lack of
attention to it…
Meanwhile, we have ramped up the activity on the S2I images and provided a
whole new architecture that relies on Maven to assemble the application
runtime (WildFly + deployments) instead of hiding that assembly in the S2I
process.
I just wrote down an article on wildfly.org explaining how WildFly users
that uses the “docker” image can adapt their workflow to the new
architecture (without having to switch to S2I!)
https://www.wildfly.org/news/2022/08/04/wildfly-maven-docker/
The target audience for this article is the “docker” users so that they
can keep their workflow (I build my deployment, I create a container image
from a Dockerfile) and benefit from all the work done around WildFly
provisioning (feature packs, layers, packaging scripts, etc.)
While writing this article and looking at the issues for the docker image,
I spotted a few themes shared between all these images:
* We want to consume more recent versions of JDK (17 in particular)
* We want to run on linux/arm64 (in addition to Intel arch)
* We want to trim the image size / reduce the surface area of security
attacks
Does what you're proposing address this aspect? Is the runtime image
smaller/less attack surface than the base-jdk image currently used?
* We want better image health index
A smaller attack surface would help with that and I believe the idea is
that aligning on the runtime images will improve our ability to handle
things like respins. Is that your thinking?
I think the investment we made on the S2I bundler and runtime images can
benefit to the docker image and vice versa.
In particular, we are dedicated to provide a runtime image that contains
all it needs to run WildFly (ie OpenJDK + a few more bits) with a good
health index.
On the docker image, the base-jdk image we are using is lagging behind and
I wonder if we should not take the opportunity to use the WildFly runtime
image as the base for the docker image (after all, its sole purpose is to
run WildFly!)
I’ve started a Board to list the synergies and feature gap we have in our
images:
https://trello.com/b/QGnEci3i/willdfly-image-alignments
I think that using the runtime image as the base image for the docker
image would be an enabler for a lot of this work and would ensure that
WildFly is in better shape to run on containers.
Why would we *not* do this? Any meaningful downsides I'm not thinking of?
As I wrote in the article, we will continue to deliver the Docker image
for WildFly but we are focusing on the new architecture and the new images
to expand the capabilities of WildFly.
We are looking forward to our users trying this new approach and validates
how it improves their workflow.
I’ve opened this thread to gather input on this alignment to make sure we
get all the requirement in place before putting this in action.
I’m looking forward to hearing your ideas on it.
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
9:16 p.m.
Hi (answers inlined)
On 5 Aug 2022, at 21:10, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
Thanks, Jeff. So AIUI the idea is to support multiarch and linux/arm64 on the runtime
image, and thus on the docker image that would now be based upon it instead of the
base-jdk image. And since we have both SE 11 and 17 runtime images it's trivial to
produce an SE 17 docker image. That all sounds reasonable; more in-line.
* We want to trim the image size / reduce the surface area of security attacks
Does what you're proposing address this aspect? Is the runtime image smaller/less
attack surface than the base-jdk image currently used?
The gain in image size is not significant (124MiB for the runtime image, 159MiB for the
docker image).
The gain becomes more evident when layers are used with the runtime image to trim the
WildFly content to install.
Freshness of the images is meaningful for the security attacks. The base-jdk11 image has
not been updated for 2 years now.
* We want better image health inde
A smaller attack surface would help with that and I believe the idea
is that aligning on the runtime images will improve our ability to handle things like
respins. Is that your thinking?
Yes. When we move the docker image from hub.docker.com to quay.io, we changed the workflow
to automate the images respins.
I think that using the runtime image as the base image for the docker
image would be an enabler for a lot of this work and would ensure that WildFly is in
better shape to run on containers.
Why would we *not* do this? Any meaningful downsides I'm not thinking of?
From a WildFly perspective, there are no downside as we would have all the packages we
need to run the server.
The big shift is in the underlying base image. The docker image is based on CentOS 7 while
the runtime image is based on UBI 8 minimal.
Users that are extending the docker image and installing other packages would have to move
from using yum to microdnf.
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
10:26 p.m.
There has been some progress on the WildFly docker images.
A contributor, Henri-Laiho, proposed in a PR[1]to switch the WildFly images
to the centos variants of the Eclipse Temurin images[2].
There are many advantages with that approach:
* The Temurin images are official images based on the Eclipse Adoptium
project.
* They have variants based on CentOS 7 (as our existing WildFly docker
images) so any Docker images built on top of them would required no changes.
* They provide maintained images for the JDK versions that are supported by
WildFly (11 & 17). We would be able to provide WildFly images for both JDK
too.
* They are multiarch (and would make the WildFly image multiarch too).
Before making a decision on switching to these images, I wanted to get some
community feedback.
* Do you see any reason to reject this switch?
* Should we switch to the OpenJDK images instead?
* What would be the first WildFly release that would use these base images?
We are about to release WildFly 27 that requires Jakarta EE 10. This would
be a good first target. But we have a lot of users that will remain on
Jakarta EE 9 (and thus WildFly 26) that would appreciate running their apps
on JDK 17 (and ARM architecture for example)?
I'll keep that thread open for feedback before we decide if, when and how
we could make that switch.
Best regards,
jeff
[1] https://github.com/jboss-dockerfiles/wildfly/pull/161
[2] https://hub.docker.com/_/eclipse-temurin/tags
On Mon, Aug 8, 2022 at 2:16 PM Jean-Frederic Mesnil <jmesnil(a)redhat.com>
wrote:
Hi (answers inlined)
> On 5 Aug 2022, at 21:10, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>
> Thanks, Jeff. So AIUI the idea is to support multiarch and linux/arm64
on the
runtime image, and thus on the docker image that would now be based
upon it instead of the base-jdk image. And since we have both SE 11 and 17
runtime images it's trivial to produce an SE 17 docker image. That all
sounds reasonable; more in-line.
>
> * We want to trim the image size / reduce the surface area of security
attacks
>
> Does what you're proposing address this aspect? Is the runtime image
smaller/less attack surface than the base-jdk image currently used?
The gain in image size is not significant (124MiB for the runtime image,
159MiB for
the docker image).
The gain becomes more evident when layers are used with the runtime
image
to trim the WildFly content to install.
Freshness of the images is meaningful for the security attacks. The
base-jdk11
image has not been updated for 2 years now.
> * We want better image health inde
> A smaller attack surface would help with that and I believe the idea is
that
aligning on the runtime images will improve our ability to handle
things like respins. Is that your thinking?
Yes. When we move the docker image from hub.docker.com to quay.io, we
changed the
workflow to automate the images respins.
> I think that using the runtime image as the base image for the docker
image
would be an enabler for a lot of this work and would ensure that
WildFly is in better shape to run on containers.
>
> Why would we *not* do this? Any meaningful downsides I'm not thinking
of?
From a WildFly perspective, there are no downside as we would have all
the packages
we need to run the server.
The big shift is in the underlying base image. The docker image is based
on CentOS
7 while the runtime image is based on UBI 8 minimal.
Users that are extending the docker image and installing other
packages
would have to move from using yum to microdnf.
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
4:07 a.m.
Is the proposal to *not* base the docker image on the runtime image then?
Or is it to base the runtime image on Temurin/CentOS 7 as well?
On Wed, Oct 12, 2022 at 8:27 AM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
There has been some progress on the WildFly docker images.
A contributor, Henri-Laiho, proposed in a PR[1]to switch the WildFly
images to the centos variants of the Eclipse Temurin images[2].
There are many advantages with that approach:
* The Temurin images are official images based on the Eclipse Adoptium
project.
* They have variants based on CentOS 7 (as our existing WildFly docker
images) so any Docker images built on top of them would required no changes.
* They provide maintained images for the JDK versions that are supported
by WildFly (11 & 17). We would be able to provide WildFly images for both
JDK too.
* They are multiarch (and would make the WildFly image multiarch too).
Before making a decision on switching to these images, I wanted to get
some community feedback.
* Do you see any reason to reject this switch?
* Should we switch to the OpenJDK images instead?
* What would be the first WildFly release that would use these base
images? We are about to release WildFly 27 that requires Jakarta EE 10.
This would be a good first target. But we have a lot of users that will
remain on Jakarta EE 9 (and thus WildFly 26) that would appreciate running
their apps on JDK 17 (and ARM architecture for example)?
I'll keep that thread open for feedback before we decide if, when and how
we could make that switch.
Best regards,
jeff
[1] https://github.com/jboss-dockerfiles/wildfly/pull/161
[2] https://hub.docker.com/_/eclipse-temurin/tags
On Mon, Aug 8, 2022 at 2:16 PM Jean-Frederic Mesnil <jmesnil(a)redhat.com>
wrote:
>
> Hi (answers inlined)
>
> > On 5 Aug 2022, at 21:10, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
> >
> > Thanks, Jeff. So AIUI the idea is to support multiarch and linux/arm64
on the runtime image, and thus on the docker image that would now be based
upon it instead of the base-jdk image. And since we have both SE 11 and 17
runtime images it's trivial to produce an SE 17 docker image. That all
sounds reasonable; more in-line.
> >
> > * We want to trim the image size / reduce the surface area of security
attacks
> >
> > Does what you're proposing address this aspect? Is the runtime image
smaller/less attack surface than the base-jdk image currently used?
>
> The gain in image size is not significant (124MiB for the runtime image,
159MiB for the docker image).
> The gain becomes more evident when layers are used with the runtime
image to trim the WildFly content to install.
>
> Freshness of the images is meaningful for the security attacks. The
base-jdk11 image has not been updated for 2 years now.
>
>
> > * We want better image health inde
>
> > A smaller attack surface would help with that and I believe the idea
is that aligning on the runtime images will improve our ability to handle
things like respins. Is that your thinking?
>
> Yes. When we move the docker image from hub.docker.com to quay.io, we
changed the workflow to automate the images respins.
>
> > I think that using the runtime image as the base image for the docker
image would be an enabler for a lot of this work and would ensure that
WildFly is in better shape to run on containers.
> >
> > Why would we *not* do this? Any meaningful downsides I'm not thinking
of?
>
> From a WildFly perspective, there are no downside as we would have all
the packages we need to run the server.
>
> The big shift is in the underlying base image. The docker image is based
on CentOS 7 while the runtime image is based on UBI 8 minimal.
> Users that are extending the docker image and installing other packages
would have to move from using yum to microdnf.
>
> Best regards,
> Jeff
>
> --
> Jeff Mesnil
> Principal Software Engineer
> Red Hat
> http://jmesnil.net/
>
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
3:40 p.m.
Is the proposal to *not* base the docker image on the runtime image
then? Or is it to base the runtime image on Temurin/CentOS 7 as well?
This new proposal would not involve the (S2I) runtime image.
It would only impact the Docker image at https://quay.io/repository/wildfly/wildfly
<https://quay.io/repository/wildfly/wildfly> and unblock it to provide often
requested feature (esp. JDK 17 and multiarch).
I did not investigate moving the S2I Builder and Runtime image to Temurin. This would be a
separate effort as our Builder image is closely tied to the OpenJDK images (we are reusing
their cekit modules).
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
8:59 p.m.
I’ve been working on moving our Docker mage to using Temurin and I think we are in a good
shape to make that move.
Henri-Laiho did the actual change in the PR
https://github.com/jboss-dockerfiles/wildfly/pull/161 and I’ve been updating the GitHub
action to be able to build multiarch (ARM & AMD) JDK 11 and 17 images from the
Dockerfile.
With that change, we will provide much requested features to our Docker images:
* JDK 17 support
* ARM architecture
* Updated JDK/OS versions
I’ve been testing it on my own container registry at
https://quay.io/repository/jmesnil/wildfly?tab=tags and the images looks good.
I can not test the ARM builds but the Intel ones work just fine.
If users with access to ARM machine could test them, that’d be great.
I am planning to publish all images under a single image registry
quay.io/wildfly/wildfly.
We would then append the idk version to the WildFly version in the image tag/ the
convention would be:
quay.io/wildfly/wildfly:<wildfly version>-jdk<jdk-version>
I’m not planning to publish the latest tag anymore if we provide multiple jdk versions.
Instead, there will be latest-<jdk-version> for each JDK version we want to
provide.
So, for the current WildFly 26.1.2.Final; we would have 4 tags:
quay.io/wildfly/wildfly:26.1.2.Final-jdk11
quay.io/wildfly/wildfly:latest-jdk11
quay.io/wildfly/wildfly:26.1.2.Final-jdk17
quay.io/wildfly/wildfly:latest-jdk17
Once we release WildFly 27.0.0.Final, we would publish images for it and the latest-jdkXX
will point to their respective 27.0.0.Final-jdkXX tags.
For users that relies on the existing quay.io/wildfly/wildfly:latest tag, they will have
to update their images to use latest-jdk11 to keep pulling the latest image of WildFly
running on JDK11.
I’m waiting for confirmation that the images I’ve built works fine and then we will be
able to do the changes and push the image to the official quay.io/wildfly/wildfly
container registry.
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
9:14 p.m.
On 3 Nov 2022, at 12:59, Jean-Frederic Mesnil
<jmesnil(a)redhat.com> wrote:
I’m not planning to publish the latest tag anymore if we provide multiple jdk versions.
Actually I changed my mind on this and I think we should continue to provide a latest
tag.
The caveat with that floating tag is that it would point to the baseline JDK version that
we provide. For example for upcoming images that will be built with JDK 11 and JDK 17,
“latest” will point to “latest-jdk11”.
So the “latest” tag can be used to pull the image as usual.
But if/when we decide to stop producing JDK 11 images, the latest tag would then point to
latest-jdk17 (without notice).
I’d recommend to use the new latest-jdk11 and latest-jdk17 to avoid such surprises if you
want to stick to a given JDK version.
I’ve updated my PR to reflect this change at
https://github.com/jboss-dockerfiles/wildfly/pull/164
<https://github.com/jboss-dockerfiles/wildfly/pull/164/commits>
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
10:57 p.m.
On Fri, Nov 4, 2022 at 7:14 AM Jean-Frederic Mesnil <jmesnil(a)redhat.com>
wrote:
On 3 Nov 2022, at 12:59, Jean-Frederic Mesnil <jmesnil(a)redhat.com> wrote:
I’m not planning to publish the latest tag anymore if we provide multiple
jdk versions.
Actually I changed my mind on this and I think we should continue to
provide a latest tag.
The caveat with that floating tag is that it would point to the baseline
JDK version that we provide. For example for upcoming images that will be
built with JDK 11 and JDK 17, “latest” will point to “latest-jdk11”.
That seems odd to me. If we're going to continue to have 'latest' it seems
intuitive it would mean 'latest JDK' as well.
I get keeping 'latest' as 'JDK 11' for compatibility, and maybe that's
fine
right now as these changes haven't been socialized widely. But if we do
that I think we should also announce that at point XXX (some time soon) the
meaning of 'latest' will change to 'latest supported JDK'.
We might continue producing SE 11 images for a long time, but really people
should be using SE 17.
So the “latest” tag can be used to pull the image as usual.
But if/when we decide to stop producing JDK 11 images, the latest tag
would then point to latest-jdk17 (without notice).
I’d recommend to use the new latest-jdk11 and latest-jdk17 to avoid such
surprises if you want to stick to a given JDK version.
I’ve updated my PR to reflect this change at
https://github.com/jboss-dockerfiles/wildfly/pull/164
<https://github.com/jboss-dockerfiles/wildfly/pull/164/commits>
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
11:04 p.m.
On 4 Nov 2022, at 14:57, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
On Fri, Nov 4, 2022 at 7:14 AM Jean-Frederic Mesnil <jmesnil(a)redhat.com
<mailto:jmesnil@redhat.com>> wrote:
>
>
>> On 3 Nov 2022, at 12:59, Jean-Frederic Mesnil <jmesnil(a)redhat.com
<mailto:jmesnil@redhat.com>> wrote:
>>
>> I’m not planning to publish the latest tag anymore if we provide multiple jdk
versions.
>
>
> Actually I changed my mind on this and I think we should continue to provide a latest
tag.
>
> The caveat with that floating tag is that it would point to the baseline JDK version
that we provide. For example for upcoming images that will be built with JDK 11 and JDK
17, “latest” will point to “latest-jdk11”.
That seems odd to me. If we're going to continue to have 'latest' it seems
intuitive it would mean 'latest JDK' as well.
I get keeping 'latest' as 'JDK 11' for compatibility, and maybe
that's fine right now as these changes haven't been socialized widely. But if we
do that I think we should also announce that at point XXX (some time soon) the meaning of
'latest' will change to 'latest supported JDK’.Ok,
Ok, we can put use “latest” to point to the most recent version of JDK (so JDK17 now).
I find it more disruptive this way. As soon as we introduce e.g. JDK19, the users will
switch from JDK 17 to JDK 19 without notice.
Keeping latest on the baseline JDK leaves more time for users to change their JDK
settings.
In any case, I’d recommend to switch to latest-jdk11 or latest-jdk17 to avoid any abrupt
changes of JDK versions that we can have with latest.
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
1:49 a.m.
On Fri, Nov 4, 2022 at 9:05 AM Jean-Frederic Mesnil <jmesnil(a)redhat.com>
wrote:
On 4 Nov 2022, at 14:57, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
On Fri, Nov 4, 2022 at 7:14 AM Jean-Frederic Mesnil <jmesnil(a)redhat.com>
wrote:
>
>
> On 3 Nov 2022, at 12:59, Jean-Frederic Mesnil <jmesnil(a)redhat.com> wrote:
>
> I’m not planning to publish the latest tag anymore if we provide multiple
> jdk versions.
>
>
> Actually I changed my mind on this and I think we should continue to
> provide a latest tag.
>
> The caveat with that floating tag is that it would point to the baseline
> JDK version that we provide. For example for upcoming images that will be
> built with JDK 11 and JDK 17, “latest” will point to “latest-jdk11”.
>
That seems odd to me. If we're going to continue to have 'latest' it seems
intuitive it would mean 'latest JDK' as well.
I get keeping 'latest' as 'JDK 11' for compatibility, and maybe
that's
fine right now as these changes haven't been socialized widely. But if we
do that I think we should also announce that at point XXX (some time soon)
the meaning of 'latest' will change to 'latest supported JDK’.Ok,
Ok, we can put use “latest” to point to the most recent version of JDK (so
JDK17 now).
I find it more disruptive this way. As soon as we introduce e.g. JDK19,
the users will switch from JDK 17 to JDK 19 without notice.
Tangent: are you considering non-LTS SE versions?
Keeping latest on the baseline JDK leaves more time for users to
change
their JDK settings.
LTS discussion aside, this is a good point -- timing of introducing a new
image != timing of wanting people to move.
In any case, I’d recommend to switch to latest-jdk11 or latest-jdk17 to
avoid any abrupt changes of JDK versions that we can have with latest.
+1; that's probably the main thing; communicate that people should move off
'latest' as it doesn't have a particularly clear meaning. Keeping it on SE
11 is fine, even for as long as we support 11. If that proves too confusing
for people, we can adjust later (drop it, move it to 17 just because, etc)
and we've given plenty of notice that 'latest' isn't recommended.
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
5:09 p.m.
On 4 Nov 2022, at 17:49, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
> Ok, we can put use “latest” to point to the most recent version of JDK (so JDK17
now).
> I find it more disruptive this way. As soon as we introduce e.g. JDK19, the users
will switch from JDK 17 to JDK 19 without notice.
Tangent: are you considering non-LTS SE versions?
Yes.
I was planning to provide images for the most recent non-LTS SE version provided by
Temurin (so 19 right now). We would add jobs in ci.wildfly.org for these versions.
I want to maintain only 1 non-LTS SE version. So as soon as Temurin would release a 20
image, we would drop (ie stop releasing) our 19 images. The non-LTS images would be quite
short-lived but they would ensure that users can benefit on new JDK releases as soon as
they are delivered for new features.
> Keeping latest on the baseline JDK leaves more time for users to
change their JDK settings.
LTS discussion aside, this is a good point -- timing of introducing a new image != timing
of wanting people to move.
>
> In any case, I’d recommend to switch to latest-jdk11 or latest-jdk17 to avoid any
abrupt changes of JDK versions that we can have with latest.
+1; that's probably the main thing; communicate that people should move off
'latest' as it doesn't have a particularly clear meaning. Keeping it on SE 11
is fine, even for as long as we support 11. If that proves too confusing for people, we
can adjust later (drop it, move it to 17 just because, etc) and we've given plenty of
notice that 'latest' isn't recommended.
Something to consider is that WildFly 27 is by itself highly disruptive with the move to
the Jakarta EE namespace.
An application using “latest” from WildFly 26 will not be able to move to “latest” from
WildFly 27 without code changes.
Before making changes to the images, I’ll write an article for wildfly.org that explains
the images we will provide moving forward and their naming conventions.
But the TL;DR will be:
* WildFly images are based on Eclipse Temurin
* We provide images for LTS JDK 11 & 17 for each release of WildFly
* We provide images for the most recent non-LTS JDK version (19 at the moment)
* Each WildFly releases will have images with fixed tags: ${version}-jdk11,
${version}-jdk17, ${version}-jdk19
* There are floating tags to pull the latest release of WildFLy for each JDK version,
latest-jdk11, latest-jdk17, latest-jdk19
* The latest tag corresponds to the latest release of WildFly on a LTS release.
* For WildFly 26, latest will correspond to latest-jdk11 (to keep compatibility)
* For WildFly 27+, latest will correspond to latest-jdk17
* We recommend to pull from the latest-jdkXX tags instead of latest to guarantee using the
same JDK version across releases
I’ll write this blog post and make sure it properly communicates any changes (and new
features) the images will provide.
@Brian, are you ok with that plan?
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
10:39 p.m.
On Mon, Nov 7, 2022 at 2:10 AM Jean-Frederic Mesnil <jmesnil(a)redhat.com>
wrote:
On 4 Nov 2022, at 17:49, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
> Ok, we can put use “latest” to point to the most recent version of JDK
> (so JDK17 now).
> I find it more disruptive this way. As soon as we introduce e.g. JDK19,
> the users will switch from JDK 17 to JDK 19 without notice.
>
Tangent: are you considering non-LTS SE versions?
Yes.
I was planning to provide images for the most recent non-LTS SE version
provided by Temurin (so 19 right now). We would add jobs in ci.wildfly.org
for these versions.
I want to maintain only 1 non-LTS SE version. So as soon as Temurin would
release a 20 image, we would drop (ie stop releasing) our 19 images. The
non-LTS images would be quite short-lived but they would ensure that users
can benefit on new JDK releases as soon as they are delivered for new
features.
Keeping latest on the baseline JDK leaves more time for users to change
> their JDK settings.
>
LTS discussion aside, this is a good point -- timing of introducing a new
image != timing of wanting people to move.
>
> In any case, I’d recommend to switch to latest-jdk11 or latest-jdk17 to
> avoid any abrupt changes of JDK versions that we can have with latest.
>
+1; that's probably the main thing; communicate that people should move
off 'latest' as it doesn't have a particularly clear meaning. Keeping it on
SE 11 is fine, even for as long as we support 11. If that proves too
confusing for people, we can adjust later (drop it, move it to 17 just
because, etc) and we've given plenty of notice that 'latest' isn't
recommended.
Something to consider is that WildFly 27 is by itself highly disruptive
with the move to the Jakarta EE namespace.
An application using “latest” from WildFly 26 will not be able to move to
“latest” from WildFly 27 without code changes.
Before making changes to the images, I’ll write an article for wildfly.org
that explains the images we will provide moving forward and their naming
conventions.
But the TL;DR will be:
* WildFly images are based on Eclipse Temurin
* We provide images for LTS JDK 11 & 17 for each release of WildFly
* We provide images for the most recent non-LTS JDK version (19 at the
moment)
* Each WildFly releases will have images with fixed tags:
${version}-jdk11, ${version}-jdk17, ${version}-jdk19
* There are floating tags to pull the latest release of WildFLy for each
JDK version, latest-jdk11, latest-jdk17, latest-jdk19
* The latest tag corresponds to the latest release of WildFly on a LTS
release.
* For WildFly 26, latest will correspond to latest-jdk11 (to keep
compatibility)
* For WildFly 27+, latest will correspond to latest-jdk17
* We recommend to pull from the latest-jdkXX tags instead of latest to
guarantee using the same JDK version across releases
I’ll write this blog post and make sure it properly communicates any
changes (and new features) the images will provide.
@Brian, are you ok with that plan?
Yes, that sounds fine. Thanks, Jeff.
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
10:54 p.m.
As planned, we have published the new WildFly images based on Temurin for 27.0.0.Final and
26.1.2.Final.
The article at https://www.wildfly.org/news/2022/11/10/wildfly-docker-temurin/ highlights
the changes.
A huge thanks to Henri Laio[1] and Kris Gerhard[2] to have contributed to these
enhancements.
Best regards,
Jeff
[1] https://github.com/Henri-Laiho
[2] https://github.com/krisgerhard
On 7 Nov 2022, at 14:39, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
On Mon, Nov 7, 2022 at 2:10 AM Jean-Frederic Mesnil <jmesnil(a)redhat.com> wrote:
> On 4 Nov 2022, at 17:49, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
> Ok, we can put use “latest” to point to the most recent version of JDK (so JDK17
now).
> I find it more disruptive this way. As soon as we introduce e.g. JDK19, the users
will switch from JDK 17 to JDK 19 without notice.
>
> Tangent: are you considering non-LTS SE versions?
Yes.
I was planning to provide images for the most recent non-LTS SE version provided by
Temurin (so 19 right now). We would add jobs in ci.wildfly.org for these versions.
I want to maintain only 1 non-LTS SE version. So as soon as Temurin would release a 20
image, we would drop (ie stop releasing) our 19 images. The non-LTS images would be quite
short-lived but they would ensure that users can benefit on new JDK releases as soon as
they are delivered for new features.
> Keeping latest on the baseline JDK leaves more time for users to change their JDK
settings.
>
> LTS discussion aside, this is a good point -- timing of introducing a new image !=
timing of wanting people to move.
>
> In any case, I’d recommend to switch to latest-jdk11 or latest-jdk17 to avoid any
abrupt changes of JDK versions that we can have with latest.
>
> +1; that's probably the main thing; communicate that people should move off
'latest' as it doesn't have a particularly clear meaning. Keeping it on SE 11
is fine, even for as long as we support 11. If that proves too confusing for people, we
can adjust later (drop it, move it to 17 just because, etc) and we've given plenty of
notice that 'latest' isn't recommended.
Something to consider is that WildFly 27 is by itself highly disruptive with the move to
the Jakarta EE namespace.
An application using “latest” from WildFly 26 will not be able to move to “latest” from
WildFly 27 without code changes.
Before making changes to the images, I’ll write an article for wildfly.org that explains
the images we will provide moving forward and their naming conventions.
But the TL;DR will be:
* WildFly images are based on Eclipse Temurin
* We provide images for LTS JDK 11 & 17 for each release of WildFly
* We provide images for the most recent non-LTS JDK version (19 at the moment)
* Each WildFly releases will have images with fixed tags: ${version}-jdk11,
${version}-jdk17, ${version}-jdk19
* There are floating tags to pull the latest release of WildFLy for each JDK version,
latest-jdk11, latest-jdk17, latest-jdk19
* The latest tag corresponds to the latest release of WildFly on a LTS release.
* For WildFly 26, latest will correspond to latest-jdk11 (to keep compatibility)
* For WildFly 27+, latest will correspond to latest-jdk17
* We recommend to pull from the latest-jdkXX tags instead of latest to guarantee using
the same JDK version across releases
I’ll write this blog post and make sure it properly communicates any changes (and new
features) the images will provide.
@Brian, are you ok with that plan?
Yes, that sounds fine. Thanks, Jeff.
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
12:53 a.m.
Thank you so much Henri, Kris and Jeff. This is a very nice improvement!
On Thu, Nov 10, 2022 at 7:55 AM Jean-Frederic Mesnil <jmesnil(a)redhat.com>
wrote:
As planned, we have published the new WildFly images based on Temurin
for
27.0.0.Final and 26.1.2.Final.
The article at
https://www.wildfly.org/news/2022/11/10/wildfly-docker-temurin/
highlights the changes.
A huge thanks to Henri Laio[1] and Kris Gerhard[2] to have contributed to
these enhancements.
Best regards,
Jeff
[1] https://github.com/Henri-Laiho
[2] https://github.com/krisgerhard
> On 7 Nov 2022, at 14:39, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>
>
>
> On Mon, Nov 7, 2022 at 2:10 AM Jean-Frederic Mesnil <jmesnil(a)redhat.com>
wrote:
>
>
>> On 4 Nov 2022, at 17:49, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>> Ok, we can put use “latest” to point to the most recent version of JDK
(so JDK17 now).
>> I find it more disruptive this way. As soon as we introduce e.g. JDK19,
the users will switch from JDK 17 to JDK 19 without notice.
>>
>> Tangent: are you considering non-LTS SE versions?
>
>
> Yes.
> I was planning to provide images for the most recent non-LTS SE version
provided by Temurin (so 19 right now). We would add jobs in ci.wildfly.org
for these versions.
> I want to maintain only 1 non-LTS SE version. So as soon as Temurin
would release a 20 image, we would drop (ie stop releasing) our 19 images.
The non-LTS images would be quite short-lived but they would ensure that
users can benefit on new JDK releases as soon as they are delivered for new
features.
>
>> Keeping latest on the baseline JDK leaves more time for users to change
their JDK settings.
>>
>> LTS discussion aside, this is a good point -- timing of introducing a
new image != timing of wanting people to move.
>>
>> In any case, I’d recommend to switch to latest-jdk11 or latest-jdk17 to
avoid any abrupt changes of JDK versions that we can have with latest.
>>
>> +1; that's probably the main thing; communicate that people should move
off 'latest' as it doesn't have a particularly clear meaning. Keeping it on
SE 11 is fine, even for as long as we support 11. If that proves too
confusing for people, we can adjust later (drop it, move it to 17 just
because, etc) and we've given plenty of notice that 'latest' isn't
recommended.
>
>
> Something to consider is that WildFly 27 is by itself highly disruptive
with the move to the Jakarta EE namespace.
> An application using “latest” from WildFly 26 will not be able to move
to “latest” from WildFly 27 without code changes.
>
> Before making changes to the images, I’ll write an article for
wildfly.org that explains the images we will provide moving forward and
their naming conventions.
> But the TL;DR will be:
>
> * WildFly images are based on Eclipse Temurin
> * We provide images for LTS JDK 11 & 17 for each release of WildFly
> * We provide images for the most recent non-LTS JDK version (19 at the
moment)
> * Each WildFly releases will have images with fixed tags:
${version}-jdk11, ${version}-jdk17, ${version}-jdk19
> * There are floating tags to pull the latest release of WildFLy for each
JDK version, latest-jdk11, latest-jdk17, latest-jdk19
> * The latest tag corresponds to the latest release of WildFly on a LTS
release.
> * For WildFly 26, latest will correspond to latest-jdk11 (to keep
compatibility)
> * For WildFly 27+, latest will correspond to latest-jdk17
> * We recommend to pull from the latest-jdkXX tags instead of latest to
guarantee using the same JDK version across releases
>
> I’ll write this blog post and make sure it properly communicates any
changes (and new features) the images will provide.
>
> @Brian, are you ok with that plan?
>
> Yes, that sounds fine. Thanks, Jeff.
> Best regards,
> Jeff
>
> --
> Jeff Mesnil
> Principal Software Engineer
> Red Hat
> http://jmesnil.net/
>
>
>
> --
> Brian Stansberry
> Principal Architect, Red Hat JBoss EAP
> He/Him/His
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
544
days inactive
641
days old
14 comments
3 participants
participants (3)
-
Brian Stansberry -
Jean-Frederic Mesnil -
Jeff Mesnil