Excellent! Review comments added to your patch. Thanks!
Xing ________________________________________ From: 王玺源 [wangxiyuan1...@gmail.com] Sent: Monday, March 6, 2017 8:08 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [cinder] Create backup with snapshots 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.y...@dell.com<mailto:xing.y...@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: 王玺源 [wangxiyuan1...@gmail.com<mailto:wangxiyuan1...@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.y...@dell.com<mailto:xing.y...@dell.com><mailto:xing.y...@dell.com<mailto:xing.y...@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: 王玺源 [wangxiyuan1...@gmail.com<mailto:wangxiyuan1...@gmail.com><mailto:wangxiyuan1...@gmail.com<mailto:wangxiyuan1...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe><http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
