Open Stack

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
>