[openstack-dev] [glance] Option to skip deleting images in use?
Chris St. Pierre
chris.a.st.pierre at gmail.com
Fri Dec 19 02:27:47 UTC 2014
Presumably to prevent images from being deleted for arbitrary reasons that
are left to the administrator(s) of each individual implementation of
OpenStack, though. Using the protected flag to prevent images that are in
use from being deleted obviates the ability to use it for arbitrary
protection. That is, it can either be used as a general purpose flag to
prevent deletion of an image; or it can be used as a flag for images that
are in use and thus must not be deleted; but it cannot be used for both.
(At least, not without a wild and woolly network of hacks to ensure that it
can serve both purposes.)
Given the general-purpose nature of the flag, I don't think that something
that should be taken away from the administrators. And yet, it's very
desirable to prevent deletion of images that are in use. I think both of
these things should be supported, at the same time on the same
installation. I do not consider it a solution to the problem that images
can be deleted in use to take the "protected" flag away from arbitrary,
bespoke use.
On Thu, Dec 18, 2014 at 6:44 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> On 12/18/2014 02:08 PM, Chris St. Pierre wrote:
>
>> I wasn't suggesting that we *actually* use filesystem link count, and
>> make hard links or whatever for every time the image is used. That's
>> prima facie absurd, for a lot more reasons that you point out. I was
>> suggesting a new database field that tracks the number of times an image
>> is in use, by *analogy* with filesystem link counts. (If I wanted to be
>> unnecessarily abrasive I might say, "This is a textbook example of
>> something called an analogy," but I'm not interested in being
>> unnecessarily abrasive.)
>>
>> Overloading the protected flag is *still* a terrible hack. Even if we
>> tracked the initial state of "protected" and restored that state when an
>> image went out of use, that would negate the ability to make an image
>>
>
> I guess I don't understand what you consider to be overloading of the
> protected flag. The original purpose of the protected flag was to protect
> images from being deleted.
>
> Best,
> -jay
>
> protected while it was in use and expect that change to remain in place.
>> So that just violates the principle of least surprise. Of course, we
>> could have glance modify the "original_protected_state" flag when that
>> flag is non-null and the user changes the actual "protected" flag, but
>> this is just layering hacks upon hacks. By actually tracking the number
>> of times an image is in use, we can preserve the ability to protect
>> images *and* avoid deleting images in use.
>>
>> On Thu, Dec 18, 2014 at 5:27 AM, Kuvaja, Erno <kuvaja at hp.com
>> <mailto:kuvaja at hp.com>> wrote:
>>
>> I think that’s horrible idea. How do we do that store independent
>> with the linking dependencies?____
>>
>> __ __
>>
>> We should not depend universal use case like this on limited subset
>> of backends, specially non-OpenStack ones. Glance (nor Nova) should
>> never depend having direct access to the actual medium where the
>> images are stored. I think this is school book example for something
>> called database. Well arguable if this should be tracked at Glance
>> or Nova, but definitely not a dirty hack expecting specific backend
>> characteristics.____
>>
>> __ __
>>
>> As mentioned before the protected image property is to ensure that
>> the image does not get deleted, that is also easy to track when the
>> images are queried. Perhaps the record needs to track the original
>> state of protected flag, image id and use count. 3 column table and
>> couple of API calls. Lets not at least make it any more complicated
>> than it needs to be if such functionality is desired.____
>>
>> __ __
>>
>> __-__Erno____
>>
>> __ __
>>
>> *From:*Nikhil Komawar [mailto:nikhil.komawar at RACKSPACE.COM
>> <mailto:nikhil.komawar at RACKSPACE.COM>]
>> *Sent:* 17 December 2014 20:34
>>
>>
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [glance] Option to skip deleting
>> images in use?____
>>
>> __ __
>>
>> Guess that's a implementation detail. Depends on the way you go
>> about using what's available now, I suppose.____
>>
>> __ __
>>
>> Thanks,
>> -Nikhil____
>>
>> ------------------------------------------------------------
>> ------------
>>
>> *From:*Chris St. Pierre [chris.a.st.pierre at gmail.com
>> <mailto:chris.a.st.pierre at gmail.com>]
>> *Sent:* Wednesday, December 17, 2014 2:07 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [glance] Option to skip deleting
>> images in use?____
>>
>> I was assuming atomic increment/decrement operations, in which case
>> I'm not sure I see the race conditions. Or is atomism assuming too
>> much?____
>>
>> __ __
>>
>> On Wed, Dec 17, 2014 at 11:59 AM, Nikhil Komawar
>> <nikhil.komawar at rackspace.com <mailto:nikhil.komawar at rackspace.com>>
>> wrote:____
>>
>> That looks like a decent alternative if it works. However, it
>> would be too racy unless we we implement a test-and-set for such
>> properties or there is a different job which queues up these
>> requests and perform sequentially for each tenant.____
>>
>> __ __
>>
>> Thanks,
>> -Nikhil____
>>
>> ------------------------------------------------------------
>> ------------
>>
>> *From:*Chris St. Pierre [chris.a.st.pierre at gmail.com
>> <mailto:chris.a.st.pierre at gmail.com>]
>> *Sent:* Wednesday, December 17, 2014 10:23 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [glance] Option to skip deleting
>> images in use?____
>>
>> That's unfortunately too simple. You run into one of two cases:
>> ____
>>
>> __ __
>>
>> 1. If the job automatically removes the protected attribute when
>> an image is no longer in use, then you lose the ability to use
>> "protected" on images that are not in use. I.e., there's no way
>> to say, "nothing is currently using this image, but please keep
>> it around." (This seems particularly useful for snapshots, for
>> instance.)____
>>
>> __ __
>>
>> 2. If the job does not automatically remove the protected
>> attribute, then an image would be protected if it had ever been
>> in use; to delete an image, you'd have to manually un-protect
>> it, which is a workflow that quite explicitly defeats the whole
>> purpose of flagging images as protected when they're in use.____
>>
>> __ __
>>
>> It seems like flagging an image as *not* in use is actually a
>> fairly difficult problem, since it requires consensus among all
>> components that might be using images.____
>>
>> __ __
>>
>> The only solution that readily occurs to me would be to add
>> something like a filesystem link count to images in Glance. Then
>> when Nova spawns an instance, it increments the usage count;
>> when the instance is destroyed, the usage count is decremented.
>> And similarly with other components that use images. An image
>> could only be deleted when its usage count was zero.____
>>
>> __ __
>>
>> There are ample opportunities to get out of sync there, but it's
>> at least a sketch of something that might work, and isn't *too*
>> horribly hackish. Thoughts?____
>>
>> __ __
>>
>> On Tue, Dec 16, 2014 at 6:11 PM, Vishvananda Ishaya
>> <vishvananda at gmail.com <mailto:vishvananda at gmail.com>> wrote:____
>>
>> A simple solution that wouldn’t require modification of
>> glance would be a cron job
>> that lists images and snapshots and marks them protected
>> while they are in use.
>>
>> Vish____
>>
>>
>> On Dec 16, 2014, at 3:19 PM, Collins, Sean
>> <Sean_Collins2 at cable.comcast.com
>> <mailto:Sean_Collins2 at cable.comcast.com>> wrote:
>>
>> > On Tue, Dec 16, 2014 at 05:12:31PM EST, Chris St. Pierre
>> wrote:
>> >> No, I'm looking to prevent images that are in use from
>> being deleted. "In
>> >> use" and "protected" are disjoint sets.
>> >
>> > I have seen multiple cases of images (and snapshots) being
>> deleted while
>> > still in use in Nova, which leads to some very, shall we
>> say,
>> > interesting bugs and support problems.
>> >
>> > I do think that we should try and determine a way forward
>> on this, they
>> > are indeed disjoint sets. Setting an image as protected is
>> a proactive
>> > measure, we should try and figure out a way to keep tenants
>> from
>> > shooting themselves in the foot if possible.
>> >
>> > --
>> > Sean M. Collins
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> >OpenStack-dev at lists.openstack.org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack-dev
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack-dev____
>>
>>
>>
>> ____
>>
>> __ __
>>
>> -- ____
>>
>> Chris St. Pierre____
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack-dev____
>>
>>
>>
>> ____
>>
>> __ __
>>
>> -- ____
>>
>> Chris St. Pierre____
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>> Chris St. Pierre
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Chris St. Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141218/7ddf5370/attachment.html>
More information about the OpenStack-dev
mailing list