Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1357796 - Should prompt forbidden info when customer try to scale up a pod with block device volume
Summary: Should prompt forbidden info when customer try to scale up a pod with block d...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Pod
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Paul Morie
QA Contact: DeShuai Ma
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-19 08:11 UTC by XiuJuan Wang
Modified: 2016-10-31 14:42 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-31 14:42:14 UTC


Attachments (Terms of Use)

Description XiuJuan Wang 2016-07-19 08:11:25 UTC
Description of problem:
Should prompt forbidden info when customer try to scale up a pod with block device volume in cli or webconsole, for example: a pod with ebs persistent volume can only have its replication controller set to 0 or 1.
Now show scaling up a pod with block device volume successfully, but the new pod will fail to bound pv actually.

Version-Release number of selected component (if applicable):
oc v3.3.0.6
kubernetes v1.3.0+57fb9ac

How reproducible:
always

Steps to Reproduce:
1.Create a pv pod and bound to a block device volume
oc new-app jenkins-persistent
2.Scale up jenkins pod to 2
oc scale rc jenkins-1 --replicas=2
3.

Actual results:
# oc scale rc jenkins-1 --replicas=2 
replicationcontroller "jenkins-1" scaled


Expected results:
Should prompt forbidden info

Additional info:

Comment 1 Andy Goldstein 2016-08-09 16:25:15 UTC
Some notes from my discussion about this with Clayton:

- We are not going to prevent this from happening in the api
- There are some reasons why it's valid to have the number of replicas set to 2 (Clayton can provide more detail)
- We don't know that volumes are block devices necessarily
- We could possibly look at the RWOnce/RWMany value on the PersistentVolume, but there's no guarantee it's correct
- There's not an easy way to address this in `oc scale` today
- We probably should find a way to make `oc status` communicate this information better.

Comment 2 Derek Carr 2016-10-31 14:42:14 UTC
I am closing this as not a bug.  We should look to create a RFE to communicate a more precise error message in oc status for this use case.


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