Open Stack

Hi John,

> So you don't resize the root disk, just leave it the size from glance, like gb=0, but you want an upper bound on its size, for snapshots, 
>comming from flavour size.
>
>That sounds cool.

Yep, that's basically it.  We want the image owner (via image metadata) and the cloud provider (via the flavor) to both be able to provide their view on how big the root disc should be.  The cloud provider defines the max size, the image owner the min size.

> The bit about increasing the size of the ephemeral disk to provide the max space for the flavour seems a bit overly complex. 
> Would it be OK to keep the ephemeral a fixed size. So advertise to the user free disk space on first boot, not total size of disk?
>
>Given the above simplifications, and ignoring the 0GB needing a cap, what about a "no-disk-expand" image flag?

I guess it depends on your users - in our case my worry is that if people realised they were losing some of the disc capacity they were paying for there would be no incentive to every make the value in the image less that the root_gb of the flavor.   The code isn't all that complex, and it's all there in the draft change we posted for review.

The root_gb=0 option still gives cloud providers that want to offer a fixed size ephemeral disk if they want to.

>So don't have a big issue with the proposal, I just wonder if the above meets your needs and makes it simpler?
>John

Appreciate it - looking forward to your support in the review ;-)

Cheers
Phil


From: John Garbutt [mailto:john at johngarbutt.com] 
Sent: 04 June 2013 12:48
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Feedback wanted please on proposal to make root disk size variable

Interesting.
So you don't resize the root disk, just leave it the size from glance, like gb=0, but you want an upper bound on its size, for snapshots, comming from flavour size.
That sounds cool.
The bit about increasing the size of the ephemeral disk to provide the max space for the flavour seems a bit overly complex. Would it be OK to keep the ephemeral a fixed size. So advertise to the user free disk space on first boot, not total size of disk?

Given the above simplifications, and ignoring the 0GB needing a cap, what about a "no-disk-expand" image flag?
So don't have a big issue with the proposal, I just wonder if the above meets your needs and makes it simpler?
John 
On Jun 3, 2013 5:56 PM, "Day, Phil" <philip.day at hp.com> wrote:
Hi Folks,
 
I'd like to get your feedback on a change we've been looking at which would allow the root disc size to vary within the constraints specified by the image Creator (via image metadata ) and the Cloud Provider (via flavors).    
 
The problem we're trying to solve is to cope with a range of images that have different root disc requirements without having to either create specific flavours for each image type of have all instances use a large root size when they don't need to.    Imagine for example trying to have a common set of flavours for Linux and Windows without forcing all Linux instances to have a 30GB root disc.
 
We think we have an approach which will do this without preventing anyone's existing use cases.  The proposal is capture here as a blueprint https://blueprints.launchpad.net/nova/+spec/variable-size-root-disk  which in turn points to a full description here in the Wiki: https://wiki.openstack.org/wiki/VariableSizeRootDisk
 
We've also posted draft code that shows how this could be implemented here:  https://review.openstack.org/#/c/31521/   
 
We're aware that there is still work to do on this around unit tests, but wanted to get some early feedback on the approach.
 
Cheers,
Phil

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev