1. Proposed title of this feature request

SWIFT, an ESS Customer, has observed that when QoS: Burstable is used below dynamic tolerations are injected by OCP on the pod spec level:

  tolerations:
  - effect: NoExecute
   key: node.kubernetes.io/not-ready 
   operator: Exists
   tolerationSeconds: 300
  - effect: NoExecute
   key: node.kubernetes.io/unreachable  
   operator: Exists
   tolerationSeconds: 300
  - effect: NoSchedule
   key: node.kubernetes.io/memory-pressure 
   operator: Exists 

2. What is the nature and description of the request?

• Customer requests enhancements to the OpenShift Product that will make this behavior optional or that this would be disabled by default.  
• Behavior is documented here https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ and applicable for 4.11/4.14/4.18 (those are versions currently used in Customer)
• Another reason is that on a really busy cluster scheduler would sometimes opt to place pods on NotReady nodes and then try to evict it after 5 minutes, which was experienced by the Customer in version 4.18. 
• Customer developers would like to have the ability to keep explicit control of the pod .spec.template.tolerations, and any arbitrary mutation from Kubernetes is not welcome here. 

3. Why does the customer need this? (List the business requirements here)

• Customer developers are not happy that they cannot fully control declaratively pod specs, which causes degradation of trust in the OpenShift platform.

4. List any affected packages or components.

• OpenShift Scheduler