Open Stack

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> 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]
> *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
> > 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> 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
>> > 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
>
> _______________________________________________
> 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/20141217/e16c20ce/attachment.html>