I didn't see that mention. You mean about legacy volumes and snapshots? On Mon, Apr 11, 2016 at 3:58 PM, Duncan Thomas <duncan.tho...@gmail.com> wrote:
> Ok, you're right about device naming by UUID. > > So we have two advantages compared to the existing system: > > - Keeping the same volume id (and therefore disk UUID) makes reverting a > VM much easier since device names inside the instance stay the same > - Can significantly reduce the amount of copying required on some backends > > These do seem like solid reasons to consider the feature. > > If you can solve the backwards compatibility problem mentioned further up > this thread, then I think there's a strong case for considering adding this > API. > > The next step is a spec and a PoC implementation. > > > > On 11 April 2016 at 20:57, Erlon Cruz <sombra...@gmail.com> wrote: > >> You are right, the instance should be shutdown or the device be >> unmounted, before 'revert' or removing the old device. That should be >> enough to avoid corruption. I think the device naming is not a problem if >> you use the same volume (at least the disk UUID will be the same). >> >> On Mon, Apr 11, 2016 at 2:39 PM, Duncan Thomas <duncan.tho...@gmail.com> >> wrote: >> >>> You can't just change the contents of a volume under the instance though >>> - at the very least you need to do an unmount in the instance, and a detach >>> is preferable, otherwise you've got data corruption issues. >>> >>> At that point, the device naming problems are identical. >>> >>> On 11 April 2016 at 20:22, Erlon Cruz <sombra...@gmail.com> wrote: >>> >>>> 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 >>>> >>>> >>> >>> >>> -- >>> -- >>> Duncan Thomas >>> >>> >>> __________________________________________________________________________ >>> 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 >> >> > > > -- > -- > Duncan Thomas > > __________________________________________________________________________ > 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