<div dir="ltr"><div><div>Hi Joe,<br></div>If we assume the user is willing to create a new instance, the workflow you are saying is exactly correct. However, what I am assuming is that the user is NOT willing to create a new instance. If Nova can revert the existing instance, instead of creating a new one, it will become the alternative way utilized by those users who are not allowed to create a new instance.<br>
</div><div>Both paths lead to the target. I think we can not assume all the people should walk through path one and should not walk through path two. Maybe creating new instance or adjusting the quota is very easy in your point of view. However, the real use case is often limited by business process. So I think we may need to consider that some users can not or are not allowed to creating the new instance under specific circumstances.<br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 12:02 AM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Tue, Mar 4, 2014 at 6:21 PM, Qin Zhao <<a href="mailto:chaochin@gmail.com">chaochin@gmail.com</a>> wrote:<br>
> Hi Joe, my meaning is that cloud users may not hope to create new instances<br>
> or new images, because those actions may require additional approval and<br>
> additional charging. Or, due to instance/image quota limits, they can not do<br>
> that. Anyway, from user's perspective, saving and reverting the existing<br>
> instance will be preferred sometimes. Creating a new instance will be<br>
> another story.<br>
><br>
<br>
</div>Are you saying some users may not be able to create an instance at<br>
all? If so why not just control that via quotas.<br>
<br>
Assuming the user has the power to rights and quota to create one<br>
instance and one snapshot, your proposed idea is only slightly<br>
different then the current workflow.<br>
<br>
Currently one would:<br>
1) Create instance<br>
2) Snapshot instance<br>
3) Use instance / break instance<br>
4) delete instance<br>
5) boot new instance from snapshot<br>
6) goto step 3<br>
<br>
>From what I gather you are saying that instead of 4/5 you want the<br>
user to be able to just reboot the instance. I don't think such a<br>
subtle change in behavior is worth a whole new API extension.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Wed, Mar 5, 2014 at 3:20 AM, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>> wrote:<br>
>><br>
>> On Tue, Mar 4, 2014 at 1:06 AM, Qin Zhao <<a href="mailto:chaochin@gmail.com">chaochin@gmail.com</a>> wrote:<br>
>> > I think the current snapshot implementation can be a solution sometimes,<br>
>> > but<br>
>> > it is NOT exact same as user's expectation. For example, a new blueprint<br>
>> > is<br>
>> > created last week,<br>
>> > <a href="https://blueprints.launchpad.net/nova/+spec/driver-specific-snapshot" target="_blank">https://blueprints.launchpad.net/nova/+spec/driver-specific-snapshot</a>,<br>
>> > which<br>
>> > seems a little similar with this discussion. I feel the user is<br>
>> > requesting<br>
>> > Nova to create in-place snapshot (not a new image), in order to revert<br>
>> > the<br>
>> > instance to a certain state. This capability should be very useful when<br>
>> > testing new software or system settings. It seems a short-term temporary<br>
>> > snapshot associated with a running instance for Nova. Creating a new<br>
>> > instance is not that convenient, and may be not feasible for the user,<br>
>> > especially if he or she is using public cloud.<br>
>> ><br>
>><br>
>> Why isn't it easy to create a new instance from a snapshot?<br>
>><br>
>> ><br>
>> > On Tue, Mar 4, 2014 at 1:32 PM, Nandavar, Divakar Padiyar<br>
>> > <<a href="mailto:divakar.padiyar-nandavar@hp.com">divakar.padiyar-nandavar@hp.com</a>> wrote:<br>
>> >><br>
>> >> >>> Why reboot an instance? What is wrong with deleting it and create a<br>
>> >> >>> new one?<br>
>> >><br>
>> >> You generally use non-persistent disk mode when you are testing new<br>
>> >> software or experimenting with settings. If something goes wrong just<br>
>> >> reboot and you are back to clean state and start over again. I feel<br>
>> >> it's<br>
>> >> convenient to handle this with just a reboot rather than recreating the<br>
>> >> instance.<br>
>> >><br>
>> >> Thanks,<br>
>> >> Divakar<br>
>> >><br>
>> >> -----Original Message-----<br>
>> >> From: Joe Gordon [mailto:<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>]<br>
>> >> Sent: Tuesday, March 04, 2014 10:41 AM<br>
>> >> To: OpenStack Development Mailing List (not for usage questions)<br>
>> >> Subject: Re: [openstack-dev] [nova][cinder] non-persistent<br>
>> >> storage(after<br>
>> >> stopping VM, data will be rollback automatically), do you think we<br>
>> >> shoud<br>
>> >> introduce this feature?<br>
>> >> Importance: High<br>
>> >><br>
>> >> On Mon, Mar 3, 2014 at 8:13 PM, Zhangleiqiang<br>
>> >> <<a href="mailto:zhangleiqiang@huawei.com">zhangleiqiang@huawei.com</a>><br>
>> >> wrote:<br>
>> >> >><br>
>> >> >> This sounds like ephemeral storage plus snapshots. You build a base<br>
>> >> >> image, snapshot it then boot from the snapshot.<br>
>> >> ><br>
>> >> ><br>
>> >> > Non-persistent storage/disk is useful for sandbox-like environment,<br>
>> >> > and<br>
>> >> > this feature has already exists in VMWare ESX from version 4.1. The<br>
>> >> > implementation of ESX is the same as what you said, boot from<br>
>> >> > snapshot of<br>
>> >> > the disk/volume, but it will also *automatically* delete the<br>
>> >> > transient<br>
>> >> > snapshot after the instance reboots or shutdowns. I think the whole<br>
>> >> > procedure may be controlled by OpenStack other than user's manual<br>
>> >> > operations.<br>
>> >><br>
>> >> Why reboot an instance? What is wrong with deleting it and create a new<br>
>> >> one?<br>
>> >><br>
>> >> ><br>
>> >> > As far as I know, libvirt already defines the corresponding<br>
>> >> > <transient><br>
>> >> > element in domain xml for non-persistent disk ( [1] ), but it cannot<br>
>> >> > specify<br>
>> >> > the location of the transient snapshot. Although qemu-kvm has<br>
>> >> > provided<br>
>> >> > support for this feature by the "-snapshot" command argument, which<br>
>> >> > will<br>
>> >> > create the transient snapshot under /tmp directory, the qemu driver<br>
>> >> > of<br>
>> >> > libvirt don't support <transient> element currently.<br>
>> >> ><br>
>> >> > I think the steps of creating and deleting transient snapshot may be<br>
>> >> > better to done by Nova/Cinder other than waiting for the <transient><br>
>> >> > support<br>
>> >> > added to libvirt, as the location of transient snapshot should<br>
>> >> > specified by<br>
>> >> > Nova.<br>
>> >> ><br>
>> >> ><br>
>> >> > [1] <a href="http://libvirt.org/formatdomain.html#elementsDisks" target="_blank">http://libvirt.org/formatdomain.html#elementsDisks</a><br>
>> >> > ----------<br>
>> >> > zhangleiqiang<br>
>> >> ><br>
>> >> > Best Regards<br>
>> >> ><br>
>> >> ><br>
>> >> >> -----Original Message-----<br>
>> >> >> From: Joe Gordon [mailto:<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>]<br>
>> >> >> Sent: Tuesday, March 04, 2014 11:26 AM<br>
>> >> >> To: OpenStack Development Mailing List (not for usage questions)<br>
>> >> >> Cc: Luohao (brian)<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 Mon, Mar 3, 2014 at 6:00 PM, Yuzhou (C) <<a href="mailto:vitas.yuzhou@huawei.com">vitas.yuzhou@huawei.com</a>><br>
>> >> >> wrote:<br>
>> >> >> > Hi stackers,<br>
>> >> >> ><br>
>> >> >> > As far as I know ,there are two types of storage used by VM in<br>
>> >> >> > openstack:<br>
>> >> >> Ephemeral Storage and Persistent Storage.<br>
>> >> >> > Data on ephemeral storage ceases to exist when the instance it is<br>
>> >> >> > associated<br>
>> >> >> with is terminated. Rebooting the VM or restarting the host server,<br>
>> >> >> however, will not destroy ephemeral data.<br>
>> >> >> > Persistent storage means that the storage resource outlives any<br>
>> >> >> > other<br>
>> >> >> resource and is always available, regardless of the state of a<br>
>> >> >> running<br>
>> >> >> instance.<br>
>> >> >> ><br>
>> >> >> > There is a use case that maybe need a new type of storage, maybe<br>
>> >> >> > we<br>
>> >> >> > can<br>
>> >> >> call it non-persistent storage .<br>
>> >> >> > The use case is that VMs are assigned to the public ephemerally in<br>
>> >> >> > public<br>
>> >> >> areas.<br>
>> >> >> > After the VM is used, new data on storage of VM ceases to exist<br>
>> >> >> > when the<br>
>> >> >> instance it is associated with is stopped.<br>
>> >> >> > It means stop the VM, Non-persistent storage used by VM will be<br>
>> >> >> > rollback<br>
>> >> >> automatically.<br>
>> >> >> ><br>
>> >> >> > Is there any other suggestions? Or any BPs about this use case?<br>
>> >> >> ><br>
>> >> >><br>
>> >> >> This sounds like ephemeral storage plus snapshots. You build a base<br>
>> >> >> image, snapshot it then boot from the snapshot.<br>
>> >> >><br>
>> >> >> > Thanks!<br>
>> >> >> ><br>
>> >> >> > Zhou Yu<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>
>> >> > 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>
>> >> 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>
>> ><br>
>> > --<br>
>> > Qin Zhao<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>
><br>
><br>
><br>
><br>
> --<br>
> Qin Zhao<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><br clear="all"><br>-- <br><div dir="ltr">Qin Zhao<br></div>
</div>