Feature Overview (aka. Goal Summary)

An elevator pitch (value statement) that describes the Feature in a clear,
concise way.

Installing RHDH (either via the Operator or Helm Chart) in an air-gapped environment is currently supported - see https://docs.redhat.com/en/documentation/red_hat_developer_hub/1.3/html/installing_red_hat_developer_hub_in_an_air-gapped_environment/index

However, the script currently seems outdated and may not work well in some setups.

For example, it might not work correctly in some (quite common) setups, e.g., when using an intermediate bastion host to connect to the cluster. Our current script (at least for the operator) assumes that the machine where it is running has access to the internal RH registries, which might not be the case.

We want our installation process to work in this situation.

Goals (aka. expected user outcomes)

The observable functionality that the user now has as a result of receiving
this feature. Include the anticipated primary user type/persona and which
existing features, if any, will be expanded.

Users can perform air-gapped installations in environments with a bastion host as an intermediary, enabling secure and automated deployment workflows. This includes capabilities to mirror the required images, apply updates, and retrieve logs through the bastion host, without direct access to the internal RH registries.

Primary personas are system administrators and DevOps engineers working in high-security isolated environments, where connecting to a bastion host is a prerequisite.

We also need to make sure to use (as much as possible) the official RH supported methods for mirroring things (like using the `oc mirror` command?)

Requirements (aka. Acceptance Criteria):

 

A list of specific needs or objectives that a feature must deliver in order
to be considered complete. If the feature spans across releases then good
to have scope for each release with acceptance criteria. Be sure to
include nonfunctional requirements such as security, reliability,
performance, maintainability, scalability, usability, etc.

• The airgap install script is maintained and works.

 

• The airgap installation process can utilize a bastion host. It either runs directly on the bastion host (taking as input all the necessary images that need to be mirrored), or can take as input the bastion host details (IP, port, creds) and directly connect to it.
• Comprehensive error messages (as well as possible mitigation measures) are provided when issues arise during the installation process
• The existing airgap installation method (without bastion hosts) remains fully functional and unaffected by this new feature
• Documentation is updated accordingly
• Demo

Out of Scope (Optional)

 

High-level list of items that are out of scope.

- Setting up, configuring, or maintaining the bastion host itself. This is a prerequisite that users are expected to already have.

 

Customer Considerations (Optional)

 

Provide any additional customer-specific considerations that must be made
when designing and delivering the Feature. Initial completion during
Refinement status.

* Isolated environments with a bastion host seem quite common as a use case

 

Documentation Considerations

Provide information that needs to be considered and planned so that
documentation will meet customer needs. If the feature extends existing
functionality, provide a link to its current documentation.

Need to update https://docs.redhat.com/en/documentation/red_hat_developer_hub/1.3/html/installing_red_hat_developer_hub_in_an_air-gapped_environment/index#proc-install-rhdh-airgapped-environment-ocp-operator_title-install-rhdh-air-grapped