[openstack-dev] [glance] Why does Glance keep the deleted membership of image ?

Nikhil Komawar nik.komawar at gmail.com
Fri Jul 10 14:34:01 UTC 2015


Please find the response inline.
>
> Hi Glance experts,
>
> I'd like to send this mail again, hope I can get help and suggest from
> glance experts. The question is from a bug
> https://bugs.launchpad.net/glance/+bug/1462315,
>
> If an image-member is deleted, then create it again with the same
> parameters, glance searches db to see if there is already an existing
> one, but the result doesn't include the record which was marked as
> deleted,
> glance will try to create a new one with the same parameters, it works
> well on mysql. But it is failed on DB2 with SQL0803N error.
>
> The root cause is that DB2 constraint is more restricted than mysql.
> For db2, the columns under unique constrains should be "NOT NULL",
> currently the column "deleted_at" which is one of unique constrain of
> image_members
> is nullable. A possible solution is to alter it to "not null" in
> migration. that means we have to insert a default timestamp value for
> the new created image-member, an active member with a no-blank
> timestamp for "deleted_at" seems very confusing.  
>

Agree that this is confusing. And changing the behavior this way is NOT
a good idea. A record that's never been deleted should not have
deleted(_at) value. It will affect notifications and conflict with API
guidelines.

> Another fix is: we may check all existing image-member records
> including the deleted image-member before create image-member, then
> update it if it exists, otherwise create a new one, that is proposed
> in https://review.openstack.org/#/c/190895/
>
>
> I'm wondering why can't we use only one record to maintain the
> member-ship between a pair of image and tenant. Maybe there is some
> other consideration, can you help give me some suggestion ? I'd like
> to know more. Thanks.
>
>

Concept wise this sounds like a good idea but it could have performance
degradation impact. Nonetheless, image-members have an idx that should
be a relief for that query image_member_find that you added in your
proposal. My hope is that the rally gate job will tell us more if there
is a performance problem.

> Best regards,
> LongQuan
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150710/88c3c1c8/attachment.html>


More information about the OpenStack-dev mailing list