Bug 1273203 - Limit range does allow defaultRequest > max when it should flag it as error
Summary: Limit range does allow defaultRequest > max when it should flag it as error
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Derek Carr
QA Contact: Wei Sun
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-19 22:52 UTC by Peter Ruan
Modified: 2015-11-23 14:24 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-23 14:24:38 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Peter Ruan 2015-10-19 22:52:59 UTC
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 17:03:16 UTC
$ 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 05:43:28 UTC
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 14:24:38 UTC
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.