<p>Interesting.</p>
<p>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.</p>
<p>That sounds cool.</p>
<p>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?</p>

<p>Given the above simplifications, and ignoring the 0GB needing a cap, what about a "no-disk-expand" image flag?</p>
<p>So don't have a big issue with the proposal, I just wonder if the above meets your needs and makes it simpler?</p>
<p>John </p>
<div class="gmail_quote">On Jun 3, 2013 5:56 PM, "Day, Phil" <<a href="mailto:philip.day@hp.com">philip.day@hp.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">






<div lang="EN-GB" link="blue" vlink="purple">
<div>
<p class="MsoNormal">Hi Folks,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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).   
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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
<a href="https://blueprints.launchpad.net/nova/+spec/variable-size-root-disk" target="_blank">https://blueprints.launchpad.net/nova/+spec/variable-size-root-disk</a>  which in turn points to a full description here in the Wiki:
<a href="https://wiki.openstack.org/wiki/VariableSizeRootDisk" target="_blank">https://wiki.openstack.org/wiki/VariableSizeRootDisk</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">We’ve also posted draft code that shows how this could be implemented here: 
<a href="https://review.openstack.org/#/c/31521/" target="_blank">https://review.openstack.org/#/c/31521/</a>  
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Cheers,<u></u><u></u></p>
<p class="MsoNormal">Phil<u></u><u></u></p>
</div>
</div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>