Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130604/42c445f6/attachment.html>