Open Stack

Cool. That's the way which I desire  mostly. Here is the bug:
https://bugs.launchpad.net/cinder/+bug/1670541 and I'll update the patch
ASAP.

Thanks very much for your explanation and  suggestion.

2017-03-06 22:43 GMT+08:00 yang, xing <Xing.Yang at dell.com>:

> I don't think we should add a separate API for backing up a snapshot.  We
> could do a check in the backup API to see whether snapshot_id is provided
> or not.  If provided, we change the status of the snapshot; otherwise, we
> change the status of the volume as usual.  Changes are needed in
> backup/api.py and backup/manager.py (to change the status back).
>
> Do you want to submit a bug fix for this change?
>
> Thanks,
> Xing
>
>
> ________________________________________
> From: 王玺源 [wangxiyuan1007 at gmail.com]
> Sent: Sunday, March 5, 2017 9:51 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [cinder] Create backup with snapshots
>
> Thanks, Xing.
>
> I got the history reason now. So is it possible that we can devide the
> create API into two APIs? One is for create backup from volumes, another is
> from snapshots. Then we can control the volumes' and snapshots' status
> dividually and easily.
>
> When create a backup from a large snapshot, such as larger than 1 TB, It
> will costs few hours generally. It's really a problem that the volume is
> not available for such a long time.
>
> 2017-03-03 22:43 GMT+08:00 yang, xing <Xing.Yang at dell.com<mailto:Xin
> g.Yang at dell.com>>:
> In the original backup API design, volume_id is a required field.  In the
> CLI, volume_id is positional and required as well.  So when I added support
> to backup from a snapshot, I added snapshot_id as an optional field in the
> request body of the backup API.  While backup is in process, you cannot
> delete the volume.  Backup from snapshot and backup from volume are using
> the same API.  So I think volume status should be changed to “backing-up”
> to be consistent.  Now I’m thinking the status of the snapshot should be
> changed to “backing-up” too if snapshot_id is provided.
>
> Thanks,
> Xing
>
>
> ________________________________________
> From: 王玺源 [wangxiyuan1007 at gmail.com<mailto:wangxiyuan1007 at gmail.com>]
> Sent: Thursday, March 2, 2017 10:21 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [cinder] Create backup with snapshots
>
> Hi cinder team:
> We met a problem about backup create recently.
>
> The backup can be created from volumes or snapshots. In the both cases,
> the volume' s status is set to 'backing-up'.
>
> But as I know, when users create backup with snapshots, the volume is not
> used(Correct me if I'm wrong). So why the volume's status is changed ?
> Should it keep available? It's a little strange that the volume is
> "backing-up" but actually only the snapshot is used for backup creation.
> the volume in "backing-up" means that it can't be used for some other
> actions. Such as: attach, delete, export to image, extend, create from
> volume, create backup from volume and so on.
>
> So is there any reason we changed the volume' status here? Or is there any
> third part driver need the volume's status must be "backing-up" when create
> backup from snapshots?
>
> Thanks!
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170307/88a92de7/attachment.html>