Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1332482

Summary: It's better to notice user when requesting storage over the capacity limitation in OSO during PVC created
Product: OpenShift Container Platform Reporter: mdong
Component: StorageAssignee: Erin Boyd <eboyd>
Status: CLOSED ERRATA QA Contact: zhaliu
Severity: medium Docs Contact:
Priority: medium    
Version: 3.2.0CC: aos-bugs, bchilds, dakini, dmace, eparis, tdawson, wsun, xtian
Target Milestone: ---Keywords: NeedsTestCase
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-01-18 12:40:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description mdong 2016-05-03 10:12:28 UTC
Description of problem:
It's not user friendly that when requesting storage over the capacity limitation(1GB) in OSO during persistentvolumeclaim created, the user doesn't get any notification or warning message, only pvc status is pending.  

Version-Release number of selected component (if applicable):
dev-preview-int

How reproducible:
Always


Steps to Reproduce:
1. Create a project named "test"
2. Create pvc and check pvc status by following command:
[dongm@dhcp-136-41 tmp]$ cat 5.yaml 
apiVersion: "v1"
kind: "PersistentVolumeClaim"
metadata:
  name: "claim-over-limit"
spec:
  accessModes:
    - "ReadWriteOnce"
  resources:
    requests:
      storage: "1.1Gi"


[dongm@dhcp-136-41 tmp]$ oc create -f 5.yaml 
persistentvolumeclaim "claim-over-limit" created
[dongm@dhcp-136-41 tmp]$ oc get pvc
NAME               STATUS    VOLUME         CAPACITY   ACCESSMODES   AGE
claim-over-limit   Pending                                           5s
claim4             Bound     pv-aws-exfj7   500M       RWO           1m

[dongm@dhcp-136-41 tmp]$ oc describe pvc claim-over-limit
Name:		claim-over-limit
Namespace:	test
Status:		Pending
Volume:		
Labels:		<none>
Capacity:	
Access Modes:

Actual results:
persistentvolumeclaim created successfully, but the status is pending

Expected results:
the user is better to get any notification or warning message when requesting storage over the capacity limitation(1GB).

Additional info:

Comment 2 Mark Turansky 2016-05-25 12:33:06 UTC
This is, essentially, an RFE as there is no means today to communicate *why* a PVC might be pending.  There are also many possible reasons why a PVC remains Pending, from mismatched access modes to exceeded capacity to simply no PVs to bind to.

I believe this is a UX issue for the storage team. Assigning to Erin Boyd.

Comment 3 Dan Mace 2016-05-25 12:58:06 UTC
This seems like it's best resolved by integrating the Kube dynamic provisioner with quota.

Comment 4 Bradley Childs 2016-08-08 20:34:06 UTC
https://github.com/kubernetes/kubernetes/pull/30145

Comment 7 Erin Boyd 2016-10-26 19:49:42 UTC
This fix should be in this merge that happened 14 days ago:
https://github.com/kubernetes/kubernetes/pull/30145

please retest

Comment 8 Troy Dawson 2016-10-28 19:50:23 UTC
This has been merged into ose and is in OSE v3.4.0.17 or newer.

Comment 10 zhaliu 2016-11-10 05:40:00 UTC
This bug can't be verified now,because the limitrange feature is not available in INT.
https://bugzilla.redhat.com/show_bug.cgi?id=1391842

There has been a test case covered this bug.

Comment 12 zhaliu 2016-11-14 02:58:28 UTC
Verified in OCP 3.4, it works well.When creating a pvc over the limit,I find it can't be created and there is a correct prompt.

Comment 14 errata-xmlrpc 2017-01-18 12:40:44 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:0066