HOWTO Create a Booster Catalog (RHOAR)

RHOAR Booster Catalog

First read the Generic page on how to set up a Booster catalog. It will explain the basic requirements for a Booster Catalog. This page will explain the RHOAR-specific extensions to the generic format.

Catalog Metadata

The repository has a metadata.yaml file in the root containing a list of the supported missions and runtimes along with their human-readable names and other information. The basic format is like this:

missions:
- id: ID
  name: NAME
  description: DESCRIPTION
  metadata:
    CUSTOM_ATTRIBUTE: CUSTOM_VALUE
    ...
  ...
runtimes:
- id: ID
  name: NAME
  description: DESCRIPTION
  icon: ICON_URL_OR_DATA
  metadata:
    CUSTOM_ATTRIBUTE: CUSTOM_VALUE
    ...
  versions:
  - id: ID
    name: NAME
    description: DESCRIPTION
    metadata:
      CUSTOM_ATTRIBUTE: CUSTOM_VALUE
    ...
    ...
  ...

Where each of the fields have the following function:

• ID is an identifier for a Mission, Runtime or Version. This must be the same as the folder name used to contain the boosters that belong to it in the Booster Catalog folder structure (see below)!
• NAME is a short human-readable name for display purposes in the Launcher UI
• DESCRIPTION is a longer description to be shown in the Launcher UI (Optional)
• ICON_URL_OR_DATA is either a URL to an image or a data:image value containing actual image data to be used for display purposes in the Launcher UI
• CUSTOM_ATTRIBUTE and CUSTOM_VALUE are custom attributes and values of any kind that can be used in the metadata section

An example of such a metadata.yaml might be (removed icon data):

missions:
- id: crud
  name: CRUD
- id: circuit-breaker
  name: Circuit Breaker
- id: configmap
  name: Externalized Configuration
runtimes:
- id: vert.x
  name: Eclipse Vert.x
  icon: ...
  metadata:
    pipelinePlatform: maven
  versions:
  - id: redhat
    name: 3.4.2.redhat-006 (RHOAR)
  - id: community
    name: 3.5.0.Final (Community)
- id: spring-boot
  name: Spring Boot
  icon: ...
  metadata:
    pipelinePlatform: maven
  versions:
  - id: 1.5.10-community
    name: 1.5.10.RELEASE (Community)
  - id: 1.5.10-redhat
    name: 1.5.10.RELEASE (RHOAR)
- id: wildfly-swarm
  name: WildFly Swarm
  icon: ...
  metadata:
    pipelinePlatform: maven
  versions:
  - id: community
    name: 2017.10.0 (Community)
  - id: redhat
    name: 7.0.0.redhat-8 (RHOAR)

IMPORTANT: If a new mission or runtime is introduced, you MUST change the metadata.yaml file too.

Catalog Structure

This repository is organized by {runtime}/{version}/{mission}/booster.yaml. Regardless if your booster supports runtime versions or not you'll have to specify at least a single {version} folder. If you don't know what to call it use default. In the example below we can see a "wildfly-swarm" Runtime with two Versions, one for "community" and one for "redhat", where both have two Missions, "health-check" and "rest-http":

Booster Descriptor

As mentioned above in the Catalog Structure, for each Booster we create a YAML file in the respective {mission}/{runtime}/{version} directory named booster.yaml. In it should/can be all the information described in the Generic page, but on top of that we have extra information we can put in the metadata section:

Name	Description
metadata/runsOn	(Optional) A single cluster type or a list of cluster types where this booster can run. A type can be prefixed with ! to negate the option: the booster will not run on clusters of that type. Special values all and none indicate the booster will run everywhere or nowhere respectively. Important: when using the ! to negate you must surround it and the cluster type name with double quotes.
metadata/buildProfile	(Optional) The Maven profile that should be activated in the booster's pom.xml file
worksWithLegacyOsio	(Optional) If set to true the booster will be available for the legacy OSIO application