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

Bug 1237337

Summary:	RFE: minimum sized volume should be default when launching a VM
Product:	Red Hat OpenStack	Reporter:	Dan Yocum <dyocum>
Component:	python-novaclient	Assignee:	Eoghan Glynn <eglynn>
Status:	CLOSED WONTFIX	QA Contact:	nlevinki <nlevinki>
Severity:	low	Docs Contact:
Priority:	low
Version:	5.0 (RHEL 6)	CC:	berrange, bhoefer, dasmith, eglynn, jruzicka, kchamart, sbauza, sferdjao, sgordon, srevivo, vromanso
Target Milestone:	---	Keywords:	FutureFeature, Triaged
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:
Clones:	1303124 (view as bug list)		Environment:
Last Closed:	2017-01-26 21:42:50 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:
Bug Depends On:
Bug Blocks:	1303124

Description Dan Yocum 2015-06-30 20:33:31 UTC

Description of problem:

When attempting to launch a VM that requires a minimum sized volume, any flavor less than that should not be an option.

Also, when attempting to launch a VM that requires a minimum sized volume using a cinder volume, the correct minimum cinder volume size should be defaulted to if 

a) no volume size is given or 
b) a volume size is created that is too small to hold the VM image.  

Or, an appropriate error should be issued instead of  "[Errno 28] No space left on device."

For instance, if a qemu or raw image requires 10GB for the root volume, then any flavor that is less than 10GB should not be available in horizon OR accepted on the command line - a suitable error should be issued.

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

Currently observing errors in RHEL-OSP 5 on RHEL 6.

Comment 5 Bernie Hoefer 2015-10-07 01:02:20 UTC

May I please get the status of this ticket, please, for a customer conference call?  It hasn't been updated in over 3 months.  It hasn't been prioritized, yet ROSP8 development is going on right now -- so I would have thought at least that would have happened.  Thanks!

Comment 6 Stephen Gordon 2016-01-29 15:50:11 UTC

(In reply to Bernie Hoefer from comment #5)
> May I please get the status of this ticket, please, for a customer
> conference call?  It hasn't been updated in over 3 months.  It hasn't been
> prioritized, yet ROSP8 development is going on right now -- so I would have
> thought at least that would have happened.  Thanks!

To my knowledge we are not actively prioritizing this request at this time, getting to the requested state is not necessarily trivial and actually is not likely to be implemented in Nova itself at all (Nova already checks these things pretty early in the processing of the API request).

The logic requested would have to be implemented as additional client side calls, assuming we are exposing enough API detail (I believe we are). Moving to python-novaclient and cloning to horizon.

Comment 7 Bernie Hoefer 2016-01-29 15:57:54 UTC

Thanks for the information, Stephen!

Comment 8 Stephen Gordon 2016-06-09 18:52:29 UTC

Bulk update to reflect scope of Red Hat OpenStack Platform 9 and Red Hat OpenStack Platform does not include this issue (No pm_ack+).

Comment 10 Stephen Gordon 2017-01-26 21:42:50 UTC

(In reply to Stephen Gordon from comment #6)
> (In reply to Bernie Hoefer from comment #5)
> > May I please get the status of this ticket, please, for a customer
> > conference call?  It hasn't been updated in over 3 months.  It hasn't been
> > prioritized, yet ROSP8 development is going on right now -- so I would have
> > thought at least that would have happened.  Thanks!
> 
> To my knowledge we are not actively prioritizing this request at this time,
> getting to the requested state is not necessarily trivial and actually is
> not likely to be implemented in Nova itself at all (Nova already checks
> these things pretty early in the processing of the API request).
> 
> The logic requested would have to be implemented as additional client side
> calls, assuming we are exposing enough API detail (I believe we are). Moving
> to python-novaclient and cloning to horizon.

I'm closing this bug as I don't believe we are likely to implement such filtering in the nova client, the Horizon bug however remains open and there is a viable proposal for handling this there (not necessarily making the options disappear but at least graying them out).

Comment 11 Red Hat Bugzilla 2023-09-14 03:01:24 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days