<div dir="ltr">Cool. That's the way which I desire  mostly. Here is the bug: <a href="https://bugs.launchpad.net/cinder/+bug/1670541">https://bugs.launchpad.net/cinder/+bug/1670541</a> and I'll update the patch ASAP. <div><br></div><div>Thanks very much for your explanation and  suggestion.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-06 22:43 GMT+08:00 yang, xing <span dir="ltr"><<a href="mailto:Xing.Yang@dell.com" target="_blank">Xing.Yang@dell.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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).<br>
<br>
Do you want to submit a bug fix for this change?<br>
<span class=""><br>
Thanks,<br>
Xing<br>
<br>
<br>
______________________________<wbr>__________<br>
From: 王玺源 [<a href="mailto:wangxiyuan1007@gmail.com">wangxiyuan1007@gmail.com</a>]<br>
</span>Sent: Sunday, March 5, 2017 9:51 PM<br>
<span class="">To: OpenStack Development Mailing List (not for usage questions)<br>
</span>Subject: Re: [openstack-dev] [cinder] Create backup with snapshots<br>
<span class=""><br>
Thanks, Xing.<br>
<br>
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.<br>
<br>
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.<br>
<br>
</span>2017-03-03 22:43 GMT+08:00 yang, xing <<a href="mailto:Xing.Yang@dell.com">Xing.Yang@dell.com</a><mailto:<a href="mailto:Xing.Yang@dell.com">Xin<wbr>g.Yang@dell.com</a>>>:<br>
<span class="">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.<br>
<br>
Thanks,<br>
Xing<br>
<br>
<br>
______________________________<wbr>__________<br>
</span>From: 王玺源 [<a href="mailto:wangxiyuan1007@gmail.com">wangxiyuan1007@gmail.com</a><<wbr>mailto:<a href="mailto:wangxiyuan1007@gmail.com">wangxiyuan1007@gmail.<wbr>com</a>>]<br>
<span class="">Sent: Thursday, March 2, 2017 10:21 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: [openstack-dev] [cinder] Create backup with snapshots<br>
<br>
Hi cinder team:<br>
We met a problem about backup create recently.<br>
<br>
The backup can be created from volumes or snapshots. In the both cases, the volume' s status is set to 'backing-up'.<br>
<br>
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.<br>
<br>
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?<br>
<br>
Thanks!<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
</span>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-<wbr>dev-request@lists.openstack.<wbr>org?subject:unsubscribe</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>