Epic Goal

• Create a new section in the Infrastructure Provider Onboarding Guide which gives instructions on how to utilize the External platform type. The documentation should give clear instructions to partners on how to enable External platform type, how to specify their unique provider name, and how to deploy Cloud Controller Managers. These instructions should also have configurations that are tested through automation to ensure the accuracy of documentation.

Why is this important?

• To reduce the development time and research complexity for partners, we should have clear documentation that instructs them on how to self-service their provider specific installations without needing to integrate code into OpenShift. Having these instructions will demonstrate to partners how they can customize their OpenShift installations (including deploying core components like CCMs and CSI drivers), which will ultimately make it easier for partners to create installations for their platforms.

Scenarios

1. A partner is just beginning their work to add their CCM and CSI driver to OpenShift so that they can provide better performance for their users. They use the Infrastructure Provider Onboarding Guide to inform their choices and plan their work. This allows them to enter the process with full knowledge of the changes they need to make and the scope of work.
2. Red Hat engineers want to confirm that the instructions for replacing CCMs are accurate. They use automated tests with well known platform components to confirm that the instructions are valid for partners and that there are no gaps in functionality.

Acceptance Criteria

• Partners can follow instructions in the provider onboarding documenation to create External platform installations including adding their unique provider name, custom CCM, and CSI driver.
• Continuous integration runs regular tests on the workflow described in the onboarding documentation.

Dependencies (internal and external)

1. Before writing the guidance for the partners who wish to seek "certified" compliance (eg replacing platform components), we will need to have great resolution on what those replacements look like. Effectively, this part of the work will depend on OCPPLAN-9429 and OCPCLOUD-1580 .

Previous Work (Optional):

1. Identifying OpenShift Components for Install Flexibility

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>