You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
redhat-developer/rhdh#3970 added support for specifying the extraction dir via a new CATALOG_ENTITIES_EXTRACT_DIR env var, which we now need to set in the Install Methods (and additionally add the right volume mounts - we cannot create that folder right in the main container because the root filesystem is read-only for security purposes).
How to test changes / Special notes to the reviewer
Before
With the changes here
Checklist
For each Chart updated, version bumped in the corresponding Chart.yaml according to Semantic Versioning.
For each Chart updated, variables are documented in the values.yaml and added to the corresponding README.md. The pre-commit utility can be used to generate the necessary content. Use pre-commit run -a to apply changes. The pre-commit Workflow will do this automatically for you if needed.
JSON Schema template updated and re-generated the raw schema via the pre-commit hook.
Tests pass using the Chart Testing tool and the ct lint command.
The chart defaults add a new extensions-catalog entry under upstream.backstage.extraVolumes and extraVolumeMounts. Users who override these lists (rather than merging) may unintentionally drop required mounts/volumes after upgrading. Add explicit documentation/notes (e.g., README or values comments) explaining the new required entries and how to preserve/merge them when overriding.
extraVolumeMounts:
# The initContainer below will install dynamic plugins in this volume mount.
- name: dynamic-plugins-rootmountPath: /opt/app-root/src/dynamic-plugins-root
- name: extensions-catalogmountPath: /marketplace
- name: tempmountPath: /tmpextraVolumes:
# -- Ephemeral volume that will contain the dynamic plugins installed by the initContainer below at start.
- name: dynamic-plugins-rootephemeral:
volumeClaimTemplate:
spec:
accessModes:
- ReadWriteOnceresources:
requests:
# -- Size of the volume that will contain the dynamic plugins. It should be large enough to contain all the plugins.storage: 5Gi# Volume that will expose the `dynamic-plugins.yaml` file from the `dynamic-plugins` config map.# The `dynamic-plugins` config map is created by the helm chart from the content of the `global.dynamic` field.
- name: dynamic-pluginsconfigMap:
defaultMode: 420name: '{{ printf "%s-dynamic-plugins" .Release.Name }}'optional: true# Optional volume that allows exposing the `.npmrc` file (through a `dynamic-plugins-npmrc` secret)# to be used when running `npm pack` during the dynamic plugins installation by the initContainer.
- name: dynamic-plugins-npmrcsecret:
defaultMode: 420optional: truesecretName: '{{ printf "%s-dynamic-plugins-npmrc" .Release.Name }}'# Optional volume that allows adding a container registry `auth.json` file (through a `dynamic-plugins-registry-auth` secret)# to be used when installing plugins from secure container registries during the dynamic plugins installation by the initContainer.
- name: dynamic-plugins-registry-authsecret:
defaultMode: 416optional: truesecretName: '{{ printf "%s-dynamic-plugins-registry-auth" .Release.Name }}'
- name: npmcacacheemptyDir: {}
- name: extensions-catalogemptyDir: {}
- name: temp
CATALOG_ENTITIES_EXTRACT_DIR is set to /marketplace and the new extensions-catalog volume is an emptyDir. Confirm this is the intended persistence model (ephemeral) and that all components expecting extracted entities can read from this location in the correct container(s).
The newly added extensions-catalog volume/mount is introduced without the inline documentation style used for other volumes (e.g., purpose, whether optional, and sizing/behavior notes). This makes it harder for chart users to understand what the volume is for and whether it’s safe to change or override. (Ref 1, Ref 2)
- name: extensions-catalogmountPath: /marketplace
- name: tempmountPath: /tmpextraVolumes:
# -- Ephemeral volume that will contain the dynamic plugins installed by the initContainer below at start.
- name: dynamic-plugins-rootephemeral:
volumeClaimTemplate:
spec:
accessModes:
- ReadWriteOnceresources:
requests:
# -- Size of the volume that will contain the dynamic plugins. It should be large enough to contain all the plugins.storage: 5Gi# Volume that will expose the `dynamic-plugins.yaml` file from the `dynamic-plugins` config map.# The `dynamic-plugins` config map is created by the helm chart from the content of the `global.dynamic` field.
- name: dynamic-pluginsconfigMap:
defaultMode: 420name: '{{ printf "%s-dynamic-plugins" .Release.Name }}'optional: true# Optional volume that allows exposing the `.npmrc` file (through a `dynamic-plugins-npmrc` secret)# to be used when running `npm pack` during the dynamic plugins installation by the initContainer.
- name: dynamic-plugins-npmrcsecret:
defaultMode: 420optional: truesecretName: '{{ printf "%s-dynamic-plugins-npmrc" .Release.Name }}'# Optional volume that allows adding a container registry `auth.json` file (through a `dynamic-plugins-registry-auth` secret)# to be used when installing plugins from secure container registries during the dynamic plugins installation by the initContainer.
- name: dynamic-plugins-registry-authsecret:
defaultMode: 416optional: truesecretName: '{{ printf "%s-dynamic-plugins-registry-auth" .Release.Name }}'
- name: npmcacacheemptyDir: {}
- name: extensions-catalogemptyDir: {}
- name: temp
Reference reasoning: Existing volume entries (notably dynamic-plugins-root) include descriptive comments explaining intent and operational expectations (ephemeral PVC, storage sizing), and CI examples reinforce this documented/override-friendly pattern. Aligning extensions-catalog with the same documentation approach improves consistency and usability of values.yaml.
Add an additional /marketplace volume mount into the RHDH container via the Helm chart.
Set the catalog entities extraction directory to use that new /marketplace volume.
Non-compliant requirements:
Ensure Helm users who override extraVolumes / extraVolumeMounts are made aware of the change.
Requires further human verification:
Validate at deployment time that catalog entity extraction artifacts are actually written under /marketplace and that permissions/SELinux contexts are correct in OpenShift.
The CI values add the extensions-catalog volume but do not add the corresponding extraVolumeMounts entry for /marketplace. If this file is used in tests, the initContainer env CATALOG_ENTITIES_EXTRACT_DIR=/marketplace may point to a non-mounted path, potentially causing runtime/test failures or masking the intended behavior.
The change introduces a new default volume/volumeMount and a new env var affecting behavior. The ticket explicitly calls out that users overriding extraVolumes/extraVolumeMounts must be made aware; add an upgrade note / values documentation describing the new extensions-catalog mount at /marketplace and the CATALOG_ENTITIES_EXTRACT_DIR behavior to prevent breaking custom overrides.
# RHDH Backstage Helm Chart for OpenShift
A Helm chart for deploying Red Hat Developer Hub, which is a Red Hat supported version of Backstage.
The telemetry data collection feature is enabled by default. Red Hat Developer Hub sends telemetry data to Red Hat by using the `backstage-plugin-analytics-provider-segment` plugin. To disable this and to learn what data is being collected, see https://docs.redhat.com/en/documentation/red_hat_developer_hub/1.6/html-single/telemetry_data_collection_and_analysis/index**Homepage:**<https://red.ht/rhdh>## Productized RHDH
This repository now provides the productized RHDH chart.
For the **Generally Available** version of this chart, see:
*https://github.com/openshift-helm-charts/charts - official releases to https://charts.openshift.io/## Maintainers| Name | Email | Url || ---- | ------ | --- || Red Hat ||<https://redhat.com>|## TL;DR```consolehelm repo add bitnami https://charts.bitnami.com/bitnamihelm repo add backstage https://backstage.github.io/chartshelm repo add redhat-developer https://redhat-developer.github.io/rhdh-charthelm install my-backstage redhat-developer/backstage --version 5.0.0
Adding required volumes via overridable defaults is fragile
The PR adds a required volume by modifying default extraVolumes and extraVolumeMounts lists, which breaks configurations for users who override these values. A better approach is to define required volumes directly in the Helm template and merge them with any user-provided extra... values.
extraVolumes:
# -- Ephemeral volume that will contain the dynamic plugins installed by the initContainer below at start.
- name: dynamic-plugins-rootephemeral:
volumeClaimTemplate:
spec:
accessModes:
- ReadWriteOnceresources:
requests:
... (clipped 27 lines)
Solution Walkthrough:
Before:
# In values.yamlbackstage:
extraVolumeMounts:
- name: dynamic-plugins-root...
- name: extensions-catalog # <-- New required mountmountPath: /marketplaceextraVolumes:
- name: dynamic-plugins-root...
- name: extensions-catalog # <-- New required volumeemptyDir: {}# In templates (conceptual)# The entire list is replaced if user provides `extraVolumes`.volumes:
{{- toYaml .Values.backstage.extraVolumes | nindent 8 }}
After:
# In values.yamlbackstage:
extraVolumeMounts: [] # For user-defined mounts onlyextraVolumes: [] # For user-defined volumes only# In templates (conceptual)# Required volumes are hardcoded, user values are appended.volumes:
- name: dynamic-plugins-root...
- name: extensions-catalog # <-- Required volume is part of the templateemptyDir: {}# User-provided volumes are merged{{- toYaml .Values.backstage.extraVolumes | nindent 8 }}
Suggestion importance[1-10]: 9
__
Why: The suggestion correctly identifies a fragile design pattern where required volumes are added to overridable extra... lists, which is a breaking change for users who customize these values, and proposes a more robust standard Helm practice.
High
General
✅ Parameterize catalog mountPathSuggestion Impact:The commit addressed the underlying consistency issue by changing the catalog extract dir and primary volume mount from /marketplace to /extensions (and updating CATALOG_ENTITIES_EXTRACT_DIR accordingly), while keeping /marketplace as a legacy backward-compatible mount. It did not implement the exact templated parameterization of mountPath via the env value.
Parameterize the hardcoded /marketplace mount path for extensions-catalog in extraVolumeMounts to use the CATALOG_ENTITIES_EXTRACT_DIR value for better consistency and maintainability.
[To ensure code accuracy, apply this suggestion manually]
Suggestion importance[1-10]: 7
__
Why: The suggestion correctly identifies a hardcoded value and proposes parameterizing it to improve maintainability by using a value already defined in the chart, which is a good practice.
The reason will be displayed to describe this comment to others. Learn more.
Might need to be removed when redhat-developer/rhdh-plugins#2006 is merged and a new catalog index image is built. or we can still keep it for now for backward compatibility.
Add an additional /marketplace volume mount into the RHDH container (Helm chart change).
Non-compliant requirements:
Ensure Helm users who override extraVolumes / extraVolumeMounts are made aware, since defaults are changing.
Requires further human verification:
Validate in a real deployment that extensions are correctly extracted to the configured directory and appear in the Extensions UI.
Validate upgrade impact for existing Helm deployments that override extraVolumes / extraVolumeMounts (especially charts that may already define a volume with the same name).
The newly added CATALOG_ENTITIES_EXTRACT_DIR entry under the initContainer env list should be double-checked for correct indentation/list structure to ensure it is actually part of env (otherwise Helm may render invalid YAML or silently place it at the wrong level).
env:
- name: NPM_CONFIG_USERCONFIGvalue: /opt/app-root/src/.npmrc.dynamic-plugins# This following variable is required for orchestrator to startup properly.
- name: MAX_ENTRY_SIZEvalue: "30000000"
- name: CATALOG_INDEX_IMAGEvalue: '{{ .Values.global.catalogIndex.image.registry }}/{{ .Values.global.catalogIndex.image.repository }}:{{ .Values.global.catalogIndex.image.tag }}'
- name: CATALOG_ENTITIES_EXTRACT_DIRvalue: '/extensions'imagePullPolicy: ""
The defaults introduce a new extensions-catalog volume and mount it in two locations (/extensions and legacy /marketplace with readOnly: true). Verify this does not break existing workloads that expect to write to /marketplace, and ensure the new default volume name doesn’t conflict with common user overrides of extraVolumes/extraVolumeMounts.
"extraVolumeMounts": {
"default": [
{
"mountPath": "/opt/app-root/src/dynamic-plugins-root",
"name": "dynamic-plugins-root"
},
{
"mountPath": "/extensions",
"name": "extensions-catalog"
},
{
"mountPath": "/marketplace",
"name": "extensions-catalog",
"readOnly": true
},
{
"mountPath": "/tmp",
"name": "temp"
}
],
"items": {
"description": "VolumeMount describes a mounting of a Volume within a container.",
"properties": {
"mountPath": {
"description": "Path within the container at which the volume should be mounted. Must not contain ':'.",
"type": "string"
},
"mountPropagation": {
"description": "mountPropagation determines how mounts are propagated from the host to container and the other way around. When not set, MountPropagationNone is used. This field is beta in 1.10. When RecursiveReadOnly is set to IfPossible or to Enabled, MountPropagation must be None or unspecified (which defaults to None).",
"type": "string"
},
"name": {
"description": "This must match the Name of a Volume.",
"type": "string"
},
"readOnly": {
"description": "Mounted read-only if true, read-write otherwise (false or unspecified). Defaults to false.",
"type": "boolean"
},
"recursiveReadOnly": {
"description": "RecursiveReadOnly specifies whether read-only mounts should be handled recursively.\n\nIf ReadOnly is false, this field has no meaning and must be unspecified.\n\nIf ReadOnly is true, and this field is set to Disabled, the mount is not made recursively read-only. If this field is set to IfPossible, the mount is made recursively read-only, if it is supported by the container runtime. If this field is set to Enabled, the mount is made recursively read-only if it is supported by the container runtime, otherwise the pod will not be started and an error will be generated to indicate the reason.\n\nIf this field is set to IfPossible or Enabled, MountPropagation must be set to None (or be unspecified, which defaults to None).\n\nIf this field is not specified, it is treated as an equivalent of Disabled.",
"type": "string"
},
"subPath": {
"description": "Path within the volume from which the container's volume should be mounted. Defaults to \"\" (volume's root).",
"type": "string"
},
"subPathExpr": {
"description": "Expanded path within the volume from which the container's volume should be mounted. Behaves similarly to SubPath but environment variable references $(VAR_NAME) are expanded using the container's environment. Defaults to \"\" (volume's root). SubPathExpr and SubPath are mutually exclusive.",
"type": "string"
}
},
"required": [
"name",
"mountPath"
],
"type": "object"
},
"title": "Backstage container additional volume mounts",
"type": "array"
},
"extraVolumes": {
"default": [
{
"ephemeral": {
"volumeClaimTemplate": {
"spec": {
"accessModes": [
"ReadWriteOnce"
],
"resources": {
"requests": {
"storage": "5Gi"
}
}
}
}
},
"name": "dynamic-plugins-root"
},
{
"configMap": {
"defaultMode": 420,
"name": "{{ printf \"%s-dynamic-plugins\" .Release.Name }}",
"optional": true
},
"name": "dynamic-plugins"
},
{
"name": "dynamic-plugins-npmrc",
"secret": {
"defaultMode": 420,
"optional": true,
"secretName": "{{ printf \"%s-dynamic-plugins-npmrc\" .Release.Name }}"
}
},
{
"name": "dynamic-plugins-registry-auth",
"secret": {
"defaultMode": 416,
"optional": true,
"secretName": "{{ printf \"%s-dynamic-plugins-registry-auth\" .Release.Name }}"
}
},
{
"emptyDir": {},
"name": "npmcacache"
},
{
"emptyDir": {},
"name": "extensions-catalog"
},
{
The new extensions-catalog volume is configured as emptyDir, which ties catalog entity extraction storage to node ephemeral disk and can fail under disk-pressure or with larger catalogs. Validate whether this data should instead use an ephemeral.volumeClaimTemplate (PVC-backed) similar to how dynamic plugins storage is handled, especially if the extraction output can be sizable. (Ref 4, Ref 5)
# to be used when installing plugins from secure container registries during the dynamic plugins installation by the initContainer.
- name: dynamic-plugins-registry-authsecret:
defaultMode: 416optional: truesecretName: '{{ printf "%s-dynamic-plugins-registry-auth" .Release.Name }}'
- name: npmcacacheemptyDir: {}
- name: extensions-catalogemptyDir: {}
- name: tempemptyDir: {}
Reference reasoning: The chart’s existing pattern for storing dynamically installed plugin artifacts uses an ephemeral volume with a PVC claim template and an explicit storage request, indicating a preference for more predictable, size-bounded storage over emptyDir. Reusing that approach for extracted catalog entities would align storage behavior and reduce risk from node ephemeral disk limits.
Why: The suggestion correctly points out that a volume populated by an init container should be mounted as read-only by the main container to prevent accidental writes, which is a security and robustness best practice.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
rm3l
force-pushed
the
rhidp-11293-helm-chart-add-a-new-marketplace-volume-into-the-rhdh-pod-and-set-catalog-entities-extraction-dir-to-it
branch
from
Description
As discussed in https://redhat-internal.slack.com/archives/C04CUSD4JSG/p1767790419980379, we need to extract the catalog entities from the index image to the
/marketplace(to be replaced by/extensionsin redhat-developer/rhdh-plugins#2006) folder, so that the extensions backend providers can automatically discover them. Otherwise, there are no plugins displayed in the RHDH Extensions UI.redhat-developer/rhdh#3970 added support for specifying the extraction dir via a new
CATALOG_ENTITIES_EXTRACT_DIRenv var, which we now need to set in the Install Methods (and additionally add the right volume mounts - we cannot create that folder right in the main container because the root filesystem is read-only for security purposes).Which issue(s) does this PR fix or relate to
How to test changes / Special notes to the reviewer
Before
With the changes here
Checklist
Chart.yamlaccording to Semantic Versioning.values.yamland added to the corresponding README.md. The pre-commit utility can be used to generate the necessary content. Usepre-commit run -ato apply changes. The pre-commit Workflow will do this automatically for you if needed.pre-commithook.ct lintcommand.