<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 17, 2014 at 9:32 PM, Zhangleiqiang (Trump) <span dir="ltr"><<a href="mailto:zhangleiqiang@huawei.com" target="_blank">zhangleiqiang@huawei.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> From: Vishvananda Ishaya [mailto:<a href="mailto:vishvananda@gmail.com">vishvananda@gmail.com</a>]<br>
> Sent: Tuesday, March 18, 2014 2:28 AM<br>
<div class="">> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [nova][cinder] non-persistent storage(after<br>
> stopping VM, data will be rollback automatically), do you think we shoud<br>
> introduce this feature?<br>
><br>
><br>
</div><div><div class="h5">> On Mar 17, 2014, at 4:34 AM, Yuzhou (C) <<a href="mailto:vitas.yuzhou@huawei.com">vitas.yuzhou@huawei.com</a>> wrote:<br>
><br>
> > Hi Duncan Thomas,<br>
> ><br>
> > Maybe the statement about approval process is not very exact. In fact in<br>
> my mail, I mean:<br>
> > In the enterprise private cloud, if beyond the quota, you want to create a new<br>
> VM ,that needs to wait for approval process.<br>
> ><br>
> ><br>
> > @stackers,<br>
> ><br>
> > I think the following two use cases show why non-persistent disk is useful:<br>
> ><br>
> > 1.Non-persistent VDI:<br>
> > When users access a non-persistent desktop, none of their settings or<br>
> data is saved once they log out. At the end of a session,<br>
> > the desktop reverts back to its original state and the user receives a fresh<br>
> image the next time he logs in.<br>
> > 1). Image manageability, Since non-persistent desktops are built from a<br>
> master image, it's easier for administrators to patch and update the image,<br>
> back it up quickly and deploy company-wide applications to all end users.<br>
> > 2). Greater security, Users can't alter desktop settings or install their own<br>
> applications, making the image more secure.<br>
> > 3). Less storage.<br>
> ><br>
> > 2.As the use case mentioned several days ago by zhangleiqiang:<br>
> ><br>
> > "Let's take a virtual machine which hosts a web service, but it is primarily<br>
> a read-only web site with content that rarely changes. This VM has three disks.<br>
> Disk 1 contains the Guest OS and web application (e.g. Apache). Disk 2<br>
> contains the web pages for the web site. Disk 3 contains all the logging activity.<br>
> > In this case, disk 1 (OS & app) are dependent (default) settings and<br>
> is backed up nightly. Disk 2 is independent non-persistent (not backed up, and<br>
> any changes to these pages will be discarded). Disk 3 is independent<br>
> persistent (not backed up, but any changes are persisted to the disk).<br>
> > If updates are needed to the web site's pages, disk 2 must be<br>
> taken out of independent non-persistent mode temporarily to allow the<br>
> changes to be made.<br>
> > Now let's say that this site gets hacked, and the pages are<br>
> doctored with something which is not very nice. A simple reboot of this host will<br>
> discard the changes made to the web pages on disk 2, but will persist the<br>
> logs on disk 3 so that a root cause analysis can be carried out."<br>
> ><br>
> > Hope to get more suggestions about non-persistent disk!<br>
><br>
><br>
> Making the disk rollback on reboot seems like an unexpected side-effect we<br>
> should avoid. Rolling back the system to a known state is a useful feature, but<br>
> this should be an explicit api command, not a side-effect of rebooting the<br>
> machine, IMHO.<br>
<br>
</div></div>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.<br>
</blockquote><div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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:<br>
1. For cinder volume, create a snapshot; For libvirt ephemeral image backend, create new image<br>
2.Update attached volume info for instance<br>
3.Delete the cinder snapshot and libvirt ephemeral image, and update volume/image info for instance again<br>
<br>
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?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> Vish<br>
><br>
> ><br>
> > Thanks.<br>
> ><br>
> > Zhou Yu<br>
> ><br>
> ><br>
> ><br>
> ><br>
> >> -----Original Message-----<br>
> >> From: Duncan Thomas [mailto:<a href="mailto:duncan.thomas@gmail.com">duncan.thomas@gmail.com</a>]<br>
> >> Sent: Saturday, March 15, 2014 12:56 AM<br>
> >> To: OpenStack Development Mailing List (not for usage questions)<br>
> >> Subject: Re: [openstack-dev] [nova][cinder] non-persistent<br>
> >> storage(after stopping VM, data will be rollback automatically), do<br>
> >> you think we shoud introduce this feature?<br>
> >><br>
> >> On 7 March 2014 08:17, Yuzhou (C) <<a href="mailto:vitas.yuzhou@huawei.com">vitas.yuzhou@huawei.com</a>> wrote:<br>
> >>> First, generally, in public or private cloud, the end users<br>
> >>> of VMs<br>
> >> have no right to create new VMs directly.<br>
> >>> If someone want to create new VMs, he or she need to wait for<br>
> >>> approval<br>
> >> process.<br>
> >>> Then, the administrator Of cloud create a new VM to applicant. So<br>
> >>> the<br>
> >> workflow that you suggested is not convenient.<br>
> >><br>
> >> This approval process & admin action is the exact opposite to what<br>
> >> cloud is all about. I'd suggest that anybody using such a process has<br>
> >> little understanding of cloud and should be educated, not weird<br>
> >> interfaces added to nova to support a broken premise. The cloud /is<br>
> >> different/ from traditional IT, that is its strength, and we should<br>
> >> be wary of undermining that to allow old-style thinking to continue.<br>
> >><br>
> >> _______________________________________________<br>
> >> OpenStack-dev mailing list<br>
> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>