On Mar 17, 2014, at 4:34 AM, Yuzhou (C) <vitas.yuz...@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.

Vish

> 
> Thanks.
> 
> Zhou Yu
> 
> 
> 
> 
>> -----Original Message-----
>> From: Duncan Thomas [mailto:duncan.tho...@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.yuz...@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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to