<div>It seems that  we  can  only delete the snapshots of the original volume firstly,then delete the original volume if the original volume has snapshots.</div><div><includetail><div> </div><div>Thanks,</div><div>lijie</div><div style="font:Verdana normal 14px;color:#000;"><div style="FONT-SIZE: 12px;FONT-FAMILY: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="FONT-SIZE: 12px;background:#efefef;padding:8px;"><div id="menu_sender"><b>From: </b> "Tomáš Vondra"<vondra@homeatcloud.cz>;</div><div><b>Date: </b> Wed, Mar 14, 2018 11:43 PM</div><div><b>To: </b> "OpenStack Developmen"<openstack-dev@lists.openstack.org>; "openstack-operators"<openstack-operators@lists.openstack.org>; <wbr></div><div></div><div><b>Subject: </b> Re: [openstack-dev] [Openstack-operators] [nova] about rebuildinstance booted from volume</div></div><div> </div><div style="position:relative;">Hi!<br>I say delete! Delete them all!<br>Really, it's called delete_on_termination and should be ignored on Rebuild.<br>We have a VPS service implemented on top of OpenStack and do throw the old contents away on Rebuild. When the user has the Backup service paid, they can restore a snapshot. Backup is implemented as volume snapshot, then clone volume, then upload to image (glance is on a different disk array).<br><br>I also sometimes multi-attach a volume manually to a service node and just dd an image onto it. If it was to be implemented this way, then there would be no deleting a volume with delete_on_termination, just overwriting. But the effect is the same.<br><br>IMHO you can have snapshots of volumes that have been deleted. Just some backends like our 3PAR don't allow it, but it's not disallowed in the API contract.<br>Tomas from Homeatcloud<br><br>-----Original Message-----<br>From: Saverio Proto [mailto:zioproto@gmail.com] <br>Sent: Wednesday, March 14, 2018 3:19 PM<br>To: Tim Bell; Matt Riedemann<br>Cc: OpenStack Development Mailing List (not for usage questions); openstack-operators@lists.openstack.org<br>Subject: Re: [Openstack-operators] [openstack-dev] [nova] about rebuild instance booted from volume<br><br>My idea is that if delete_on_termination flag is set to False the Volume should never be deleted by Nova.<br><br>my 2 cents<br><br>Saverio<br><br>2018-03-14 15:10 GMT+01:00 Tim Bell <Tim.Bell@cern.ch>:<br>> Matt,<br>><br>> To add another scenario and make things even more difficult (sorry (), if the original volume has snapshots, I don't think you can delete it.<br>><br>> Tim<br>><br>><br>> -----Original Message-----<br>> From: Matt Riedemann <mriedemos@gmail.com><br>> Reply-To: "OpenStack Development Mailing List (not for usage <br>> questions)" <openstack-dev@lists.openstack.org><br>> Date: Wednesday, 14 March 2018 at 14:55<br>> To: "openstack-dev@lists.openstack.org" <br>> <openstack-dev@lists.openstack.org>, openstack-operators <br>> <openstack-operators@lists.openstack.org><br>> Subject: Re: [openstack-dev] [nova] about rebuild instance booted from <br>> volume<br>><br>>     On 3/14/2018 3:42 AM, 李杰 wrote:<br>>     ><br>>     >              This is the spec about  rebuild a instance booted from<br>>     > volume.In the spec,there is a<br>>     >        question about if we should delete the old root_volume.Anyone who<br>>     > is interested in<br>>     >        booted from volume can help to review this. Any suggestion is<br>>     > welcome.Thank you!<br>>     >        The link is here.<br>>     >        Re:the rebuild spec:https://review.openstack.org/#/c/532407/<br>><br>>     Copying the operators list and giving some more context.<br>><br>>     This spec is proposing to add support for rebuild with a new image for<br>>     volume-backed servers, which today is just a 400 failure in the API<br>>     since the compute doesn't support that scenario.<br>><br>>     With the proposed solution, the backing root volume would be deleted and<br>>     a new volume would be created from the new image, similar to how boot<br>>     from volume works.<br>><br>>     The question raised in the spec is whether or not nova should delete the<br>>     root volume even if its delete_on_termination flag is set to False. The<br>>     semantics get a bit weird here since that flag was not meant for this<br>>     scenario, it's meant to be used when deleting the server to which the<br>>     volume is attached. Rebuilding a server is not deleting it, but we would<br>>     need to replace the root volume, so what do we do with the volume we're<br>>     replacing?<br>><br>>     Do we say that delete_on_termination only applies to deleting a server<br>>     and not rebuild and therefore nova can delete the root volume during a<br>>     rebuild?<br>><br>>     If we don't delete the volume during rebuild, we could end up leaving a<br>>     lot of volumes lying around that the user then has to clean up,<br>>     otherwise they'll eventually go over quota.<br>><br>>     We need user (and operator) feedback on this issue and what they would<br>>     expect to happen.<br>><br>>     --<br>><br>>     Thanks,<br>><br>>     Matt<br>><br>>     __________________________________________________________________________<br>>     OpenStack Development Mailing List (not for usage questions)<br>>     Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>><br>><br>> _______________________________________________<br>> OpenStack-operators mailing list<br>> OpenStack-operators@lists.openstack.org<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operator<br>> s<br><br>_______________________________________________<br>OpenStack-operators mailing list<br>OpenStack-operators@lists.openstack.org<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br><br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></div></div><!--<![endif]--></includetail></div>