OCP/Telco Definition of Done
Epic Template descriptions and documentation.

<--- Cut-n-Paste the entire contents of this description into your new Epic --->

Epic Goal

Support arbitrary update of manifests generated by openshift-install create manifests before running openshift-install create cluster.

Why is this important?

Most use cases where manifests need to be a certain way fall into one of two categories:
1. openshift-install supports the configuration via the install-config.
2. The manifests eventually correspond to in-cluster objects which can be reconciled day 2 in various ways, including via hive's MachinePool and [Selector]SyncSet APIs, and day 2 is "soon enough".

However, certain cases exist where #1 isn't supported; and #2 is no good because the manifests need to be in the desired state for "day 0" - i.e. during the cluster creation process itself. Such as...

Use Case: As a developer who is using hive to deploy and managed an openshift fleet, I would like to instruct hive to deploy instances with an additional security group selector.

ODF Managed service is being delivered as a new OCM offering of type "Managed Service". An OCM managed service offering is a single bundle that consists of both compute and software (OCM addon) and is deployed as a single unit. 

ODF Managed service needs some inbound rules to be defined prior to the installation of the ODF software to complete a successful installation, without these inbound rules in place deployment will fail and the resulting deployment will be unrecoverable. 

To mitigate the issue the customer is expected to create a security group with the correct inbound rules prior to deploying ODF Managed service.

The issue is that OCM has no way to ask Hive to configure the cluster's machine pool to select and apply the security group that the customer has created prior to deployment, to the instances created from it.

Scenarios

1. ...

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. Node Team

Previous Work (Optional):

1. …

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>