The actual user workflow is: 1 - User creates a volume(s) 2 - User attach volume to instance 3 - User creates a snapshot 4 - Something happens causing the need of a revert 5 - User creates a volume(s) from the snapshot(s) 6 - User detach old volumes 7 - User attach new volumes (and pray so they get the same id) - Nova, should have the ability to honor supplied device names (vdc, vdd, etc), which not always happen[1]. But, does the volume keep the same UUID in the system? Several application use that to boot.
The suggested workflow would be simpler for a user POV: 1 - User creates a volume(s) 2 - User attach volume to instance 3 - User creates a snapshot 4 - Something happens causing the need of a revert 5 - User revert snapshot(s) [1] https://goo.gl/Kusfne On Fri, Apr 8, 2016 at 5:07 AM, Ivan Kolodyazhny <e...@e0ne.info> wrote: > Hi Chenzongliang, > > I still don't understand what is difference between proposed feature and > 'restore volume from snapshot'? Could you please explain it? > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > On Thu, Apr 7, 2016 at 12:00 PM, Chenzongliang <chenzongli...@huawei.com> > wrote: > >> Dear Cruz: >> >> >> >> Thanks for you kind support, I will review the previous spec >> according to the following links. May be more user scenario we should >> considered,such as backup,create volume from snapshot,consistency group and >> etc,we will spend some time to gather >> >> the user's scenarios and determin what to do next step. >> >> >> >> Sincerely, >> >> zongliang chen >> >> >> >> *发件人:* Erlon Cruz [mailto:sombra...@gmail.com] >> *发送时间:* 2016年4月5日 2:50 >> *收件人:* OpenStack Development Mailing List (not for usage questions) >> *抄送:* Zhangli (ISSP); Shenhong (C) >> *主题:* Re: [openstack-dev] [Cinder] About snapshot Rollback? >> >> >> >> Hi Chen, >> >> >> >> Not sure if I got you right but I brought this topic in #openstack-cinder >> some days ago. The idea is to be able to rollback a snapshot in Cinder. >> Today what is possible to do is to create a volume from a snapshot. From >> the user point of view, this is not ideal, as there are several cases, if >> not the majority of, that the purpose of the snapshot is to revert to a >> desired state, and not keep the original volume. For some backends, keeping >> the original volume means space consumption. This space problem becomes >> bold when we think about consistency groups. For consistency groups, some >> backends might have to copy an entire filesystem for each snapshot, >> consuming space and time. So, I think it would be desired to have the >> ability to revert snapshots. >> >> >> >> I know there have been efforts in the past[1] to implement that, but for >> some reason the work was stopped. If you want to retake the effort please >> create a spec[2] sol everybody can provide feedback. >> >> >> >> Erlon >> >> >> >> >> >> [1] >> https://blueprints.launchpad.net/cinder/+spec/cinder-volume-rollback-snapshot >> >> [2] https://github.com/openstack/cinder-specs >> >> >> >> On Thu, Mar 24, 2016 at 6:09 AM, Chenzongliang <chenzongli...@huawei.com> >> wrote: >> >> Hi all: >> >> We are condering add a fucntion rollback_snapshot when we use backup. >> In the end user's scenario. If a vm fails, we hope that we can use snapshot >> to to recovery the volume's data. >> >> Beacuse it can quickly recovery our vm. But if we use the remote data >> to recovery. We will spend more time. >> >> But i'm not sure if the data was recoveried from the backend. whether >> the host need to rescan the volumes? At the same time. If a volume have >> been extended, whether it can be roolback? >> >> >> >> I want to know whether the topic have been discussed or have other >> recommendations to us? >> >> >> >> Thanks >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
