[COMMUNITY] [community] WildFly Glow, introduce spaces to structure discovered Galleon feature-packs
Overview
Today WildFly Glow retrieves, for a given WildFly version, the Galleon feature-packs compatible with WildFly from a single location. There is a need for a finer grain way to structure feature-packs to reflect their "maturity" level.
We are here defining a generic solution that would allow users to expand the WildFly Glow discovery outside of the "default" space.
A good example would be the introduction of an 'experimental' space that would contain Galleon feature-packs that we know are not finalized and are expected to evolve in an incompatible way.
Issue Metadata
Issue
Related Issues
Stability Level
-
Experimental
-
Preview
-
Community
-
default
Dev Contacts
QE Contacts
-
TBD
Testing By
-
Engineering
-
QE
Affected Projects or Components
Other Interested Projects
Relevant Installation Types
-
Traditional standalone server (unzipped or provisioned by Galleon)
-
Managed domain
-
OpenShift s2i
-
Bootable jar
Requirements
WildFly Glow additional spaces
The current location where WildFly Glow retrieves the feature-packs is defined as the 'default' space. This space is always enabled. That is where WildFly Galleon feature-packs and feature-packs known to be mature are registered.
We are adding the ability to add spaces to the discovery context. A space contains additional feature-packs that come in addition to the feature-packs
registered in the default
space.
Space implementation
Spaces are located in the sub-directory spaces
of the current location.
Although a limited number of spaces are going to be defined (perhaps only one) an unbounded number of spaces can be defined. To allow for spaces discovery from the tools, some metadata is defined to list the known spaces.
The spaces sub-directory:
-
The spaces directory.
-
The spaces.yaml metadata file.
A space is composed of:
-
A set of directories containing Galleon provisioning.xml files for both bare-metal and cloud for both WildFly and WildFly Preview. Each directory is named with the WildFly version it targets. For example '34.0.0.Final'. Example of an incubating space
-
A versions.yaml file that contains the list of WildFly versions for which we have additional feature-packs.
-
For a given WildFly version, the additional feature-packs are added to Galleon
provisioning.xml
files:-
bare-metal provisioning.xml file
-
cloud provisioning.xml file
-
preview/bare-metal provisioning.xml file
-
preview/cloud provisioning.xml file
-
The experimental
space
This proposal defines the space experimental
in which Galleon feature-packs that are not yet stable can be registered.
Feature-packs registered in this space don’t offer any guarantee in term of backward compatibility. They can break in a next release. They can even
be unregistered.
A good first candidate for this space is the WildFly AI feature-pack
that is currently under development.
Moving from the experimental
space to the 'default' space
For a new WildFly major release, a feature-pack in the 'experimental' space can be removed and added to the default space. Such feature-pack should only contain features that are at least at the community stability level.
Expanding discovery to some additional spaces
This is a user action. By defaults, only the default space is seen by the WildFly Glow discovery. Other spaces are not seen by WildFly Glow. Spaces need to be explicitly added to the discovery context.
WildFly Glow command line
All commands that can expand the discovery context are evolved with the --spaces=<list of space names>
option.
WildFly Maven Plugin
The following XML configuration can be added to the <discover-provisioning-info>
XML element:
<discover-provisioning-info>
<spaces>
<space>[space name]</space>
...
</spaces>
</discover-provisioning-info>
Hard Requirements
-
A user should be able to specify additional spaces in which Galleon feature-packs are registered.
-
The release process in use to update the know feature-packs must take into account the additional spaces.
-
The WildFly Galleon feature-packs repository CI must take into account spaces and execute automated tests when new feature-packs are added to spaces.
Nice-to-Have Requirements
None
Non-Requirements
None
Future Work
-
Possibly define a space for the "preview" stability level
Backwards Compatibility
This evolution is backward compatible
Test Plan
-
Some tests are added to WildFly Glow and WildFly Maven plugin to cover the options allowing to set spaces.
Community Documentation
WildFly Glow community documentation is evolved with:
-
Documentation on how to enable spaces
-
Documentation of the existing spaces. The registered feature-packs and layers they are defining are documented.