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
[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
Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected
I have the same concern as a Chinese, Emperor Meiji will be linked to a war happened in 1895, also invasion of Taiwan. That is so bad historical memory for Chinese. Refer to : https://en.wikipedia.org/wiki/First_Sino-Japanese_War I recommend selecting another candidate. >It is totally understandable that the combination of "Japan" and >"Meiji" recalls harsh history to some people, especially in East Asia. >As a Japanese, I'm sorry for that. >I think the release naming process should not cause such friction. >Could we just select some other neutral candidate name instead? >At Wed, 08 Jul 2015 04:40:58 +, >Jaesuk Ahn wrote: > > Dear OpenStack Community, > > As Clint mentioned, there is some historical background regarding the name > of "Meiji". > > I have been aware of the potential problem with "Meiji", however, I have > not raise my voice here since it was not the top of the list. > However, with current situation, IMHO, it is better to present my concern > over this name. > > It was briefly mentioned in the previous email thread. > Once again, please understand that the name "Meiji" can create some > historical debate in East Asia, especially in Korea. Under the name of > t, Japan forcefully colonized Korea. Lots of people in Korea > suffered during the colonization. Furthermore, this history is not the one > only exists on the book. This is actually very recent event in terms of > history. > > FYI, there is a wiki entry: > https://en.wikipedia.org/wiki/Korea_under_Japanese_rule > If you look at "legacy" section in the above wiki entry, you will > understand what I am referring to. > > I am not saying the word "Meiji" is bad in general. I just want to state > that this word can cause very negative feeling to some people in East Asia. > > I totally value the community's process and rules. I recognize that process > to select "Meiji" itself was not the problem at all. > However, I am sincerely asking the community to acknowledge my concern over > this name, and please put some effort as a community to avoid any > unnecessary debate. > > Thank you. > > Best wishes for everyone here in the community. > > > Jaesuk Ahn, Ph.D. > member of OpenStack Community and OpenStack Korea User Group. > > > > > On Wed, Jul 8, 2015 at 2:24 AM Clint Byrum wrote: > > > http://afe.easia.columbia.edu/main_pop/kpct/kp_meiji.htm > > > > There's a summary of what Meiji might mean to historians. I'm not sure if > > OpenStack needs to be too concerned about this, but I believe this is what > > Ian is referring to as "historical and political debates in East Asia." > > > > Seems like a hot-button name for OpenStack to adopt. > > > > Excerpts from Ian Y. Choi's message of 2015-07-07 05:40:52 -0700: > > > Hello, > > > > > > I think the third name 'Meiji' may arise some historical and political > > > debates in East Asia, as far as I know. > > > > > > Could you share what significant identified problems are on the first two > > > selected from our election? > > > > > > > > > With many thanks, > > > > > > /Ian > > > > > > On Tue, Jul 7, 2015 at 8:55 PM, Masayuki Igawa > > > > > wrote: > > > > > > > Hi, > > > > # I'm a native Japanese speaker :-) > > > > > > > > 2015年7月7日(火) 20:33 Amrith Kumar : > > > > > > > >> Maybe this (the google answer)? > > > >> > > > >> www.youtube.com/watch?v=Qvw0A12aOGQ > > > > > > > > > > > > Yeah, this is correct pronunciation. > > > > > > > > > > > >> But someone who is a native Japanese speaker should confirm. > > > >> > > > > > > > > https://www.youtube.com/watch?v=D9vwge557hY > > > > I think this is a casual version and Japanese people are familiar with > > > > this. > > > > > > > > Thanks, > > > > -- Masayuki Igawa > > > > > > > > > > > >> -amrith > > > >> > > > >> P.S. the yahoo answer suggests that you pronounce it as "Meh - gee" > > with > > > >> the emphasis on the "meh" ;) > > > >> > > > >> -Original Message- > > > >> From: Matthias Runge [mailto:mru...@redhat.com] > > > >> Sent: Tuesday, July 07, 2015 6:08 AM > > > >> To: openstack-dev@lists.openstack.org > > > >> Subject: Re: [openstack-dev] OpenStack Meiji (明治) - Our next release > > name > > > >> has been selected > > > >> > > > >> On Mon, Jul 06, 2015 at 11:48:13PM -0400, Monty Taylor wrote: > > > >> > significant identified problems... but the third in the list, Meiji > > (明 > > > >> > 治) is clear. > > > >> > > > > >> > So please join me in welcoming the latest name to our family ... and > > > >> > if you, like me, are not a native Japanese speaker, in learning two > > > >> > new characters. > > > >> > > > >> Could someone provide a hint please, how to pronounce this properly? > > > >> -- > > > >> Matthias Runge > > > >> > > > >> > > __ > > > >> OpenStack Development Mailing List (not for usage questions) > > > >> Unsubscribe: > > > >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > > >> http://lists.openstack.org/cgi-bin/mailman/listi
[openstack-dev] [Glancel] why does Glance keep the deleted membership of image ?
Hi Glance team, 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, 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
