Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160411/c332b717/attachment.html>