Open Stack

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