Feature Overview (aka. Goal Summary)  

An elevator pitch (value statement) that describes the Feature in a clear, concise way.  Complete during New status.

Workload partitioning currently does not support mutating containers that have cpu limits.  That  can cause platform/control plane components  use the wrong core budget (application instead of platform). 

Goals (aka. expected user outcomes)

Apply the workload paritioning also for containers that have cpu limits.

Requirements (aka. Acceptance Criteria):

1) Add another annotation to the crio drop in to represent the limit, "cpuquota"

[crio.runtime.workloads.management]
activation_annotation = "target.workload.openshift.io/management"
annotation_prefix = "resources.workload.openshift.io"
resources = { "cpushares" = 0,  "cpuquota"=0, "cpuset" = "0-1,52-53" }

2) Modify the admission plugin to take cpu limits and add a cpuquota annotation. The cpu limits would be stripped. A new annotation or extend the existing one i.e.

annotations:

    resources.workload.openshift.io/foo: {"cpushares": 20, "cpuquota": 50}

3) Modify crio to set cfs.quota for the contatiner to the value of cpuquota

Questions to Answer (Optional):

1. Any consideration needed for upgrades from previous versions?

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

n/a

Background

The original premise was that all ocp pods did not set limits, however it has been found that at least one klusteret containers does set limits. This will be worked around in 4.8 but in 4.9 a proper solution is required to deal with these exceptions. In addition, the desire in the future is to support different workload types which would require limit support. 

Customer Considerations

Requested by telco customers

Documentation Considerations

No docs changed expected

Interoperability Considerations

No impact on other projects expected