2:50 p.m.
Hello! Resending this message originally sent on 2021-07-27 since the
non-delivery issue on this mailing list has been resolved.
I’m currently reviewing the proposal [1] of WFLY-14934 [2] feature request
and I’m struggling to understand what are the objectives of this feature.
The “Relevant Installation Types” section with selected “OpenShift s2i” in
the proposal [1] suggest this feature is OpenShift focused. However the
only differences between this new feature and existing bootable JAR can be
observed on bare metal. On bare metal this feature brings the same features
as bootable JAR does but it adds three things: persistent configuration,
multiple deployments and direct access to each file of the provisioned
server. In S2I scenarios there seems to be no difference between bootable
JAR and this feature. Form of the server in the application image is as far
as I know transparent for the user.
What are the real use-case scenarios of this feature?
Regards, Honza
[1] https://github.com/wildfly/wildfly-proposals/pull/401/files
[2] https://issues.redhat.com/browse/WFLY-14934 and
https://issues.redhat.com/browse/EAP7-1734
--
Jan (Honza) Kasik
Quality Engineer, EAP QE
3:07 p.m.
Hi Jan
On 23 Aug 2021, at 14:50, Jan Kašík <jkasik(a)redhat.com> wrote:
Hello! Resending this message originally sent on 2021-07-27 since the non-delivery issue
on this mailing list has been resolved.
I’m currently reviewing the proposal [1] of WFLY-14934 [2] feature request and I’m
struggling to understand what are the objectives of this feature.
The “Relevant Installation Types” section with selected “OpenShift s2i” in the proposal
[1] suggest this feature is OpenShift focused.
It’s not emphasized enough in the proposal but this RFE *also adds a new installation
type*: Maven-controlled standalone server
This is distinct from “traditional standalone server” (that we often refer to as “Bare
Metal” as the application pom.xml is now controlling the installation and provisioning of
WildFly.
This is a significant improvement for the WildFly users as WildFly server becomes a
component owned and controlled from their application pom.xml.
They will no longer have to download and install WildFly separately before being able to
write, test and deploy their applications.
In S2I scenarios there seems to be no difference between bootable JAR
and this feature. Form of the server in the application image is as far as I know
transparent for the user.
We are introducing this new installation type (which is really a generalisation of the
bootable jar) as it provides a consistent mechanism to build and deploy WildFly
applications on the cloud and on OpenShift.
Most of the configuration that was done in S2I will be moved to Galleon feature packs.
This introduces several benefits:
* These feature packs will be simpler to update and maintain and will not require new
images for every WildFly releases
* We can provide alternative to S2I building on top of this installation type (e.g. CNCF
Buildpacks)
* This installation type allows integration testing with Arquillian using the actual
provisioned server that will be deployed on the Cloud (or on bare metal).
Before I left for PTO, I was writing a mail about this feature and I will make sure to
post it this week on this mailing list.
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
970
days inactive
970
days old
1 comments
2 participants
participants (2)
-
Jan Kašík -
Jean-Frederic Mesnil