Bug 1273203 - Limit range does allow defaultRequest > max when it should flag it as error
Limit range does allow defaultRequest > max when it should flag it as error
Status: CLOSED CURRENTRELEASE
Product: OpenShift Container Platform
Classification: Red Hat
Component: Command Line Interface (Show other bugs)
3.1.0
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Derek Carr
Wei Sun
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-19 18:52 EDT by Peter Ruan
Modified: 2015-11-23 09:24 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-23 09:24:38 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Ruan 2015-10-19 18:52:59 EDT
Description of problem:

Limit range does allow defaultRequest > max when it should flag it as error
Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1. Login and create a project.

$ oc login -u user1

$ oc new-project proj1

$ oadm policy add-role-to-user cluster-admin  user1  -n  proj1

2. Set limit for pod/container with defaultRequest > max
 $ oc create -f limit.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: limits
  namespace: proj1
spec:
  limits:
  - type: Container
    max:
      cpu: 200m
      memory: 1Gi
    defaultRequest:
      cpu: 400m
      memory: 2Gi

Actual results:
limit range created

Expected results:

The LimitRange "limits" is invalid.

* spec.limits[0].defaultRequest[cpu]: invalid value '400m', Details: default request value 400m is greater than max value 200m
* spec.limits[0].defaultRequest[memory]: invalid value '2Gi', Details: default request value 2Gi is greater than max value 1Gi


Additional info:
Comment 3 Derek Carr 2015-10-20 13:03:16 EDT
$ git commit ac0b6e0ef316c3e2771297cba4f539e28d351463

$ cat limit.yaml 
apiVersion: v1
kind: LimitRange
metadata:
  name: limits
spec:
  limits:
  - type: Container
    max:
      cpu: 200m
      memory: 1Gi
    defaultRequest:
      cpu: 400m
      memory: 2Gi

_output/local/bin/linux/amd64/oc create -f limit.yaml 
The LimitRange "limits" is invalid.

* spec.limits[0].defaultRequest[cpu]: invalid value '400m', Details: default request value 400m is greater than max value 200m
* spec.limits[0].defaultRequest[cpu]: invalid value '400m', Details: default request value 400m is greater than default limit value 200m
* spec.limits[0].defaultRequest[memory]: invalid value '2Gi', Details: default request value 2Gi is greater than max value 1Gi
* spec.limits[0].defaultRequest[memory]: invalid value '2Gi', Details: default request value 2Gi is greater than default limit value 1Gi


The spec.limits[0].default values are populated based on the spec.limits[0].max values if not specified during the server-side defaulting pass.  As a result, the error message will report that the defaultRequest is greater than both the max and the default limit values.
Comment 4 Liang Xia 2015-10-21 01:43:28 EDT
Verified this has been fixed.

$ oc version
oc v3.0.2.901-61-g568adb6
kubernetes v1.1.0-alpha.1-653-g86b4e77


$ oc create -f limit.yaml 
The LimitRange "limits" is invalid.
* spec.limits[0].defaultRequest[memory]: invalid value '2Gi', Details: default request value 2Gi is greater than max value 1Gi
* spec.limits[0].default[memory]: invalid value '1Gi', Details: default value 2Gi is greater than max value 1Gi
* spec.limits[0].defaultRequest[cpu]: invalid value '400m', Details: default request value 400m is greater than max value 200m
* spec.limits[0].default[cpu]: invalid value '200m', Details: default value 400m is greater than max value 200m


$ cat limit.yaml 
apiVersion: v1
kind: LimitRange
metadata:
  name: limits
  namespace: proj1
spec:
  limits:
  - type: Container
    max:
      cpu: 200m
      memory: 1Gi
    default:
      cpu: 400m
      memory: 2Gi
Comment 5 Brenton Leanhardt 2015-11-23 09:24:38 EST
This fix is available in OpenShift Enterprise 3.1.

Note You need to log in before you can comment on or make changes to this bug.