Re: [openstack-dev] [glance] Why does Glance keep the deleted membership of image ?
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 > To: "OpenStack Development Mailing List (not for usage questions)" > > 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
Re: [openstack-dev] [glance] Why does Glance keep the deleted membership of image ?
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
To: "OpenStack Development Mailing List (not for usage questions)"
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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
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
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 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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
[openstack-dev] [glance] Why does Glance keep the deleted membership of image ?
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. 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. Best regards, LongQuan __ 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
