Open Stack

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.thomas at 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 <sombrafam at 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.thomas at 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 <sombrafam at 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 <e0ne at 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 <
>>>>> chenzongliang at 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:sombrafam at 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 <
>>>>>> chenzongliang at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160412/fe7c3baa/attachment.html>