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 <kuv...@hp.com
<mailto:kuv...@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.koma...@rackspace.com
    <mailto:nikhil.koma...@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.pie...@gmail.com
    <mailto:chris.a.st.pie...@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.koma...@rackspace.com <mailto:nikhil.koma...@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.pie...@gmail.com
        <mailto:chris.a.st.pie...@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
        <vishvana...@gmail.com <mailto:vishvana...@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_colli...@cable.comcast.com
            <mailto:sean_colli...@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@lists.openstack.org
            <mailto:OpenStack-dev@lists.openstack.org>
            >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


            _______________________________________________
            OpenStack-dev mailing list
            OpenStack-dev@lists.openstack.org
            <mailto:OpenStack-dev@lists.openstack.org>
            
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev____



        ____

        __ __

        -- ____

        Chris St. Pierre____


        _______________________________________________
        OpenStack-dev mailing list
        OpenStack-dev@lists.openstack.org
        <mailto:OpenStack-dev@lists.openstack.org>
        http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev____



    ____

    __ __

    -- ____

    Chris St. Pierre____


    _______________________________________________
    OpenStack-dev mailing list
    OpenStack-dev@lists.openstack.org
    <mailto:OpenStack-dev@lists.openstack.org>
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Chris St. Pierre


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to