doc: updated wording and updated reviewers and approvers

added clearity on risks and goals

Signed-off-by: ehila <[email protected]>

Author: eggfoobar

enhancements/workload-partitioning/wide-availability-workload-partitioning.md

@@ -3,13 +3,11 @@ title: wide-availability-workload-partitioning
 authors:
   - "@eggfoobar"
 reviewers:
-  - TBD
+  - "@jerpeter1"
 approvers:
-  - TBD
-api-approvers:
-  - TBD
+  - "@jerpeter1"
 creation-date: 2022-08-03
-last-updated: 2022-08-08
+last-updated: 2022-08-09
 tracking-link:
   - https://issues.redhat.com/browse/CNF-5562
 see-also:
@@ -57,6 +55,9 @@ determinism required of my applications.
   masters and for workers, 2 hyperthreaded cores.
 - We want a general approach, that can be applied to all OpenShift control plane
   and per-node components via the PerformenceProfile
+- We want to be clear with customers that this enhancement is a day 0 supported
+  feature only. We do not support turning it off after the installation is done
+  and the feature is on.
 
 ### Non-Goals
 
@@ -83,10 +84,7 @@ but slightly different non-goals
 - This enhancement assumes that the configuration of a management CPU pool is
   done as part of installing the cluster. It can be changed after the fact but
   we will need to stipulate that, that is currently not supported. The intent
-  here is for this to be supported as a day 0 feature.
-- This enhancement describes partitioning concepts that could be expanded to be
-  used for other purposes. Use cases for partitioning workloads for other
-  purposes may be addressed by future enhancements.
+  here is for this to be supported as a day 0 feature, only.
 
 ## Proposal
 
@@ -278,6 +276,26 @@ day 0 configuration and day n+1 alterations are not be supported with this
 enhancement. Part of that messaging should involve a clear indication that this
 should be a cluster wide feature.
 
+A risk we can run into is that a customer can apply a CPU set that is too small
+or out of bounds can cause problems such as extremely poor performance or start
+up errors. Mitigation of this scenario will be to provide proper guidance and
+guidelines for customers who enable this enhancement. Furthermore, the
+performance team would need to be reached out to for more specific information
+around upper and lower bounds of CPU sets for running an Openshift cluster.
+
+It is possible to build a cluster with the feature enabled and then add a node
+in a way that does not configure the workload partitions only for that node. We
+do not support this configuration as all nodes must have the feature turned on.
+However, there might be a race condition where a node is added and is in the
+process of being restarted with workload partitioning, during that process pods
+being admitted will trigger a warning. We expect the resulting error message
+described in [failure modes](#failure-modes) to explain the problem well enough
+for admins to recover.
+
+A possible risk are cluster upgrades, this is the first time this enhancement
+will be for multi-node clusters, we need to run more tests on upgrade cycles to
+make sure things run as expected.
+
 ### Drawbacks
 
 This feature contains the same drawbacks as the [Management Workload