Bug 1356682 - [API] API deployments allow 0 value for openshift_storage_size
Summary: [API] API deployments allow 0 value for openshift_storage_size
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Quickstart Cloud Installer
Classification: Red Hat
Component: fusor-server
Version: 1.0
Hardware: All
OS: All
high
high
Target Milestone: ga
: 1.0
Assignee: dgao
QA Contact: Landon LaSmith
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-14 17:17 UTC by Landon LaSmith
Modified: 2016-09-13 16:31 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-13 16:31:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1366748 0 unspecified NEW [RFE] [API] API deployments allow setting openshift_storage_size to invalid value 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHEA-2016:1862 0 normal SHIPPED_LIVE Red Hat Quickstart Installer 1.0 2016-09-13 20:18:48 UTC

Internal Links: 1366748

Description Landon LaSmith 2016-07-14 17:17:55 UTC
Description of problem: Deploying QCI via the fusor api will allow a deployment to proceed with a default value of 0 for openshift_storage_size in the deployment object.

ISO Media Version: QCI-1.2-RHEL-7-20160711.t.1

How reproducible: 100%


Steps to Reproduce:
1. Create a RHEV deployment using the fusor API
2. Don't include a value for
PUT /fusor/api/v21/deployments/<deployment id -d

  {'deployment': {
       'openshift_storage_size': 0}

3. Validate deployment - GET /fusor/api/v21/deployments/<deployment id>/validate
4. Start deployment using the fusor API

Actual results: Deployment starts normally and failing during setup of OpenShift. setup.yaml fails during 'lsblk /dev/vdb'


Expected results: Deployment validation should return an error with 'openshift_storage_size should be greater than 0'

Additional info: Default value for openshift_storage_size should be minimum recommended size for a QCI OpenShift deployment

Comment 9 John Matthews 2016-07-25 12:42:19 UTC
QCI-1.0-RHEL-7-20160723.t.0-QCI-x86_64-dvd1.iso

Comment 10 John Matthews 2016-07-25 13:15:10 UTC
Moving to MODIFIED, PR isnt merged/built yet

Comment 11 John Matthews 2016-08-02 18:42:36 UTC
QCI-1.0-RHEL-7-20160801.t.2-QCI-x86_64-dvd1.iso

Comment 12 Landon LaSmith 2016-08-11 22:17:51 UTC
Moving back to assigned since it will properly fail deployment validation but specifying 0 for openshift_storage_size via the api call will still still return 200 code even when it doesn't pass validation

QCI Iso media version: QCI-1.0-RHEL-7-20160809.t.1

Comment 13 John Matthews 2016-08-12 16:20:50 UTC
Landon,

Please treat this BZ as only for the validation check, i.e. when we do a check if the deployment is valid we get a response indicating issues.

Additionally, please file a new BZ for the suggestion you have of not allowing a bad value in the deployment when it's created.  This is a potential RFE for post-GA.

The reason we are not addressing the specific request you have in comment #12 for GA is that the workflow allows partial updates of the deployment object over multiple calls. As in, we expect the deployment object to built up as a user progresses through the wizard, many of the values will be zero/empty as the data is being built up, so we delay validation until the very end.

Post-GA we can re-examine this workflow.

Comment 14 Landon LaSmith 2016-08-12 17:07:30 UTC
John,

Created RFE in response to comment #13 and marking as VERIFIED since it's no long possible to proceed with a deployment when the value is 0.

Comment 16 errata-xmlrpc 2016-09-13 16:31:48 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/RHEA-2016:1862


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