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