[COMMUNITY]  [community] WildFly Glow, introduce spaces to structure discovered Galleon feature-packs

In  wf-galleon
Tracked by https://github.com/wildfly/wildfly-proposals/issues/625

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

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:

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:

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.

Release Note Content