Metadata and the UI catalog

The Validated Patterns Operator console plugin displays patterns from a catalog served on-cluster. pattern-metadata.yaml in each pattern repository is normalized into that catalog so the Pattern Catalog page can render pattern cards, sizing details, and install flows. Use this information when you prepare a pattern for inclusion in the UI catalog or when you troubleshoot missing catalog entries.

Source format and catalog format

Pattern repositories store pattern-metadata.yaml in a source format that existing patterns use today. The pattern-ui-catalog repository converts that file into a catalog format before the UI consumes it.

The catalog generator (generate-catalog.sh) applies these normalizations:

Change Source format (pattern-metadata.yaml) Catalog format (catalog/<name>/pattern.yaml)

Change	Source format (`pattern-metadata.yaml`)	Catalog format (`catalog/<name>/pattern.yaml`)
Cloud provider nesting	`requirements.hub.compute.platform.aws`	`requirements.hub.compute.aws` (the `platform` wrapper is removed)
Pattern owners	Comma-separated string (`owners: user1, user2`) or YAML array	YAML array of usernames
GitHub organization	Not present in the source file	`org` field added from the repository GitHub organization
Default cluster group	Not present in the source file	`clustergroupname` added from `values-global.yaml` → `main.clusterGroupName` when available
Optional fields	Can be omitted	`external_requirements`, `extra_features`, `docs_repo_url`, `ci_url`, and `spoke` default to `null` when absent

Cloud provider nesting

requirements.hub.compute.platform.aws

requirements.hub.compute.aws (the platform wrapper is removed)

Pattern owners

Comma-separated string (owners: user1, user2) or YAML array

YAML array of usernames

GitHub organization

Not present in the source file

org field added from the repository GitHub organization

Default cluster group

Not present in the source file

clustergroupname added from values-global.yaml → main.clusterGroupName when available

Optional fields

Can be omitted

external_requirements, extra_features, docs_repo_url, ci_url, and spoke default to null when absent

The authoritative schema for catalog files is pattern.schema.json. For field definitions and required keys, see Schema and field reference. For validation commands, see Validation and troubleshooting.

Catalog discovery and publication

The pattern-ui-catalog project runs generate-catalog.sh, which queries GitHub for public repositories tagged with ui-catalog-enabled in the validatedpatterns and validatedpatterns-sandbox organizations.
For each repository, the script fetches pattern-metadata.yaml from the default branch.
If the file is missing or cannot be parsed, the repository is skipped.
The script normalizes the metadata and writes:
- catalog/catalog.yaml — index listing all discovered pattern names
- catalog/<pattern-name>/pattern.yaml — normalized metadata for one pattern
- catalog/<pattern-name>/values-secret.yaml.template — optional secret template copy
The catalog directory is built into a container image (quay.io/validatedpatterns/pattern-ui-catalog) and deployed by the operator.

To include a pattern in the UI catalog, tag the GitHub repository with the ui-catalog-enabled topic and ensure pattern-metadata.yaml is present and parseable.

On-cluster catalog access

The console plugin fetches catalog data through a proxy path:

/api/proxy/plugin/patterns-operator-console-plugin/pattern-ui-catalog/catalog.yaml
/api/proxy/plugin/patterns-operator-console-plugin/pattern-ui-catalog/<pattern>/pattern.yaml

The plugin loads catalog.yaml, then fetches each listed pattern.yaml. You can override the catalog image by patching the patterns-operator-config ConfigMap catalog.image key. For more information about custom catalogs, see the pattern-ui-catalog README.

Fields the UI renders

The Pattern Catalog page in the Red Hat Hybrid Cloud Console uses these metadata fields:

Field UI usage

Field	UI usage
`display_name`	Pattern card title
`description`	Card body text
`tier`	Tier label with color coding (`maintained`, `tested`, `sandbox`) and filter control
`logo`	Pattern logo on the card (absolute URL, or path relative to the catalog entry)
`org`	Tooltip on the card title
`requirements`	Cloud provider labels and hub/spoke sizing summary with detailed tooltip per cloud (`aws`, `gcp`, `azure`)
`external_requirements.cluster_sizing_note`	"Additional requirements" info icon and tooltip
`docs_url`, `repo_url`	External link buttons on the card
`name`	Install, uninstall, and secrets management navigation

display_name

Pattern card title

description

Card body text

tier

Tier label with color coding (maintained, tested, sandbox) and filter control

logo

Pattern logo on the card (absolute URL, or path relative to the catalog entry)

org

Tooltip on the card title

requirements

Cloud provider labels and hub/spoke sizing summary with detailed tooltip per cloud (aws, gcp, azure)

external_requirements.cluster_sizing_note

"Additional requirements" info icon and tooltip

docs_url, repo_url

External link buttons on the card

name

Install, uninstall, and secrets management navigation

The catalog cards do not render ci_url, issues_url, owners, or extra_features. When a pattern defines variants in metadata, the operator install flow presents a variant selector so you can choose a deployment topology before installation. Install flows also use fields such as clustergroupname and repo_url when creating a Pattern custom resource.

For more information about installing patterns through the operator, see Using the Validated Patterns Operator.