Open Stack

Currently, a flavor with its root_gb is 0 should be only used for volume 
booted or for testing purposes:
https://github.com/openstack/nova/blob/master/api-ref/source/parameters.yaml#L1782~L1787


I have a use case:
Users may create some virtual machines for the processing of their 
business, these virtual machines use customized images which can meet 
their requirement. When users create virtual machines using these 
customized images in batches, they don't need to know the size of 
instance's root_gb, so they can use flavor with its disk size as 0.
In this case, the value of root_gb's filed in db table of instances is 0 
for every virtual machine, but it's real value is not 0. This will lead to 
live migrate failure since live-migration's destination compute node's 
disk_available_least is always less than 0.
We often enable disk_filter to control compute nodes's disk space, but 
when the value of root_gb's filed in db table of instances is 0, this 
filter does not work.


For this case, I think testing purposes for a flavor with its root_gb is 0 
would mislead users. User probably didn't notice this tips and they found 
instance with flavor's root_gb is 0 could be booted successfully. Many 
problems occur after cloud environment running for many a period, but its 
too late for rebuild this cloud environment. I think it's dangerous.


I have two optional solution.

1. First option:
When an instances booted from image and  its flavor's root_gb is 0, this 
instance boot failed.

2. Second option:
When an instances booted from image and  its flavor's root_gb is 0, the 
value of root_gb's filed in db table of instances should be equal to 
image's virtual size, min_size or size which is max.


I submitted a bug for this question: 
https://bugs.launchpad.net/nova/+bug/1414947
I submitted second optional solution code: 
https://review.openstack.org/398891 
Balazs Gibizer (balazs-gibizer) wrote a a clarification to the doc about 
disks == 0 case: https://review.openstack.org/#/c/339034/ 

I need you advice, thank you very much.

Best,

Charlotte Han
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161118/395bdec6/attachment.html>