<br><br><div class="gmail_quote">On Fri, Sep 2, 2011 at 8:01 AM, Soren Hansen <span dir="ltr"><<a href="mailto:soren@linux2go.dk" target="_blank">soren@linux2go.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2011/9/2 Paul Voccio <<a href="mailto:openstack@substation9.com" target="_blank">openstack@substation9.com</a>>:<br>
<div>> Vish,<br>
> We've talked about this idea in the past and I agree this works for *nix<br>
> hosts, but a base install of Windows 2k8R2 with CloudServers is 10.7GB.<br>
<br>
</div>Yikes.<br></blockquote><div><br></div><div>Tell me about it. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> If we went with a 10gb base disk solution this obviously won't work.<br>
> Even if we went with a 20gb partition it could become a problem as<br>
> users install programs to C: and then try to do system updates that<br>
> expect to have some reasonable disk available on C:. Providing a clean<br>
> install with < 10gb usable doesn't feel like a good customer<br>
> experience.<br>
<br>
</div>What we do now is grow the image if it's smaller than size X. If it's<br>
already of size X or larger, we leave it alone.<br>
<br>
I guess we should add a check to verify that the image isn't larger than<br>
the disk size granted to the requested flavour so that people can't<br>
abuse this.<br>
<div><br>
> We have some users that wish to format their disk with other<br>
> filesystems for performance reasons or encrypt them for security<br>
> reasons. Both of these are completely valid. However, this poses a<br>
> problem if we were to try to resize these partitions for them. Easy<br>
> solution is don't touch the partitions and let them do it themselves.<br>
> I think this type of solution works well for power users and<br>
> developers. This does pose a problem for less technical users who<br>
> would resize a disk and then wonder why they don't see the extra space<br>
> as expected. This would create extra support costs that not all<br>
> providers are willing to shoulder.<br>
<br>
</div>I think this is the difference between "a cloud" and a "VPS with an API"<br>
making its appearance.<br></blockquote><div><br></div><div>Soren, I agree with you that this is a subtle difference. The big think that I'm not sure we always consider is the support costs of using Nova. If the customers were responsible for expanding the disk there will always be some that are unable (or unwilling) to do this. If the software was able to do this you could reduce the staff needed to handle support. IMHO, this is what we're tasked to do, is automate those support features. </div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm all for building something on top of which someone can provide a<br>
VPS, but that's not the core of what Nova is. It's meant to be "a<br>
cloud". It's a piece of infrastructure on top of which amazing,<br>
scalable technology can be built. If we document "this is how this thing<br>
behaves. Deal with it" that should be fine. I'd be really sad if we<br>
weren't able to make the best choice because the best choice might<br>
surprise less technical users using it as a VPS and who haven't read the<br>
documentation.<br></blockquote><div><br></div><div>This is why I think we can give users the choice in how they want to manage this. You can currently use Nova to do both. You can use it entirely as a cloud as is and treat everything ephemeral (even if it isn't). I agree with you on this point and this is how I build my apps on virtualized infrastructure. </div>
<div><br></div><div>However, this is not what everyone actually does. Some people just a want a few developer machines to test with. If I'm working on a feature and I'm running out of memory on a test, I think you would agree it would be an interesting feature to increase the VM to a different size, run the test and confirm that it was a memory problem, then resize do a smaller instance once I was finished. I shouldn't have to copy all the data around to do this. You could accomplish this by taking a snapshot and launching a larger instance but I don't know if that will always be the case (I'm thinking of single use licensed softwares).</div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If a deployer of OpenStack thinks this demographic is particularly<br>
appealing, they can extend the images they offer to notify users about<br>
these things or perhaps even take action on their part. E.g.:<br>
<br>
* E-mail the user telling them this is what they need to do<br>
* Show a pop-up on login telling them there's unpartitioned space.<br>
"Click here to extend C: to use this space" or "Click here to<br>
fire up 'Microsoft Genuine Partitioning Tool 2008 XP'".<br>
* "We've detected you've grown your Cloud Server. C: has been extended<br>
to use this new space. Have a nice day."<br>
<br></blockquote><div><br></div><div>Option #3 above is exactly what I'm describing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't believe this should be a core concern for Nova. Do you think we<br>
can get that separation of concern to work out for everyone?<br>
<div><br>
> To address this, we designed what we felt was a compromise and let the users<br>
> decide what they feel is the best solution. It would be an extension that<br>
> would let users define what kind of disk management they wish to use,<br>
> 'manual' or 'auto'. Manual would be the hands off approach that would tell<br>
> the system to expand the disk, but not touch the partition.<br>
> Auto would expand the disk along with the partition. The caveat with the<br>
> auto expand would be the filesystem would have to be in a format that the<br>
> host understood.<br>
<br>
</div>The potential for filesystem bugs that could bring the host down gives<br>
me the heebie jeebies. I really, really don't want to mount people's<br>
filesystems.<br>
<div><div></div><div><br></div></div></blockquote><div><br></div><div>Can you explain a bit more here? I would like to understand your concerns. I would advocate mounting in a utility VM if you mean to protect from mounting instance with malicious data. We may have to do this to expand partitions or resize down for Windows. </div>
<div><br></div><div> </div><div>pvo</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
--<br>
Soren Hansen | <a href="http://linux2go.dk/" target="_blank">http://linux2go.dk/</a><br>
Ubuntu Developer | <a href="http://www.ubuntu.com/" target="_blank">http://www.ubuntu.com/</a><br>
OpenStack Developer | <a href="http://www.openstack.org/" target="_blank">http://www.openstack.org/</a><br>
</div></div></blockquote></div><br>