Epic Goal

A cluster admin can express accepted risks for a cluster so that when a conditional update of cluster is requested,
it can be accepted only if the risks associated with the conditional update are all accepted.

Why is this important?

It is to reduce the time and effort for cluster administrators who manage many clusters, enabling them to pre-approve certain risks that they deem acceptable across some or all of their environments.

The request is brought up to OTA by Scott from the meetings with customers.

Scenarios (mandatory)

The feature is useful, e.g., in the following scenario:

• A cluster admin gets conditional updates of a cluster and evaluates the risks in the conditional updates.
• After evaluation, the admin decides that some risks can be accepted on all or some of the managed clusters.
• The administrator configures relevant clusters to allow for updates, as long as any identified risks have all been accepted.

Dependencies (internal and external)

The enhancement proposal about the epic and extensions of OpenShift API must be approved by their owners before further implementation can be carried out, e.g, to CVO and oc-cli.

Contributing Teams (and contacts)

Our expectation is that teams would modify the list below to fit the epic. Some epics may not need all the default groups but what is included here should accurately reflect who will be involved in delivering the epic.

• Development - OTA
• Documentation - OTA docs team
• QE - OTA
• PX - 
• Others -

Acceptance Criteria

For example, if a cluster admin accepts RiskA and RiskB and requests an update to a new version:

• The update is accepted if the update is recommended.
• The update is accepted if the cluster thought it was only exposed to RiskA.
• The update is accepted if the cluster thought it was only exposed to RiskA and RiskB.
• The update is rejected if the cluster thought it was only exposed to RiskC.
• The update is rejected if the cluster thought it was only exposed to RiskA and RiskC.

Drawbacks or Risk

Reasons we should consider NOT doing this is that we aren't particularly clear on which customer(s) (if any) would consume the new API. It makes sense to us in the updates team imagining a hypothetical customer with many clusters to update, but it would be good to find a customer who would read an enhancement proposal or other pitch and say "yes, I'd benefit from an API like that". And if we have the CVO reject updates that have not accepted some assessed risk or other issue, it would be good to know if there are any customers who think their workflows might be disrupted by needing to populate the new ClusterVersion spec.desiredUpdate.acceptedRisks (or whatever we end up calling it) property.

Done - Checklist

The following points apply to all epics and are what the OpenShift team believes are the minimum set of criteria that epics should meet for us to consider them potentially shippable. We request that epic owners modify this list to reflect the work to be completed in order to produce something that is potentially shippable.

• CI Testing - Tests are merged and completing successfully
• Documentation - Content development is complete.
• QE - Test scenarios are written and executed successfully.
• Technical Enablement - Slides are complete (if requested by PLM)
• Other