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.
Thanks,
lijie
-- Original --
From: "Tomáš Vondra"<von...@homeatcloud.cz>;
Date: Wed, Mar 14, 2018 11:43 PM
To: "OpenStack Developmen"<openstack-dev@lists.openstack.org>;
"openstack-operators"<openstack-operat...@lists.openstack.org>;
Subject: Re: [openstack-dev] [Openstack-operators] [nova] about
rebuildinstance booted from volume
Hi!
I say delete! Delete them all!
Really, it's called delete_on_termination and should be ignored on Rebuild.
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).
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.
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.
Tomas from Homeatcloud
-Original Message-
From: Saverio Proto [mailto:ziopr...@gmail.com]
Sent: Wednesday, March 14, 2018 3:19 PM
To: Tim Bell; Matt Riedemann
Cc: OpenStack Development Mailing List (not for usage questions);
openstack-operat...@lists.openstack.org
Subject: Re: [Openstack-operators] [openstack-dev] [nova] about rebuild
instance booted from volume
My idea is that if delete_on_termination flag is set to False the Volume should
never be deleted by Nova.
my 2 cents
Saverio
2018-03-14 15:10 GMT+01:00 Tim Bell <tim.b...@cern.ch>:
> Matt,
>
> 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.
>
> Tim
>
>
> -Original Message-
> From: Matt Riedemann <mriede...@gmail.com>
> Reply-To: "OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> Date: Wednesday, 14 March 2018 at 14:55
> To: "openstack-dev@lists.openstack.org"
> <openstack-dev@lists.openstack.org>, openstack-operators
> <openstack-operat...@lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] about rebuild instance booted from
> volume
>
> On 3/14/2018 3:42 AM, 李杰 wrote:
> >
> > This is the spec about rebuild a instance booted from
> > volume.In the spec,there is a
> >question about if we should delete the old root_volume.Anyone who
> > is interested in
> >booted from volume can help to review this. Any suggestion is
> > welcome.Thank you!
> >The link is here.
> >Re:the rebuild spec:https://review.openstack.org/#/c/532407/
>
> Copying the operators list and giving some more context.
>
> This spec is proposing to add support for rebuild with a new image for
> volume-backed servers, which today is just a 400 failure in the API
> since the compute doesn't support that scenario.
>
> With the proposed solution, the backing root volume would be deleted and
> a new volume would be created from the new image, similar to how boot
> from volume works.
>
> The question raised in the spec is whether or not nova should delete the
> root volume even if its delete_on_termination flag is set to False. The
> semantics get a bit weird here since that flag was not meant for this
> scenario, it's meant to be used when deleting the server to which the
> volume is attached. Rebuilding a server is not deleting it, but we would
> need to replace the root volume, so what do we do with the volume we're
> replacing?
>
> Do we say that delete_on_termination only applies to deleting a server
> and not rebuild and therefore nova can delete the root volume during a
> rebuild?
>
> If we don't delete the volume during rebuild, we could end up leaving a
> lot of volumes lying around that the user then has to clean up,
> otherwise they'll eventually go over quota.
>
> We need user (and operator) feedback on this issue and what they would
> expect to happen.
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-de
