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).
This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please assign kim-tsao for approval. For more information see the Code Review Process.
The full list of commands accepted by this bot can be found here.
Details
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
rm3l
changed the title
fix: add volume for extension catalog entities in 1.9+ [RHIDP-11292]
fix: add volume for extension catalog entities [RHIDP-11292]
Jan 9, 2026
Add an additional /marketplace volume mount into the RHDH container.
Ensure catalog entities extraction directory is set to the new volume/mount (so extracted entities land on that mounted storage).
Non-compliant requirements:
(none)
Requires further human verification:
Validate at runtime that catalog entity extraction actually writes to CATALOG_ENTITIES_EXTRACT_DIR=/extensions and that /marketplace alias behavior remains backward compatible for existing extensions.
Validate that the volume is mounted in all operator-managed deployment variants (e.g., upgrades, different profiles) and not only in the default-config templates/manifests.
The same volume extensions-catalog is mounted to both /extensions and legacy /marketplace with readOnly: true on the legacy path. Confirm that anything still expecting to write under /marketplace will not break (even indirectly), and that all writers now use /extensions (via CATALOG_ENTITIES_EXTRACT_DIR).
- name: extensions-catalogmountPath: /extensions
- name: extensions-catalog# TODO(asoro): legacy path for backward compatibility. Will be removed in a near future.mountPath: /marketplacereadOnly: true
- mountPath: /tmp
The createdAt field changed; if this file is expected to be generated, ensure it is updated by the correct release/bundle tooling and won’t cause noisy diffs or conflicts in downstream automation.
createdAt: "2026-01-09T20:08:15Z"description: Red Hat Developer Hub is a Red Hat supported version of Backstage.
The new CATALOG_ENTITIES_EXTRACT_DIR env var value is single-quoted ('/extensions') while other env var path values in similar manifests are left unquoted. Align the quoting style (prefer unquoted or consistent double quotes) to avoid accidental escaping/formatting differences when these manifests are embedded or templated. (Ref 2)
Reference reasoning: Similar deployment/config YAML in the repo sets filesystem path env vars as plain scalars (e.g., /opt/app-root/src/.npmrc.dynamic-plugins), indicating a consistent convention that avoids introducing unnecessary quoting differences.
Instead of mounting the same volume to both /extensions and /marketplace for backward compatibility, consider using a symbolic link. This simplifies the Kubernetes manifests and avoids a confusing dual-mount pattern.
- name: extensions-catalogmountPath: /extensions
- name: extensions-catalog# TODO(asoro): legacy path for backward compatibility. Will be removed in a near future.mountPath: /marketplacereadOnly: true
- name: extensions-catalogmountPath: /extensions
- name: extensions-catalog# TODO(asoro): legacy path for backward compatibility. Will be removed in a near future.mountPath: /marketplacereadOnly: true
Why: The suggestion correctly identifies an unusual dual-volume-mount pattern for backward compatibility and proposes cleaner, more idiomatic alternatives like using a symbolic link, which improves the maintainability of the Kubernetes manifests.
Medium
Security
Make extension mount read-only
Improve security by making the extensions-catalog volume mount at /extensions read-only for the main container.
Why: The suggestion correctly identifies that the /extensions volume mount could be made read-only for the main container, which is a good security practice.
Low
Organization best practice
Strengthen volume mount assertions
Include the expected Name (and ReadOnly where applicable) for the new mounts and assert against it, so the test ensures /extensions and /marketplace are backed by extensions-catalog as intended.
[To ensure code accuracy, apply this suggestion manually]
Suggestion importance[1-10]: 6
__
Why:
Relevant best practice - Write assertions that fully validate critical configuration (e.g., volume mount Name/ReadOnly) to avoid false positives and improve test robustness.
Low
Document new extension catalog volume
Document the new extensions-catalog volume and the CATALOG_ENTITIES_EXTRACT_DIR default (including the 1.9+ behavior and the /marketplace legacy mount and its planned removal) so users understand where catalog entities are extracted and how to override/disable it.
-...+## Extension catalog entities (1.9+)+Starting with **RHDH 1.9**, the Operator mounts an `emptyDir` volume named `extensions-catalog` and configures dynamic plugin catalog extraction into it.++- Default extract directory: `CATALOG_ENTITIES_EXTRACT_DIR=/extensions`+- Mounted paths:+ - `/extensions` (read/write)+ - `/marketplace` (read-only **legacy** path for backward compatibility; will be removed in a future release)++If you customize the Deployment/Pod template, ensure the `extensions-catalog` volume and corresponding mounts are preserved, or set `CATALOG_ENTITIES_EXTRACT_DIR` to match your desired mount path.+
[To ensure code accuracy, apply this suggestion manually]
Suggestion importance[1-10]: 5
__
Why:
Relevant best practice - Keep documentation synchronized with implementation changes, specifying versions, defaults, and behavior changes to avoid user confusion when behavior evolves.
Low
General
Assert extension volume exists
Enhance the integration test by adding an explicit assertion to verify the presence and configuration of the extensions-catalog volume.
g.Expect(deploy.PodSpec().Volumes).To(HaveLen(8))
+{+ found := false+ for _, v := range deploy.PodSpec().Volumes {+ if v.Name == "extensions-catalog" {+ found = true+ g.Expect(v.EmptyDir).NotTo(BeNil())+ }+ }+ g.Expect(found).To(BeTrue())+}
Apply / Chat
Suggestion importance[1-10]: 5
__
Why: This suggestion improves the test by adding a more specific assertion for the extensions-catalog volume, making the test more robust against future changes.
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.
Non-compliant requirements:
(empty)
Requires further human verification:
Confirm at runtime that the extracted catalog entities are written to the intended directory and that the Extensions UI discovers them correctly with the new mount(s).
The test asserts an exact volume count (HaveLen(8)), which can become flaky as unrelated volumes are added/removed. Consider asserting presence of the new volume (extensions-catalog) and expected mounts/paths instead of a strict total count.
The same volume (extensions-catalog) is mounted twice in the same container at two different paths (/extensions and /marketplace), with only one of them marked readOnly. Validate that this duplication is intentional and doesn’t create confusing semantics (e.g., writes via /extensions still affect the data visible via /marketplace despite it being readOnly). (Ref 3, Ref 4)
- name: extensions-catalogmountPath: /extensions
- name: extensions-catalog# TODO(asoro): legacy path for backward compatibility. Will be removed in a near future.mountPath: /marketplacereadOnly: true
Reference reasoning: Existing operator-managed deployment YAML consistently mounts each volume a single time per container (e.g., default-config and plugin-deps), avoiding multiple mount points to the same backing volume. Aligning with that pattern reduces ambiguity and makes access mode expectations clearer.
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
changed the title
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
PR acceptance criteria
How to test changes / Special notes to the reviewer
Before
With the changes here