Open Stack

On Mon, Aug 10, 2015 at 9:54 PM, hao wang <sxmatch1986 at gmail.com> wrote:

> @Duncan and John, I have a idea about this issue,  if volume is in-use but
> the instance which it's attached to is power-off, so can we avoid data
> corruption? If it's true, cinder could free the "available" restriction,
> let user decide if they want to restore the boot disk, and they should shut
> down the instance first and then restore volume.
>
> 2015-08-11 11:30 GMT+08:00 hao wang <sxmatch1986 at gmail.com>:
>
>> @Duncan and John, thank you both and I have understood this.  The reason
>> I ask this question is we can't restore the boot volume of instance which
>> is boot-from-volume, since Nova can't detach the boot disk now. So we need
>> to figure out a way to solve this issue.
>>
>> Maybe we should let nova can detach the boot disk, but there are also
>> some problems, like "what state should be set after detach the boot disk?
>> Can user reboot/stop/migrate the instance after detach the boot disk? etc".
>>
>> Anyway, I feel it may be a long way to solve this issue properly.
>>
>> 2015-08-11 0:13 GMT+08:00 John Griffith <john.griffith8 at gmail.com>:
>>
>>>
>>>
>>> On Mon, Aug 10, 2015 at 3:47 AM, hao wang <sxmatch1986 at gmail.com> wrote:
>>>
>>>> Sorry if I missed something, since now we have supported backup in-use
>>>> volumes in L,  so I wonder is there some plan or design to support
>>>> restoring on-line volumes.
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>>
>>>> Best Wishes For You!
>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>>>
>>>> ​No, a restore operation is going to require that the volume be taken
>>> offline for a number of reasons.  Even with multi-attach if/when it ever
>>> becomes a reality you can't write to the volume while it's in use by
>>> another Instance (corruption, file system updates etc etc)​ unless you're
>>> using a shared FS or clustered File System.
>>>
>>> That's a use case that I don't think has a ton of value and it's not
>>> compelling enough to introduce all of the issues that come along with it
>>> IMO.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>>
>>
>>
>> --
>>
>> Best Wishes For You!
>>
>>
>
>
> --
>
> Best Wishes For You!
>
>
> __________________________________________________________________________
> 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
>
> ​Wouldn't a detach be less impact than powering off the instance?  I don't
understand why this is desired?  Is there a compelling reason perhaps that
I'm not aware of for this?
​
Oh... maybe you are thinking specifically for the boot from volume case
here?

I guess if that's the case I could see why you may desire to keep the
instance ID etc after a restore.  Although I wish we could all just agree
that things in Clouds are dynamic and things like their ID can change and
just deal with it.  For point in time recovery type things I still think
snapshots are great, for full DR, backups are preferred and with full DR
scenarios I don't think it's unreasonable to require a little extra effort.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150811/eb5f5f6d/attachment.html>