Open Stack

Response inline.
>
> 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 .
>

Your change isn't. But including deleted is increasing the possibility
of using that method somewhere else with a wider criterion. Image member
is idxed but the criterion that can be used to find members is not
necessarily going to be.

I think adding a NOTE to that method mentioning what cases it's safe to
use it should help. This looks like a okay tradeoff given the call is
mostly safe. We can discuss further on the review as ML shouldn't be
used for such.

>
>
> Best regards,
> LongQuan
>
>
> Inactive hide details for Nikhil Komawar ---2015/07/10
> 22:34:16---Please find the response inline. >Nikhil Komawar
> ---2015/07/10 22:34:16---Please find the response inline. >
>
> 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_
>     <mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
>     _http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_
>
>
> -- 
>
> Thanks,
> Nikhil

-- 

Thanks,
Nikhil