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.koma...@gmail.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Cc: Long Quan Sha/China/IBM@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-requ...@lists.openstack.org?subject:unsubscribe_ > <mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > _http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_ > > > -- > > Thanks, > Nikhil -- Thanks, Nikhil __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
