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

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

• I have standardized configurations for the platform which I need to automate the deployment. I do not consider the platform fully deployed until the underlying kubernetes cluster as well as the standardized configuration is successfully deployed and configured. For example, to properly configure a SNO cluster to host the DU workload, I need to customize the platform. This requires the orchestrator to deploy about 6-8 operators (policies) and watch the status of each. 
• If the configuration changes, the orchestration logic needs to be updated to include the logic to deploy the new entity as well as to watch the status of the new configuration item.

Epic Goal

• Enable one to manage the lifecycle of Profiles, i.e. create them, define their contents as well as delete them. 
• As part of Day 1 operations, the profile provides an aggregate interface that enables one to customize the newly created cluster for a specific usage. 

Why is this important?

• When deploying OpenShift, the result is a general configuration of OpenShift. As we know, clusters are used for different purposes, i.e. host different types of workloads and/or reside in different environments which require specific customization. Thus, they might require different configurations to host those workloads. For example, 
• an SNO cluster might be hosting a 5G DU workload. In this case, the SNO clusters need to have the appropriate configuration, e.g. PTP operator, SR-IOV configuration, log collector to export to Kafka, etc.
• An SNO cluster might be hosting a 5G CU workload. Similar to above, they would have a different set of configurations applied.

• • In addition to easily defining the profile content, the real value provided is the ability to get aggregated status. When one deploys a profile to clusterX, they do not need to understand the individual members of the profile. Nor do they need to monitor the status of each member. They just need to get the status of the profile.
• Examples of individual members in a profile:
• ACM Policy - this is the MVP
• Ansible Role
• ACM Application (ArgoCD)

• A profile contains configuration information, workloads, etc.
  • Enhance a customer's user experience when:

• • deploying configuration profiles
  • determining if the profile has been deployed to a cluster(s)
  • determining the status of the profile on a specific cluster
• Status of the profile is the aggregate status (pass or fail) of all members of the profile. The aggregate is based on the worst status of any member in the profile. For example, if one out of the ten members of the profile failed, then the profile status is fail.

Note: The current method requires deep knowledge of multiple moving parts.

• Provide the ability to modify the profile content w/o having to 
• train operations/administrators, i.e. they do not need to understand the detailed content of the profile
• Modify orchestration tooling which deploys and checks the status of the profile

Scenarios

1. I need to prepare the DU profile which will be used on the 10,000s of SNO clusters being provisioned.  
2. I need to deploy a profile as part of the Day 1 operations. After the cluster is provisioned successfully, I want to apply a profile to the cluster.  
3. In the case of a failed profile deployment, I need the ability to remove the profile from the cluster.  
4. I need to control who can modify the contents of a profile. It is important to ensure that the appropriate configuration content is in the profile and nothing more. An invalid content could jeopardize the workload. 
5. Each deployed profile has its own status.

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• The deletion of the profile definition on the Hub Cluster will not delete the definition of any of the contents of that profile.  
• A profile on the Hub cluster cannot be deleted if it is deployed to ≥ 1 managed cluster.
• The contents of the profile are configuration items.
• The contents of a deployed profile can be modified, but when a change occurs, the status of the deployed profile must go to “pending”.
• Profile shows completion status, i.e. status=failed, when at least 1 configuration item in the profile fails.
• MVP: There is no guarantee of order for the contents of a profile
• The same profile cannot be deployed to the same managed cluster if it already exists on that managed cluster.
• Profiles are independent of each other.
• Profile can be used with any configuration object (e.g. policies)
• If a profile fails, the user must manually delete the deployed profile and redeploy it.
• Profile doesn't take into account any prerequisites.
• Only cluster admins can create, add, and delete the contents of a profile.
• Only cluster admins can create and delete profiles.
• Only cluster admins can remove deployed profiles.
• Only cluster admins can deploy profiles.
• Non-cluster admins can view profiles.
• Non-cluster admins can view the contents of a profile.

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. What if we remove an individual member from the profile after it has been deployed? What will the status be? Will it still count as success since we're not concerned with if the member has been removed?
   The status is reflective of the worst status of any one element.  We can not control the impl of the individual configuration items.  Even if the status goes to “removing” and eventually success when the item is fully removed.  Unless you are doing a watch, you will probably miss the “removing” status (if there at all).

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>
• Profile interface is created (code) and consumable
• Profile interface has CI testing surrounding its functionality

MVP

• **Profiles must be deployed explicitly and only to a managed cluster that's availableUnconcerned about profile prerequisites 

• No ordering of members of the profile 

• Profiles are independent

• • So if you deploy profile "foo" and it's in progress (status hasn't aggregated), you can also deploy profile "bar" to the same managed cluster 

• The same profile cannot be deployed if it already has been deployed to a managed cluster

• If a profile fails, the user has to manually remove the deployed profile from the managed cluster before they can redeploy it 
  • This means we need some logic to ensure that the same profile hasn't been deployed 

• • • How do we compare? Is it by name, by members, or both?