Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
Min, Between this issue and 1745, it may be prudent to give the create-schema.sql a good once over to ensure that we don't have any other schema issues. Thanks, -John On Mar 20, 2013, at 2:08 PM, Min Chen min.c...@citrix.com wrote: Hi Chip, I created this bug https://issues.apache.org/jira/browse/CLOUDSTACK-1747 because I noticed yesterday in dev setup that after running mvn -P developer -pl developer –Ddeploydb, my DB is still at 4.0 version, not expected 4.1 version. This is causing so much confusion to developers. We can only see our new schema introduced in 4.1 after we restart MS the first time. This is not the expected behavior for new fresh db creation change. The correct commit is already in master, we just need to cherry-pick them to 4.1, so I assigned this bug to you to cherry-pick those 2 commits from master to 4.1. Thanks -min
Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
On Wed, Mar 20, 2013 at 11:08:01AM -0700, Min Chen wrote: Hi Chip, I created this bug https://issues.apache.org/jira/browse/CLOUDSTACK-1747 because I noticed yesterday in dev setup that after running mvn -P developer -pl developer –Ddeploydb, my DB is still at 4.0 version, not expected 4.1 version. This is causing so much confusion to developers. We can only see our new schema introduced in 4.1 after we restart MS the first time. This is not the expected behavior for new fresh db creation change. The correct commit is already in master, we just need to cherry-pick them to 4.1, so I assigned this bug to you to cherry-pick those 2 commits from master to 4.1. Thanks -min ACK - thanks
Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
On Wed, Mar 20, 2013 at 11:08:01AM -0700, Min Chen wrote: Hi Chip, I created this bug https://issues.apache.org/jira/browse/CLOUDSTACK-1747 because I noticed yesterday in dev setup that after running mvn -P developer -pl developer –Ddeploydb, my DB is still at 4.0 version, not expected 4.1 version. This is causing so much confusion to developers. We can only see our new schema introduced in 4.1 after we restart MS the first time. This is not the expected behavior for new fresh db creation change. The correct commit is already in master, we just need to cherry-pick them to 4.1, so I assigned this bug to you to cherry-pick those 2 commits from master to 4.1. Thanks -min Min - please see Rohit's comments in the bug.
Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
Chip, Based on Rohit's comments, the blocking defect I raised may not be a bug. I will perform a rebuild tomorrow to determine if the template_s3_ref table gets created properly. Thanks, -John On Wed, Mar 20, 2013 at 2:13 PM, Chip Childers chip.child...@sungard.comwrote: On Wed, Mar 20, 2013 at 11:08:01AM -0700, Min Chen wrote: Hi Chip, I created this bug https://issues.apache.org/jira/browse/CLOUDSTACK-1747because I noticed yesterday in dev setup that after running mvn -P developer -pl developer –Ddeploydb, my DB is still at 4.0 version, not expected 4.1 version. This is causing so much confusion to developers. We can only see our new schema introduced in 4.1 after we restart MS the first time. This is not the expected behavior for new fresh db creation change. The correct commit is already in master, we just need to cherry-pick them to 4.1, so I assigned this bug to you to cherry-pick those 2 commits from master to 4.1. Thanks -min Min - please see Rohit's comments in the bug.
Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
Pl see https://cwiki.apache.org/confluence/display/CLOUDSTACK/Database+Creator Edit/add/modify wiki boldly in case something is confusing, missing. On Wed, Mar 20, 2013 at 11:43 PM, Chip Childers chip.child...@sungard.com wrote: On Wed, Mar 20, 2013 at 11:08:01AM -0700, Min Chen wrote: Hi Chip, I created this bug https://issues.apache.org/jira/browse/CLOUDSTACK-1747 because I noticed yesterday in dev setup that after running mvn -P developer -pl developer –Ddeploydb, my DB is still at 4.0 version, not expected 4.1 version. This is causing so much confusion to developers. We can only see our new schema introduced in 4.1 after we restart MS the first time. This is not the expected behavior for new fresh db creation change. The correct commit is already in master, we just need to cherry-pick them to 4.1, so I assigned this bug to you to cherry-pick those 2 commits from master to 4.1. Thanks -min Min - please see Rohit's comments in the bug.
Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
For 4.1, you deploydb (that would be 4.0 schema), run mgmt server (dbupgradechecker should upgrade to 4.1). Starting 4.2, dbcreator would do that (like on master) and cloud-setup-databases should call dbcreator as well. I tried to refactor the tool and upgrade classes, that did not work smoothly for me so did not move refactor. Only making cloud-setup-databases use dbcreator is pending. Regards. On Wed, Mar 20, 2013 at 11:46 PM, John Burwell jburw...@basho.com wrote: Chip, Based on Rohit's comments, the blocking defect I raised may not be a bug. I will perform a rebuild tomorrow to determine if the template_s3_ref table gets created properly. Thanks, -John On Wed, Mar 20, 2013 at 2:13 PM, Chip Childers chip.child...@sungard.comwrote: On Wed, Mar 20, 2013 at 11:08:01AM -0700, Min Chen wrote: Hi Chip, I created this bug https://issues.apache.org/jira/browse/CLOUDSTACK-1747because I noticed yesterday in dev setup that after running mvn -P developer -pl developer –Ddeploydb, my DB is still at 4.0 version, not expected 4.1 version. This is causing so much confusion to developers. We can only see our new schema introduced in 4.1 after we restart MS the first time. This is not the expected behavior for new fresh db creation change. The correct commit is already in master, we just need to cherry-pick them to 4.1, so I assigned this bug to you to cherry-pick those 2 commits from master to 4.1. Thanks -min Min - please see Rohit's comments in the bug.
Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
Oh, i see. That means that this issue is not only specific to dev environment, actually exists in QA environment as well. Basically QA cannot verify DB schema without starting MS once. I am consulting with Alex to see if we want to fix this in 4.1 or not. Thanks for clarification. Chip, please hold on this. -min On 3/20/13 11:20 AM, Rohit Yadav bhais...@apache.org wrote: For 4.1, you deploydb (that would be 4.0 schema), run mgmt server (dbupgradechecker should upgrade to 4.1). Starting 4.2, dbcreator would do that (like on master) and cloud-setup-databases should call dbcreator as well. I tried to refactor the tool and upgrade classes, that did not work smoothly for me so did not move refactor. Only making cloud-setup-databases use dbcreator is pending. Regards. On Wed, Mar 20, 2013 at 11:46 PM, John Burwell jburw...@basho.com wrote: Chip, Based on Rohit's comments, the blocking defect I raised may not be a bug. I will perform a rebuild tomorrow to determine if the template_s3_ref table gets created properly. Thanks, -John On Wed, Mar 20, 2013 at 2:13 PM, Chip Childers chip.child...@sungard.comwrote: On Wed, Mar 20, 2013 at 11:08:01AM -0700, Min Chen wrote: Hi Chip, I created this bug https://issues.apache.org/jira/browse/CLOUDSTACK-1747because I noticed yesterday in dev setup that after running mvn -P developer -pl developer Ddeploydb, my DB is still at 4.0 version, not expected 4.1 version. This is causing so much confusion to developers. We can only see our new schema introduced in 4.1 after we restart MS the first time. This is not the expected behavior for new fresh db creation change. The correct commit is already in master, we just need to cherry-pick them to 4.1, so I assigned this bug to you to cherry-pick those 2 commits from master to 4.1. Thanks -min Min - please see Rohit's comments in the bug.
Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
Chip, By reading Rohit's email and wiki, I understood current situation on this issue. Unlike I previously understood, this DB issue not only happens on dev environment, but also happens on QA/production environment as well. And this introduces a different behavior in 4.1 from previous 4.1 release. The commits mentioned in this bug will only fix dev environment, but to fix QA/productioin env, we need that pending feature (making cloud-setup-database use DatabaseCreator) to be done. We need community concensus whether we want to fix it in 4.1 or 4.2. Based on timeline, it may be wise to fix it in 4.2 and create a JIRA ticket to track this. If so, I still think that we need to file a doc bug to document this change in 4.1. Thanks -min On 3/20/13 11:24 AM, Min Chen min.c...@citrix.com wrote: Oh, i see. That means that this issue is not only specific to dev environment, actually exists in QA environment as well. Basically QA cannot verify DB schema without starting MS once. I am consulting with Alex to see if we want to fix this in 4.1 or not. Thanks for clarification. Chip, please hold on this. -min On 3/20/13 11:20 AM, Rohit Yadav bhais...@apache.org wrote: For 4.1, you deploydb (that would be 4.0 schema), run mgmt server (dbupgradechecker should upgrade to 4.1). Starting 4.2, dbcreator would do that (like on master) and cloud-setup-databases should call dbcreator as well. I tried to refactor the tool and upgrade classes, that did not work smoothly for me so did not move refactor. Only making cloud-setup-databases use dbcreator is pending. Regards. On Wed, Mar 20, 2013 at 11:46 PM, John Burwell jburw...@basho.com wrote: Chip, Based on Rohit's comments, the blocking defect I raised may not be a bug. I will perform a rebuild tomorrow to determine if the template_s3_ref table gets created properly. Thanks, -John On Wed, Mar 20, 2013 at 2:13 PM, Chip Childers chip.child...@sungard.comwrote: On Wed, Mar 20, 2013 at 11:08:01AM -0700, Min Chen wrote: Hi Chip, I created this bug https://issues.apache.org/jira/browse/CLOUDSTACK-1747because I noticed yesterday in dev setup that after running mvn -P developer -pl developer Ddeploydb, my DB is still at 4.0 version, not expected 4.1 version. This is causing so much confusion to developers. We can only see our new schema introduced in 4.1 after we restart MS the first time. This is not the expected behavior for new fresh db creation change. The correct commit is already in master, we just need to cherry-pick them to 4.1, so I assigned this bug to you to cherry-pick those 2 commits from master to 4.1. Thanks -min Min - please see Rohit's comments in the bug.
Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
Corrected a typo, I meant a different behavior in 4.1 from previous 4.0 release. Thanks -min On 3/20/13 11:43 AM, Min Chen min.c...@citrix.com wrote: Chip, By reading Rohit's email and wiki, I understood current situation on this issue. Unlike I previously understood, this DB issue not only happens on dev environment, but also happens on QA/production environment as well. And this introduces a different behavior in 4.1 from previous 4.1 release. The commits mentioned in this bug will only fix dev environment, but to fix QA/productioin env, we need that pending feature (making cloud-setup-database use DatabaseCreator) to be done. We need community concensus whether we want to fix it in 4.1 or 4.2. Based on timeline, it may be wise to fix it in 4.2 and create a JIRA ticket to track this. If so, I still think that we need to file a doc bug to document this change in 4.1. Thanks -min On 3/20/13 11:24 AM, Min Chen min.c...@citrix.com wrote: Oh, i see. That means that this issue is not only specific to dev environment, actually exists in QA environment as well. Basically QA cannot verify DB schema without starting MS once. I am consulting with Alex to see if we want to fix this in 4.1 or not. Thanks for clarification. Chip, please hold on this. -min On 3/20/13 11:20 AM, Rohit Yadav bhais...@apache.org wrote: For 4.1, you deploydb (that would be 4.0 schema), run mgmt server (dbupgradechecker should upgrade to 4.1). Starting 4.2, dbcreator would do that (like on master) and cloud-setup-databases should call dbcreator as well. I tried to refactor the tool and upgrade classes, that did not work smoothly for me so did not move refactor. Only making cloud-setup-databases use dbcreator is pending. Regards. On Wed, Mar 20, 2013 at 11:46 PM, John Burwell jburw...@basho.com wrote: Chip, Based on Rohit's comments, the blocking defect I raised may not be a bug. I will perform a rebuild tomorrow to determine if the template_s3_ref table gets created properly. Thanks, -John On Wed, Mar 20, 2013 at 2:13 PM, Chip Childers chip.child...@sungard.comwrote: On Wed, Mar 20, 2013 at 11:08:01AM -0700, Min Chen wrote: Hi Chip, I created this bug https://issues.apache.org/jira/browse/CLOUDSTACK-1747because I noticed yesterday in dev setup that after running mvn -P developer -pl developer Ddeploydb, my DB is still at 4.0 version, not expected 4.1 version. This is causing so much confusion to developers. We can only see our new schema introduced in 4.1 after we restart MS the first time. This is not the expected behavior for new fresh db creation change. The correct commit is already in master, we just need to cherry-pick them to 4.1, so I assigned this bug to you to cherry-pick those 2 commits from master to 4.1. Thanks -min Min - please see Rohit's comments in the bug.
Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
On Wed, Mar 20, 2013 at 11:43:30AM -0700, Min Chen wrote: Chip, By reading Rohit's email and wiki, I understood current situation on this issue. Unlike I previously understood, this DB issue not only happens on dev environment, but also happens on QA/production environment as well. And this introduces a different behavior in 4.1 from previous 4.1 release. The commits mentioned in this bug will only fix dev environment, but to fix QA/productioin env, we need that pending feature (making cloud-setup-database use DatabaseCreator) to be done. We need community concensus whether we want to fix it in 4.1 or 4.2. Based on timeline, it may be wise to fix it in 4.2 and create a JIRA ticket to track this. If so, I still think that we need to file a doc bug to document this change in 4.1. Is there no option for us to set the correct version for 4.1 during an upgrade / fresh install, based on the current approach used in the 4.1 branch?
RE: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
Hi everyone, We had a discussion on irc. To implement something intermediary will be around the same effort as finishing the job and there are various reasons why just running the create-schema.sql and update*.sql is not enough. So we should just decide on finishing the job in 4.1 or document the behavior. Any input on which way we should take. The engineer in me says just finish the job. It's obviously working in dev setup on master so the risk of this introducing bugs is very low. If someone knows why it's difficult to change in cloud-setup-databases script, please speak up. --Alex -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Wednesday, March 20, 2013 12:39 PM To: cloudstack-dev@incubator.apache.org Subject: Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry- pick commits from master On Wed, Mar 20, 2013 at 11:43:30AM -0700, Min Chen wrote: Chip, By reading Rohit's email and wiki, I understood current situation on this issue. Unlike I previously understood, this DB issue not only happens on dev environment, but also happens on QA/production environment as well. And this introduces a different behavior in 4.1 from previous 4.1 release. The commits mentioned in this bug will only fix dev environment, but to fix QA/productioin env, we need that pending feature (making cloud-setup-database use DatabaseCreator) to be done. We need community concensus whether we want to fix it in 4.1 or 4.2. Based on timeline, it may be wise to fix it in 4.2 and create a JIRA ticket to track this. If so, I still think that we need to file a doc bug to document this change in 4.1. Is there no option for us to set the correct version for 4.1 during an upgrade / fresh install, based on the current approach used in the 4.1 branch?
Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
Alex, Given that we are 3 business days to the RC1 deadline, it seems to me that we should pursue to lowest risk path possible. To my mind, that would be reverting to the 4.0 behavior. Is there a way to revert to the previous behavior for 4.1 and defer the entire enhancement to 4.2? Based on the mailing list discussion, it appears that this change was introduced after the 31 Jan 2013 code freeze. If my understanding of the history correct, I think there is broader issue we need to work out as community -- how/why did this feature get merged post-freeze? Thanks, -John On Mar 20, 2013, at 4:24 PM, Alex Huang alex.hu...@citrix.com wrote: Hi everyone, We had a discussion on irc. To implement something intermediary will be around the same effort as finishing the job and there are various reasons why just running the create-schema.sql and update*.sql is not enough. So we should just decide on finishing the job in 4.1 or document the behavior. Any input on which way we should take. The engineer in me says just finish the job. It's obviously working in dev setup on master so the risk of this introducing bugs is very low. If someone knows why it's difficult to change in cloud-setup-databases script, please speak up. --Alex -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Wednesday, March 20, 2013 12:39 PM To: cloudstack-dev@incubator.apache.org Subject: Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry- pick commits from master On Wed, Mar 20, 2013 at 11:43:30AM -0700, Min Chen wrote: Chip, By reading Rohit's email and wiki, I understood current situation on this issue. Unlike I previously understood, this DB issue not only happens on dev environment, but also happens on QA/production environment as well. And this introduces a different behavior in 4.1 from previous 4.1 release. The commits mentioned in this bug will only fix dev environment, but to fix QA/productioin env, we need that pending feature (making cloud-setup-database use DatabaseCreator) to be done. We need community concensus whether we want to fix it in 4.1 or 4.2. Based on timeline, it may be wise to fix it in 4.2 and create a JIRA ticket to track this. If so, I still think that we need to file a doc bug to document this change in 4.1. Is there no option for us to set the correct version for 4.1 during an upgrade / fresh install, based on the current approach used in the 4.1 branch?
Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
On Wed, Mar 20, 2013 at 4:24 PM, Alex Huang alex.hu...@citrix.com wrote: Hi everyone, We had a discussion on irc. To implement something intermediary will be around the same effort as finishing the job and there are various reasons why just running the create-schema.sql and update*.sql is not enough. So we should just decide on finishing the job in 4.1 or document the behavior. Any input on which way we should take. The engineer in me says just finish the job. It's obviously working in dev setup on master so the risk of this introducing bugs is very low. If someone knows why it's difficult to change in cloud-setup-databases script, please speak up. --Alex My take on this is that we shouldn't do anything to 4.1 The people that matter (users) are taken care of when they start the MS - and that is a well-tested path. The only visible benefit for 4.1 is for developers/QA - and while I want everyone's life to be as easy as possible - last minute changes to help folks in a branch that's already feature frozen and days away from RC doesn't seem like the wisest path. --David
RE: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
John, The code was in before deadline. I think you're looking at a commit where Rohit tried to fix a problem with the developer deploy in the pom.xml. I had previously thought even though the developer deploy had problems, the production deploy was actually working. Turns out it wasn't. --Alex -Original Message- From: John Burwell [mailto:jburw...@basho.com] Sent: Wednesday, March 20, 2013 1:32 PM To: cloudstack-dev@incubator.apache.org Subject: Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry- pick commits from master Alex, Given that we are 3 business days to the RC1 deadline, it seems to me that we should pursue to lowest risk path possible. To my mind, that would be reverting to the 4.0 behavior. Is there a way to revert to the previous behavior for 4.1 and defer the entire enhancement to 4.2? Based on the mailing list discussion, it appears that this change was introduced after the 31 Jan 2013 code freeze. If my understanding of the history correct, I think there is broader issue we need to work out as community -- how/why did this feature get merged post-freeze? Thanks, -John On Mar 20, 2013, at 4:24 PM, Alex Huang alex.hu...@citrix.com wrote: Hi everyone, We had a discussion on irc. To implement something intermediary will be around the same effort as finishing the job and there are various reasons why just running the create- schema.sql and update*.sql is not enough. So we should just decide on finishing the job in 4.1 or document the behavior. Any input on which way we should take. The engineer in me says just finish the job. It's obviously working in dev setup on master so the risk of this introducing bugs is very low. If someone knows why it's difficult to change in cloud-setup-databases script, please speak up. --Alex -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Wednesday, March 20, 2013 12:39 PM To: cloudstack-dev@incubator.apache.org Subject: Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry- pick commits from master On Wed, Mar 20, 2013 at 11:43:30AM -0700, Min Chen wrote: Chip, By reading Rohit's email and wiki, I understood current situation on this issue. Unlike I previously understood, this DB issue not only happens on dev environment, but also happens on QA/production environment as well. And this introduces a different behavior in 4.1 from previous 4.1 release. The commits mentioned in this bug will only fix dev environment, but to fix QA/productioin env, we need that pending feature (making cloud-setup-database use DatabaseCreator) to be done. We need community concensus whether we want to fix it in 4.1 or 4.2. Based on timeline, it may be wise to fix it in 4.2 and create a JIRA ticket to track this. If so, I still think that we need to file a doc bug to document this change in 4.1. Is there no option for us to set the correct version for 4.1 during an upgrade / fresh install, based on the current approach used in the 4.1 branch?
RE: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
My take on this is that we shouldn't do anything to 4.1 The people that matter (users) are taken care of when they start the MS - and that is a well- tested path. The only visible benefit for 4.1 is for developers/QA - and while I want everyone's life to be as easy as possible - last minute changes to help folks in a branch that's already feature frozen and days away from RC doesn't seem like the wisest path. Then we should document for the benefit of the end users in case they were comparing the schema to 4.0 schema. --Alex
Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
On Wed, Mar 20, 2013 at 02:23:33PM -0700, Alex Huang wrote: My take on this is that we shouldn't do anything to 4.1 The people that matter (users) are taken care of when they start the MS - and that is a well- tested path. The only visible benefit for 4.1 is for developers/QA - and while I want everyone's life to be as easy as possible - last minute changes to help folks in a branch that's already feature frozen and days away from RC doesn't seem like the wisest path. Then we should document for the benefit of the end users in case they were comparing the schema to 4.0 schema. --Alex Suggested wording? Probably belongs in the release notes.
RE: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
How does this sound? CloudStack's database is created using the 4.0 schema and updated to the 4.1 schema when the management server starts for the first time. It is fine to see the same schema as 4.0 if the management server has not started yet. --Alex -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Wednesday, March 20, 2013 6:28 PM To: cloudstack-dev@incubator.apache.org Subject: Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry- pick commits from master On Wed, Mar 20, 2013 at 02:23:33PM -0700, Alex Huang wrote: My take on this is that we shouldn't do anything to 4.1 The people that matter (users) are taken care of when they start the MS - and that is a well- tested path. The only visible benefit for 4.1 is for developers/QA - and while I want everyone's life to be as easy as possible - last minute changes to help folks in a branch that's already feature frozen and days away from RC doesn't seem like the wisest path. Then we should document for the benefit of the end users in case they were comparing the schema to 4.0 schema. --Alex Suggested wording? Probably belongs in the release notes.
