Open Stack

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 <jaypipes at gmail.com>:

> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150304/0689bab1/attachment.html>