Open Stack

On Fri, Sep 2, 2011 at 8:01 AM, Soren Hansen <soren at linux2go.dk> wrote:

> 2011/9/2 Paul Voccio <openstack at substation9.com>:
> > Vish,
> > We've talked about this idea in the past and I agree this works for *nix
> > hosts, but a base install of Windows 2k8R2 with CloudServers is 10.7GB.
>
> Yikes.
>

Tell me about it.


>
> > If we went with a 10gb base disk solution this obviously won't work.
> > Even if we went with a 20gb partition it could become a problem as
> > users install programs to C: and then try to do system updates that
> > expect to have some reasonable disk available on C:. Providing a clean
> > install with < 10gb usable doesn't feel like a good customer
> > experience.
>
> What we do now is grow the image if it's smaller than size X. If it's
> already of size X or larger, we leave it alone.
>
> I guess we should add a check to verify that the image isn't larger than
> the disk size granted to the requested flavour so that people can't
> abuse this.
>
> > We have some users that wish to format their disk with other
> > filesystems for performance reasons or encrypt them for security
> > reasons. Both of these are completely valid. However, this poses a
> > problem if we were to try to resize these partitions for them. Easy
> > solution is don't touch the partitions and let them do it themselves.
> > I think this type of solution works well for power users and
> > developers. This does pose a problem for less technical users who
> > would resize a disk and then wonder why they don't see the extra space
> > as expected. This would create extra support costs that not all
> > providers are willing to shoulder.
>
> I think this is the difference between "a cloud" and a "VPS with an API"
> making its appearance.
>

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.



> I'm all for building something on top of which someone can provide a
> VPS, but that's not the core of what Nova is. It's meant to be "a
> cloud".  It's a piece of infrastructure on top of which amazing,
> scalable technology can be built. If we document "this is how this thing
> behaves.  Deal with it" that should be fine. I'd be really sad if we
> weren't able to make the best choice because the best choice might
> surprise less technical users using it as a VPS and who haven't read the
> documentation.
>

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.

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).




>
> If a deployer of OpenStack thinks this demographic is particularly
> appealing, they can extend the images they offer to notify users about
> these things or perhaps even take action on their part. E.g.:
>
>  * E-mail the user telling them this is what they need to do
>  * Show a pop-up on login telling them there's unpartitioned space.
>   "Click here to extend C: to use this space" or "Click here to
>   fire up 'Microsoft Genuine Partitioning Tool 2008 XP'".
>  * "We've detected you've grown your Cloud Server. C: has been extended
>   to use this new space. Have a nice day."
>
>
Option #3 above is exactly what I'm describing.


> I don't believe this should be a core concern for Nova. Do you think we
> can get that separation of concern to work out for everyone?
>
> > To address this, we designed what we felt was a compromise and let the
> users
> > decide what they feel is the best solution. It would be an extension that
> > would let users define what kind of disk management they wish to use,
> > 'manual' or 'auto'. Manual would be the hands off approach that would
> tell
> > the system to expand the disk, but not touch the partition.
> > Auto would expand the disk along with the partition. The caveat with the
> > auto expand would be the filesystem would have to be in a format that the
> > host understood.
>
> The potential for filesystem bugs that could bring the host down gives
> me the heebie jeebies. I really, really don't want to mount people's
> filesystems.
>
>
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.


pvo


 --
> Soren Hansen        | http://linux2go.dk/
> Ubuntu Developer    | http://www.ubuntu.com/
> OpenStack Developer | http://www.openstack.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110902/9a33722e/attachment.html>