Open Stack

On Mon, Mar 17, 2014 at 9:32 PM, Zhangleiqiang (Trump) <
zhangleiqiang at huawei.com> wrote:

> > From: Vishvananda Ishaya [mailto:vishvananda at gmail.com]
> > Sent: Tuesday, March 18, 2014 2:28 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [nova][cinder] non-persistent storage(after
> > stopping VM, data will be rollback automatically), do you think we shoud
> > introduce this feature?
> >
> >
> > On Mar 17, 2014, at 4:34 AM, Yuzhou (C) <vitas.yuzhou at huawei.com> wrote:
> >
> > > Hi Duncan Thomas,
> > >
> > >     Maybe the statement about approval process is not very exact. In
> fact in
> > my mail, I mean:
> > > In the enterprise private cloud, if beyond the quota, you want to
> create a new
> > VM ,that needs to wait for approval process.
> > >
> > >
> > > @stackers,
> > >
> > > I think the following two use cases show why non-persistent disk is
> useful:
> > >
> > > 1.Non-persistent VDI:
> > >     When users access a non-persistent desktop, none of their settings
> or
> > data is saved once they log out. At the end of a session,
> > >     the desktop reverts back to its original state and the user
> receives a fresh
> > image the next time he logs in.
> > >     1). Image manageability, Since non-persistent desktops are built
> from a
> > master image, it's easier for administrators to patch and update the
> image,
> > back it up quickly and deploy company-wide applications to all end users.
> > >     2). Greater security, Users can't alter desktop settings or
> install their own
> > applications, making the image more secure.
> > >     3). Less storage.
> > >
> > > 2.As the use case mentioned several days ago by zhangleiqiang:
> > >
> > >     "Let's take a virtual machine which hosts a web service, but it is
> primarily
> > a read-only web site with content that rarely changes. This VM has three
> disks.
> > Disk 1 contains the Guest OS and web application (e.g.        Apache).
> Disk 2
> > contains the web pages for the web site. Disk 3 contains all the logging
> activity.
> > >         In this case, disk 1 (OS & app) are dependent (default)
> settings and
> > is backed up nightly. Disk 2 is independent non-persistent (not backed
> up, and
> > any changes to these pages will be discarded). Disk 3 is      independent
> > persistent (not backed up, but any changes are persisted to the disk).
> > >         If updates are needed to the web site's pages, disk 2 must be
> > taken out of independent non-persistent mode temporarily to allow the
> > changes to be made.
> > >         Now let's say that this site gets hacked, and the pages are
> > doctored with something which is not very nice. A simple reboot of this
> host will
> > discard the changes made to the web pages on disk 2, but will persist
>       the
> > logs on disk 3 so that a root cause analysis can be carried out."
> > >
> > > Hope to get more suggestions about non-persistent disk!
> >
> >
> > Making the disk rollback on reboot seems like an unexpected side-effect
> we
> > should avoid. Rolling back the system to a known state is a useful
> feature, but
> > this should be an explicit api command, not a side-effect of rebooting
> the
> > machine, IMHO.
>
> I think there is some misunderstanding about non-persistent disk, the
> non-persistent disk will only rollback if the instance is shutdown and
> start again, and will persistent the data if it is soft-reboot.
>

I think your intent is understood here, however I think I have to agree
with others that it's a use case that really is already provided for and in
fact is pretty much the nature of an elastic cloud to begin with.

I also want to highlight the comment by Vish about the confusion and
unhappy users we'll have if we suddenly change the behavior of reboot.
 Certainly this could be an option but IMHO just because you *can* create
an option in an API doesn't always mean that you should.

I feel that we provide the necessary steps to do what you're asking here
already, and if a provider does in fact restrict things like creating
instances, then just as others said this is sort of against the whole point
of having the cloud in the first place.  This might be a great thing for
them to implement as their own custom extension, but it doesn't seem to fit
with the existing core project IMO.


> Non-persistent disk does have use cases. Using explicit API command can
> achieve it, but I think there will be some work need to be done before
> booting the instance or after shutdown the instance, including:
> 1. For cinder volume, create a snapshot; For libvirt ephemeral image
> backend, create new image
> 2.Update attached volume info for instance
> 3.Delete the cinder snapshot and libvirt ephemeral image, and update
> volume/image info for instance again
>
> These works can be done by users manually or by some "Upper system" ? Or
> non-persistent can be set as a metadata/property of volume/image, and
> handled by Nova?
>
>
>
> > Vish
> >
> > >
> > > Thanks.
> > >
> > > Zhou Yu
> > >
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Duncan Thomas [mailto:duncan.thomas at gmail.com]
> > >> Sent: Saturday, March 15, 2014 12:56 AM
> > >> To: OpenStack Development Mailing List (not for usage questions)
> > >> Subject: Re: [openstack-dev] [nova][cinder] non-persistent
> > >> storage(after stopping VM, data will be rollback automatically), do
> > >> you think we shoud introduce this feature?
> > >>
> > >> On 7 March 2014 08:17, Yuzhou (C) <vitas.yuzhou at huawei.com> wrote:
> > >>>        First, generally, in public or private cloud, the end users
> > >>> of VMs
> > >> have no right to create new VMs directly.
> > >>> If someone want to create new VMs, he or she need to wait for
> > >>> approval
> > >> process.
> > >>> Then, the administrator Of cloud create a new VM to applicant. So
> > >>> the
> > >> workflow that you suggested is not convenient.
> > >>
> > >> This approval process & admin action is the exact opposite to what
> > >> cloud is all about. I'd suggest that anybody using such a process has
> > >> little understanding of cloud and should be educated, not weird
> > >> interfaces added to nova to support a broken premise. The cloud /is
> > >> different/ from traditional IT, that is its strength, and we should
> > >> be wary of undermining that to allow old-style thinking to continue.
> > >>
> > >> _______________________________________________
> > >> OpenStack-dev mailing list
> > >> OpenStack-dev at lists.openstack.org
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> 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/20140321/9aeb7aba/attachment.html>