Open Stack

I can't understand how the impact on performance, image-members still have
an idx. Is there any other concern on the patch ?  How to get result from
"rally gate job" ?

Can you give me suggestion on how to move forward ?  Thanks .



Best regards,
LongQuan




From:	Nikhil Komawar <nik.komawar at gmail.com>
To:	"OpenStack Development Mailing List (not for usage questions)"
            <openstack-dev at lists.openstack.org>
Cc:	Long Quan Sha/China/IBM at IBMCN
Date:	2015/07/10 22:34
Subject:	Re: [openstack-dev] [glance] Why does Glance keep the deleted
            membership of image ?



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/6fc2c8cd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150710/6fc2c8cd/attachment.gif>