Thank you for reply, @Jay. +1 for There should not be any "magic" setting for root_gb that needs to be interpreted both by the user and the Nova code base.
I will try to restart the patch 136284 on the other way, like: instance object. Best Regards 2015-03-04 4:45 GMT+08:00 Jay Pipes <[email protected]>: > On 03/03/2015 01:10 AM, Rui Chen wrote: > >> Hi all, >> >> When we boot instance from volume, we find some ambiguous description >> about flavor root_gb in operations guide, >> http://docs.openstack.org/openstack-ops/content/flavors.html >> >> /Virtual root disk size in gigabytes. This is an ephemeral disk the base >> image is copied into. You don't use it when you boot from a persistent >> volume. / >> /The "0" size is a special case that uses the native base image size as >> the size of the ephemeral root volume./ >> / >> / >> 'You don't use it(root_gb) when you boot from a persistent volume.' >> It means that we need to set the root_gb to 0 or not? I don't know. >> > > Hi Rui, I agree the documentation -- and frankly, the code in Nova -- is > confusing around this area. > > But I find out that the root_gb will been added into local_gb_used of >> compute_node so that it will impact the next scheduling. Think about a >> use case, the local_gb of compute_node is 10, boot instance from volume >> with the root_gb=5 flavor, in this case, I can only boot 2 >> boot-from-volume instances on the compute_nodes, although these >> instances don't use the local disk of compute_nodes. >> >> I find a patch that try to fix this issue, >> https://review.openstack.org/#/c/136284/ >> >> I want to know that which solution is better for you? >> >> Solution #1: boot instance from volume with the root_gb=0 flavor. >> Solution #2: add some special logic in order to correct the disk usage, >> like patch #136284 >> > > Solution #2 is a better idea, IMO. There should not be any "magic" setting > for root_gb that needs to be interpreted both by the user and the Nova code > base. > > The issue with the 136284 patch is that it is trying to address the > problem in the wrong place, IMHO. > > Best, > -jay > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
