I don't understand why this is a problem. >From a systems perspective there is only one (correct) timezone. Actually using timezones, especially in a geographically distributed cloud is problematic.
--David On Sun, Jun 30, 2013 at 11:27 PM, Ryan Lei <ryan...@cht.com.tw> wrote: > Great. Both the OSS and non-OSS builds fine on the 4.1 branch now! Tested > on OS X 10.6.8 and CentOS 6.3. > > But here's another flaw in DB upgrade: > The upgrade writes the timestamp in UTC+0 time zone in MySQL (in 4.1, 4.2, > master): > > [4.1] mysql> select * from version; > +----+---------+---------------------+----------+ > | id | version | updated | step | > +----+---------+---------------------+----------+ > | 1 | 4.0.0 | 2013-07-01 10:05:24 | Complete | > | 2 | 4.1.0 | 2013-07-01 02:18:36 | Complete | > | 3 | 4.1.1 | 2013-07-01 02:18:36 | Complete | > +----+---------+---------------------+----------+ > > [4.2] mysql> select * from version; > +----+---------+---------------------+----------+ > | id | version | updated | step | > +----+---------+---------------------+----------+ > | 1 | 4.0.0 | 2013-07-01 10:38:22 | Complete | > | 2 | 4.1.0 | 2013-07-01 02:41:17 | Complete | > | 3 | 4.2.0 | 2013-07-01 02:41:18 | Complete | > +----+---------+---------------------+----------+ > > My time zone is CST (UTC+8). The correct time should be 2013-07-01 10:xx:xx. > > mysql> SELECT NOW(); reports the correct time, so I guess the problem is on > the Java (JDBC?) side. > > > ------------------------------------------------------------------------------------------- > Yu-Heng (Ryan) Lei, Associate Reasearcher > Chunghwa Telecom Laboratories / Cloud Computing Laboratory > ryan...@cht.com.tw<https://email.cht.com.tw/owa/redir.aspx?C=-wE1FEC3G0SWYpVkiWo8SsDdf3ZqO9AIuAPTzRnFYCUi-z4YljtI_hyVKkNHfn9F1Bn-vUWJnQ4.&URL=mailto%3aryanlei%40cht.com.tw> > or > ryanlei750...@gmail.com > > > > On Sat, Jun 29, 2013 at 1:59 AM, Hugo Trippaers <h...@trippaers.nl> wrote: > >> Hello :-) >> >> Nice find! >> >> I've pushed this commit to the branch: >> >> commit b330f2aa909d7ddc387863e0806f71964f6d5f80 >> Author: Hugo Trippaers <htrippa...@schubergphilis.com> >> Date: Fri Jun 28 10:57:51 2013 -0700 >> >> CLOUDSTACK-3278 Add the 410 to 411 upgrade to the >> PremiumDatabaseUpgradeChecker >> >> Can you verify if this fixes your problem? >> >> >> Cheers, >> >> Hugo >> >> On Jun 28, 2013, at 10:39 AM, Ryan Lei <ryan...@cht.com.tw> wrote: >> >> > Actually, the errors happen only in non-OSS build with git 4.1 >> > (4.1.1-SNAPSHOT). >> > >> > OSS build with git 4.1 and non-OSS build with 4.1.0 source code work >> fine. >> > They are able to run the Upgrade40to41 or Upgrade410to411. >> > >> > I have created a JIRA ticket for this issue: >> > https://issues.apache.org/jira/browse/CLOUDSTACK-3278 >> > >> > >> ------------------------------------------------------------------------------------------- >> > Yu-Heng (Ryan) Lei, Associate Reasearcher >> > Chunghwa Telecom Laboratories / Cloud Computing Laboratory >> > ryan...@cht.com.tw< >> https://email.cht.com.tw/owa/redir.aspx?C=-wE1FEC3G0SWYpVkiWo8SsDdf3ZqO9AIuAPTzRnFYCUi-z4YljtI_hyVKkNHfn9F1Bn-vUWJnQ4.&URL=mailto%3aryanlei%40cht.com.tw >> > >> > or >> > ryanlei750...@gmail.com >> > >> > >> > >> > On Fri, Jun 28, 2013 at 4:42 PM, Ryan Lei <ryan...@cht.com.tw> wrote: >> > >> >> Hi all, >> >> I was trying to use the git 4.1 branch to run non-OSS CloudStack from >> >> source. My commands were: >> >> >> >> (1) Put the neccessary jars in deps >> >> (2) Run deps/install-non-oss.sh with success >> >> (3) $ mvn clean install -DskipTests=true -Dnonoss >> >> (4) $ mvn -P developer -pl developer -Ddeploydb >> >> (5) $ mvn -pl :cloud-client-ui jetty:run >> >> >> >> Then I got these DB version errors which made the jetty quit: >> >> INFO [utils.component.ComponentContext] (Timer-2:) Running >> >> SystemIntegrityChecker encryptionSecretKeyChecker >> >> INFO [utils.component.ComponentContext] (Timer-2:) Running >> >> SystemIntegrityChecker databaseIntegrityChecker >> >> INFO [cloud.upgrade.DatabaseIntegrityChecker] (Timer-2:) Grabbing lock >> to >> >> check for database integrity. >> >> INFO [cloud.upgrade.DatabaseIntegrityChecker] (Timer-2:) Performing >> >> database integrity check >> >> INFO [utils.component.ComponentContext] (Timer-2:) Running >> >> SystemIntegrityChecker managementServerNode >> >> INFO [utils.component.ComponentContext] (Timer-2:) Running >> >> SystemIntegrityChecker premiumDatabaseUpgradeChecker >> >> INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) Grabbing lock to >> >> check for database upgrade. >> >> INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) DB version = >> 4.0.0 >> >> Code Version = 4.1.1-SNAPSHOT >> >> INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) Database upgrade >> >> must be performed from 4.0.0 to 4.1.1-SNAPSHOT >> >> ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) The end upgrade >> >> version is actually at 4.1.0 but our management server code version is >> at >> >> 4.1.1-SNAPSHOT >> >> ERROR [utils.component.ComponentContext] (Timer-2:) System integrity >> check >> >> failed. Refuse to startup >> >> >> >> >> >> In MySQL, I found the table in 'version' has only one entry whose value >> is >> >> 4.0.0. >> >> Manually modifying the value to 4.1.1 led to other exceptions. Looks >> like >> >> 4.1 git "forgets" to upgrade the database. >> >> >> >> Is this a bug in the current 4.1 branch? >> >> >> >> >> >> >> ------------------------------------------------------------------------------------------- >> >> Yu-Heng (Ryan) Lei, Associate Reasearcher >> >> Chunghwa Telecom Laboratories / Cloud Computing Laboratory >> >> ryan...@cht.com.tw< >> https://email.cht.com.tw/owa/redir.aspx?C=-wE1FEC3G0SWYpVkiWo8SsDdf3ZqO9AIuAPTzRnFYCUi-z4YljtI_hyVKkNHfn9F1Bn-vUWJnQ4.&URL=mailto%3aryanlei%40cht.com.tw> >> or >> >> ryanlei750...@gmail.com >> >> >> >> >> >>
