Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
All, we will be crafting RC2 release with 2 minor patches (will explain more in the RC2 voting thread), so please keep your vote for the RC2 and let's stop the voting process for RC1. Anyone testing RC1 is NOT expected / not mandatory to retest anything on RC2, except those 2 patches (to be explained) IF they affect you. Thanks Andrija On Wed, 6 May 2020 at 11:25, Andrija Panic wrote: > Thanks Liridon. > > p.s. as for the usage server - the first run after you change things will > not run (not owner of job, etc), but you can hack that (which is what I've > done, as it seems it was successful), assuming there is only a single usage > server in your test env. > - after restarting the usage-server, check it's PID, and then edit the > last records in the cloud_usage.usage_job tablw to have the new PID and not > the PID of the previous usage job process. > - then next run will actually really run (instead of being skipped, that > one) > > Regards, > Andrija > > On Wed, 6 May 2020 at 09:17, Ismaili, Liridon (SWISS TXT) < > liridon.isma...@swisstxt.ch> wrote: > >> Hi Andrija & Daan >> >> @Daan I tried that out but without success. However the service seems to >> be recovered and did run successful. The dates inside the DB are in UTC >> format but when I list entries from the usage or cloud DB with CloudMonkey >> I get CEST results. >> (the GUI did still show me UTC values in the Events but that's may caused >> by my environment). >> >> @Andrija: I would say that it looks good. I also testet the parameters >> with "Europe/Zurich" but made no difference to me. >> >> Regards >> Liridon >> >> -Original Message- >> From: Andrija Panic > andrija%20panic%20%3candrija.pa...@gmail.com%3e>> >> Reply-To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> >> To: us...@cloudstack.apache.org > 22us...@cloudstack.apache.org%22%20%3cus...@cloudstack.apache.org%3e>>, >> dev mailto:dev%20%3c...@cloudstack.apache.org >> %3e>> >> Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 >> Date: Tue, 05 May 2020 19:11:14 +0200 >> >> >> Hi Liridon, >> >> >> do you have any feedback about the usage records timing/time zone and >> such? >> >> >> Thanks >> >> Andrija >> >> >> On Mon, 4 May 2020 at 14:32, Daan Hoogland < >> >> <mailto:daan.hoogl...@gmail.com> >> >> daan.hoogl...@gmail.com >> >> > wrote: >> >> >> Liridon, >> >> "Not owner of usage job, skipping" means there is a PID in the record for >> >> this job that isn't the current process. If recognise this and have >> >> remedied by setting the process id to null in the record. I'm sure there >> is >> >> some underlying issue that you hit though. Just a workaround. >> >> >> On Mon, May 4, 2020 at 12:56 PM Ismaili, Liridon (SWISS TXT) < >> >> <mailto:liridon.isma...@swisstxt.ch> >> >> liridon.isma...@swisstxt.ch >> >> > wrote: >> >> >> Hi Rohit >> >> >> I tried so and did configure the usage to run 12:45 so I can monitor the >> >> behavior. I got the following output: >> >> 2020-05-04 12:45:00,002 INFO [cloud.usage.UsageManagerImpl] >> >> (Usage-Job-1:null) (logid:) starting usage job... >> >> 2020-05-04 12:45:00,015 DEBUG [cloud.usage.UsageManagerImpl] >> >> (Usage-Job-1:null) (logid:) Not owner of usage job, skipping... >> >> 2020-05-04 12:45:00,015 INFO [cloud.usage.UsageManagerImpl] >> >> (Usage-Job-1:null) (logid:) usage job complete >> >> >> So the job did not run for some reason... I'm still looking into this. So >> >> currently I can't confirm but will update you later as soon as the usage >> >> job did run. >> >> >> Regards >> >> Liridon >> >> -Original Message- >> >> From: Rohit Yadav < >> >> <mailto:rohit.ya...@shapeblue.com> >> >> rohit.ya...@shapeblue.com >> >> > >> <mailto:rohit%20yadav%20%3crohit.ya...@shapeblue.com> >> >> rohit%20yadav%20%3crohit.ya...@shapeblue.com >> >> %3e>> >> >> Reply-To: >> >> <mailto:us...@cloudstack.apache.org> >> >> us...@cloudstack.apache.org >> >> > >> <mailto:us...@cloudstack.apache.org> >> >> us...@cloudstack.apache.org >> >> > >> >> To: &g
Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Thanks Liridon. p.s. as for the usage server - the first run after you change things will not run (not owner of job, etc), but you can hack that (which is what I've done, as it seems it was successful), assuming there is only a single usage server in your test env. - after restarting the usage-server, check it's PID, and then edit the last records in the cloud_usage.usage_job tablw to have the new PID and not the PID of the previous usage job process. - then next run will actually really run (instead of being skipped, that one) Regards, Andrija On Wed, 6 May 2020 at 09:17, Ismaili, Liridon (SWISS TXT) < liridon.isma...@swisstxt.ch> wrote: > Hi Andrija & Daan > > @Daan I tried that out but without success. However the service seems to > be recovered and did run successful. The dates inside the DB are in UTC > format but when I list entries from the usage or cloud DB with CloudMonkey > I get CEST results. > (the GUI did still show me UTC values in the Events but that's may caused > by my environment). > > @Andrija: I would say that it looks good. I also testet the parameters > with "Europe/Zurich" but made no difference to me. > > Regards > Liridon > > -Original Message- > From: Andrija Panic andrija%20panic%20%3candrija.pa...@gmail.com%3e>> > Reply-To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> > To: us...@cloudstack.apache.org 22us...@cloudstack.apache.org%22%20%3cus...@cloudstack.apache.org%3e>>, > dev mailto:dev%20%3c...@cloudstack.apache.org > %3e>> > Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 > Date: Tue, 05 May 2020 19:11:14 +0200 > > > Hi Liridon, > > > do you have any feedback about the usage records timing/time zone and such? > > > Thanks > > Andrija > > > On Mon, 4 May 2020 at 14:32, Daan Hoogland < > > <mailto:daan.hoogl...@gmail.com> > > daan.hoogl...@gmail.com > > > wrote: > > > Liridon, > > "Not owner of usage job, skipping" means there is a PID in the record for > > this job that isn't the current process. If recognise this and have > > remedied by setting the process id to null in the record. I'm sure there is > > some underlying issue that you hit though. Just a workaround. > > > On Mon, May 4, 2020 at 12:56 PM Ismaili, Liridon (SWISS TXT) < > > <mailto:liridon.isma...@swisstxt.ch> > > liridon.isma...@swisstxt.ch > > > wrote: > > > Hi Rohit > > > I tried so and did configure the usage to run 12:45 so I can monitor the > > behavior. I got the following output: > > 2020-05-04 12:45:00,002 INFO [cloud.usage.UsageManagerImpl] > > (Usage-Job-1:null) (logid:) starting usage job... > > 2020-05-04 12:45:00,015 DEBUG [cloud.usage.UsageManagerImpl] > > (Usage-Job-1:null) (logid:) Not owner of usage job, skipping... > > 2020-05-04 12:45:00,015 INFO [cloud.usage.UsageManagerImpl] > > (Usage-Job-1:null) (logid:) usage job complete > > > So the job did not run for some reason... I'm still looking into this. So > > currently I can't confirm but will update you later as soon as the usage > > job did run. > > > Regards > > Liridon > > -Original Message- > > From: Rohit Yadav < > > <mailto:rohit.ya...@shapeblue.com> > > rohit.ya...@shapeblue.com > > > <mailto:rohit%20yadav%20%3crohit.ya...@shapeblue.com> > > rohit%20yadav%20%3crohit.ya...@shapeblue.com > > %3e>> > > Reply-To: > > <mailto:us...@cloudstack.apache.org> > > us...@cloudstack.apache.org > > > <mailto:us...@cloudstack.apache.org> > > us...@cloudstack.apache.org > > > > > To: > > <mailto:dev@cloudstack.apache.org> > > dev@cloudstack.apache.org > > < > > <mailto:dev@cloudstack.apache.org> > > dev@cloudstack.apache.org > > > <mailto:22...@cloudstack.apache.org> > > 22...@cloudstack.apache.org > > <mailto:%22%20%3c...@cloudstack.apache.org> > > %22%20%3c...@cloudstack.apache.org > > %3e>>, > > <mailto:andrija.pa...@gmail.com> > > andrija.pa...@gmail.com > > < > > <mailto:andrija.pa...@gmail.com> > > andrija.pa...@gmail.com > > > <mailto:22andrija.pa...@gmail.com> > > 22andrija.pa...@gmail.com > > <mailto:%22%20%3candrija.pa...@gmail.com> > > %22%20%3candrija.pa...@gmail.com > > %3e>>, > > <mailto:us...@cloudstack.apache.org> > > us...@cloudstack.apache.org > > < > > <mailto:us...@cloudstack.apache.org> > > us...@cloudstack.apache.org > > &g
Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Hi Andrija & Daan @Daan I tried that out but without success. However the service seems to be recovered and did run successful. The dates inside the DB are in UTC format but when I list entries from the usage or cloud DB with CloudMonkey I get CEST results. (the GUI did still show me UTC values in the Events but that's may caused by my environment). @Andrija: I would say that it looks good. I also testet the parameters with "Europe/Zurich" but made no difference to me. Regards Liridon -Original Message- From: Andrija Panic mailto:andrija%20panic%20%3candrija.pa...@gmail.com%3e>> Reply-To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> To: us...@cloudstack.apache.org mailto:%22us...@cloudstack.apache.org%22%20%3cus...@cloudstack.apache.org%3e>>, dev mailto:dev%20%3c...@cloudstack.apache.org%3e>> Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 Date: Tue, 05 May 2020 19:11:14 +0200 Hi Liridon, do you have any feedback about the usage records timing/time zone and such? Thanks Andrija On Mon, 4 May 2020 at 14:32, Daan Hoogland < <mailto:daan.hoogl...@gmail.com> daan.hoogl...@gmail.com > wrote: Liridon, "Not owner of usage job, skipping" means there is a PID in the record for this job that isn't the current process. If recognise this and have remedied by setting the process id to null in the record. I'm sure there is some underlying issue that you hit though. Just a workaround. On Mon, May 4, 2020 at 12:56 PM Ismaili, Liridon (SWISS TXT) < <mailto:liridon.isma...@swisstxt.ch> liridon.isma...@swisstxt.ch > wrote: Hi Rohit I tried so and did configure the usage to run 12:45 so I can monitor the behavior. I got the following output: 2020-05-04 12:45:00,002 INFO [cloud.usage.UsageManagerImpl] (Usage-Job-1:null) (logid:) starting usage job... 2020-05-04 12:45:00,015 DEBUG [cloud.usage.UsageManagerImpl] (Usage-Job-1:null) (logid:) Not owner of usage job, skipping... 2020-05-04 12:45:00,015 INFO [cloud.usage.UsageManagerImpl] (Usage-Job-1:null) (logid:) usage job complete So the job did not run for some reason... I'm still looking into this. So currently I can't confirm but will update you later as soon as the usage job did run. Regards Liridon -Original Message- From: Rohit Yadav < <mailto:rohit.ya...@shapeblue.com> rohit.ya...@shapeblue.com mailto:rohit%20yadav%20%3crohit.ya...@shapeblue.com> rohit%20yadav%20%3crohit.ya...@shapeblue.com %3e>> Reply-To: <mailto:us...@cloudstack.apache.org> us...@cloudstack.apache.org mailto:us...@cloudstack.apache.org> us...@cloudstack.apache.org > To: <mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org < <mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org mailto:22...@cloudstack.apache.org> 22...@cloudstack.apache.org <mailto:%22%20%3c...@cloudstack.apache.org> %22%20%3c...@cloudstack.apache.org %3e>>, <mailto:andrija.pa...@gmail.com> andrija.pa...@gmail.com < <mailto:andrija.pa...@gmail.com> andrija.pa...@gmail.com mailto:22andrija.pa...@gmail.com> 22andrija.pa...@gmail.com <mailto:%22%20%3candrija.pa...@gmail.com> %22%20%3candrija.pa...@gmail.com %3e>>, <mailto:us...@cloudstack.apache.org> us...@cloudstack.apache.org < <mailto:us...@cloudstack.apache.org> us...@cloudstack.apache.org mailto:22us...@cloudstack.apache.org> 22us...@cloudstack.apache.org <mailto:%22%20%3cus...@cloudstack.apache.org> %22%20%3cus...@cloudstack.apache.org %3e>> Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 Date: Mon, 04 May 2020 10:16:51 + Thanks for testing and sharing your results Liridon! Can you also test the case if the usage records have the correct time according to configured timezone (in global settings) if you're using a non-UTC timezone? I'll add the db.usage.url.paramsl as well in the PR. Regards, Rohit Yadav Software Architect, ShapeBlue < <https://www.shapeblue.com> https://www.shapeblue.com > <https://www.shapeblue.com> https://www.shapeblue.com From: Ismaili, Liridon (SWISS TXT) < mailto:liridon.isma...@swisstxt.ch> liridon.isma...@swisstxt.ch > <mailto:liridon.isma...@swisstxt.ch> liridon.isma...@swisstxt.ch Sent: Monday, May 4, 2020 15:38 To: mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org > <mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org < mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org > <mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org ; mailto:andrija.pa...@gmail.com> andrija.pa...@gmail.com > <mailto:andrija.pa...@gmail.com> andrija.pa...@gmail.com < mailto:a
Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Hi Liridon, do you have any feedback about the usage records timing/time zone and such? Thanks Andrija On Mon, 4 May 2020 at 14:32, Daan Hoogland wrote: > Liridon, > "Not owner of usage job, skipping" means there is a PID in the record for > this job that isn't the current process. If recognise this and have > remedied by setting the process id to null in the record. I'm sure there is > some underlying issue that you hit though. Just a workaround. > > On Mon, May 4, 2020 at 12:56 PM Ismaili, Liridon (SWISS TXT) < > liridon.isma...@swisstxt.ch> wrote: > >> Hi Rohit >> >> I tried so and did configure the usage to run 12:45 so I can monitor the >> behavior. I got the following output: >> 2020-05-04 12:45:00,002 INFO [cloud.usage.UsageManagerImpl] >> (Usage-Job-1:null) (logid:) starting usage job... >> 2020-05-04 12:45:00,015 DEBUG [cloud.usage.UsageManagerImpl] >> (Usage-Job-1:null) (logid:) Not owner of usage job, skipping... >> 2020-05-04 12:45:00,015 INFO [cloud.usage.UsageManagerImpl] >> (Usage-Job-1:null) (logid:) usage job complete >> >> So the job did not run for some reason... I'm still looking into this. So >> currently I can't confirm but will update you later as soon as the usage >> job did run. >> >> Regards >> Liridon >> -Original Message- >> From: Rohit Yadav > rohit%20yadav%20%3crohit.ya...@shapeblue.com%3e>> >> Reply-To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org> >> To: dev@cloudstack.apache.org > 22...@cloudstack.apache.org%22%20%3c...@cloudstack.apache.org%3e>>, >> andrija.pa...@gmail.com > 22andrija.pa...@gmail.com%22%20%3candrija.pa...@gmail.com%3e>>, >> us...@cloudstack.apache.org > 22us...@cloudstack.apache.org%22%20%3cus...@cloudstack.apache.org%3e>> >> Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 >> Date: Mon, 04 May 2020 10:16:51 + >> >> >> Thanks for testing and sharing your results Liridon! >> >> >> Can you also test the case if the usage records have the correct time >> according to configured timezone (in global settings) if you're using a >> non-UTC timezone? >> >> >> I'll add the db.usage.url.paramsl as well in the PR. >> >> >> >> Regards, >> >> >> Rohit Yadav >> >> >> Software Architect, ShapeBlue >> >> >> <https://www.shapeblue.com> >> >> https://www.shapeblue.com >> >> >> >> >> >> From: Ismaili, Liridon (SWISS TXT) < >> >> <mailto:liridon.isma...@swisstxt.ch> >> >> liridon.isma...@swisstxt.ch >> >> > >> >> Sent: Monday, May 4, 2020 15:38 >> >> To: >> >> <mailto:dev@cloudstack.apache.org> >> >> dev@cloudstack.apache.org >> >> < >> >> <mailto:dev@cloudstack.apache.org> >> >> dev@cloudstack.apache.org >> >> >; >> >> <mailto:andrija.pa...@gmail.com> >> >> andrija.pa...@gmail.com >> >> < >> >> <mailto:andrija.pa...@gmail.com> >> >> andrija.pa...@gmail.com >> >> >; >> >> <mailto:us...@cloudstack.apache.org> >> >> us...@cloudstack.apache.org >> >> < >> >> <mailto:us...@cloudstack.apache.org> >> >> us...@cloudstack.apache.org >> >> > >> >> Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 >> >> >> Hi Rohit >> >> >> That did the trick! I did remove all the timezone information on my.cnf >> and only added the timezone information on the db.properties file. >> >> So I can confirm it fixes the issue. >> >> >> If you are using the usage service too you will also need to specify the >> timezone information for the usage DB: >> >> "db.usage.url.params=" in the /etc/cloudstack/management/db.properties >> file. Otherwise the usage service won't be able to start. >> >> >> This did also fix my issue and all my dates inside the db are now in the >> correct time zone! I'll also update the Github PR so we can track it there. >> >> >> Many thanks and Regards >> >> Liridon >> >> >> <mailto:rohit.ya...@shapeblue.com> >> >> rohit.ya...@shapeblue.com >> >> >> >> <http://www.shapeblue.com> >> >> www.shapeblue.com >> >> >> 3 London Bridge Street, 3rd fl
Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Liridon, "Not owner of usage job, skipping" means there is a PID in the record for this job that isn't the current process. If recognise this and have remedied by setting the process id to null in the record. I'm sure there is some underlying issue that you hit though. Just a workaround. On Mon, May 4, 2020 at 12:56 PM Ismaili, Liridon (SWISS TXT) < liridon.isma...@swisstxt.ch> wrote: > Hi Rohit > > I tried so and did configure the usage to run 12:45 so I can monitor the > behavior. I got the following output: > 2020-05-04 12:45:00,002 INFO [cloud.usage.UsageManagerImpl] > (Usage-Job-1:null) (logid:) starting usage job... > 2020-05-04 12:45:00,015 DEBUG [cloud.usage.UsageManagerImpl] > (Usage-Job-1:null) (logid:) Not owner of usage job, skipping... > 2020-05-04 12:45:00,015 INFO [cloud.usage.UsageManagerImpl] > (Usage-Job-1:null) (logid:) usage job complete > > So the job did not run for some reason... I'm still looking into this. So > currently I can't confirm but will update you later as soon as the usage > job did run. > > Regards > Liridon > -Original Message- > From: Rohit Yadav rohit%20yadav%20%3crohit.ya...@shapeblue.com%3e>> > Reply-To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org> > To: dev@cloudstack.apache.org 22...@cloudstack.apache.org%22%20%3c...@cloudstack.apache.org%3e>>, > andrija.pa...@gmail.com 22andrija.pa...@gmail.com%22%20%3candrija.pa...@gmail.com%3e>>, > us...@cloudstack.apache.org 22us...@cloudstack.apache.org%22%20%3cus...@cloudstack.apache.org%3e>> > Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 > Date: Mon, 04 May 2020 10:16:51 + > > > Thanks for testing and sharing your results Liridon! > > > Can you also test the case if the usage records have the correct time > according to configured timezone (in global settings) if you're using a > non-UTC timezone? > > > I'll add the db.usage.url.paramsl as well in the PR. > > > > Regards, > > > Rohit Yadav > > > Software Architect, ShapeBlue > > > <https://www.shapeblue.com> > > https://www.shapeblue.com > > > > > > From: Ismaili, Liridon (SWISS TXT) < > > <mailto:liridon.isma...@swisstxt.ch> > > liridon.isma...@swisstxt.ch > > > > > Sent: Monday, May 4, 2020 15:38 > > To: > > <mailto:dev@cloudstack.apache.org> > > dev@cloudstack.apache.org > > < > > <mailto:dev@cloudstack.apache.org> > > dev@cloudstack.apache.org > > >; > > <mailto:andrija.pa...@gmail.com> > > andrija.pa...@gmail.com > > < > > <mailto:andrija.pa...@gmail.com> > > andrija.pa...@gmail.com > > >; > > <mailto:us...@cloudstack.apache.org> > > us...@cloudstack.apache.org > > < > > <mailto:us...@cloudstack.apache.org> > > us...@cloudstack.apache.org > > > > > Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 > > > Hi Rohit > > > That did the trick! I did remove all the timezone information on my.cnf > and only added the timezone information on the db.properties file. > > So I can confirm it fixes the issue. > > > If you are using the usage service too you will also need to specify the > timezone information for the usage DB: > > "db.usage.url.params=" in the /etc/cloudstack/management/db.properties > file. Otherwise the usage service won't be able to start. > > > This did also fix my issue and all my dates inside the db are now in the > correct time zone! I'll also update the Github PR so we can track it there. > > > Many thanks and Regards > > Liridon > > > <mailto:rohit.ya...@shapeblue.com> > > rohit.ya...@shapeblue.com > > > > <http://www.shapeblue.com> > > www.shapeblue.com > > > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK > > @shapeblue > > > > > > > > -Original Message- > > From: "Ismaili, Liridon (SWISS TXT)" < > > <mailto:liridon.isma...@swisstxt.ch> > > liridon.isma...@swisstxt.ch > > <mailto:%22Ismaili, > > <mailto:%20liridon%20%28swiss%20txt%29%22%20%3cliridon.isma...@swisstxt.ch > > > > %20liridon%20%28swiss%20txt%29%22%20%3cliridon.isma...@swisstxt.ch > > %3e>> > > Reply-To: > > <mailto:us...@cloudstack.apache.org> > > us...@cloudstack.apache.org > > > <mailto:us...@cloudstack.apache.org> > > us...@cloudstack.apache.org > > > > > To: > > <mailto:dev@cloudstack.apache.
Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Hi Rohit I tried so and did configure the usage to run 12:45 so I can monitor the behavior. I got the following output: 2020-05-04 12:45:00,002 INFO [cloud.usage.UsageManagerImpl] (Usage-Job-1:null) (logid:) starting usage job... 2020-05-04 12:45:00,015 DEBUG [cloud.usage.UsageManagerImpl] (Usage-Job-1:null) (logid:) Not owner of usage job, skipping... 2020-05-04 12:45:00,015 INFO [cloud.usage.UsageManagerImpl] (Usage-Job-1:null) (logid:) usage job complete So the job did not run for some reason... I'm still looking into this. So currently I can't confirm but will update you later as soon as the usage job did run. Regards Liridon -Original Message- From: Rohit Yadav mailto:rohit%20yadav%20%3crohit.ya...@shapeblue.com%3e>> Reply-To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org> To: dev@cloudstack.apache.org mailto:%22...@cloudstack.apache.org%22%20%3c...@cloudstack.apache.org%3e>>, andrija.pa...@gmail.com mailto:%22andrija.pa...@gmail.com%22%20%3candrija.pa...@gmail.com%3e>>, us...@cloudstack.apache.org mailto:%22us...@cloudstack.apache.org%22%20%3cus...@cloudstack.apache.org%3e>> Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 Date: Mon, 04 May 2020 10:16:51 + Thanks for testing and sharing your results Liridon! Can you also test the case if the usage records have the correct time according to configured timezone (in global settings) if you're using a non-UTC timezone? I'll add the db.usage.url.paramsl as well in the PR. Regards, Rohit Yadav Software Architect, ShapeBlue <https://www.shapeblue.com> https://www.shapeblue.com From: Ismaili, Liridon (SWISS TXT) < <mailto:liridon.isma...@swisstxt.ch> liridon.isma...@swisstxt.ch > Sent: Monday, May 4, 2020 15:38 To: <mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org < <mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org >; <mailto:andrija.pa...@gmail.com> andrija.pa...@gmail.com < <mailto:andrija.pa...@gmail.com> andrija.pa...@gmail.com >; <mailto:us...@cloudstack.apache.org> us...@cloudstack.apache.org < <mailto:us...@cloudstack.apache.org> us...@cloudstack.apache.org > Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 Hi Rohit That did the trick! I did remove all the timezone information on my.cnf and only added the timezone information on the db.properties file. So I can confirm it fixes the issue. If you are using the usage service too you will also need to specify the timezone information for the usage DB: "db.usage.url.params=" in the /etc/cloudstack/management/db.properties file. Otherwise the usage service won't be able to start. This did also fix my issue and all my dates inside the db are now in the correct time zone! I'll also update the Github PR so we can track it there. Many thanks and Regards Liridon <mailto:rohit.ya...@shapeblue.com> rohit.ya...@shapeblue.com <http://www.shapeblue.com> www.shapeblue.com 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue -Original Message- From: "Ismaili, Liridon (SWISS TXT)" < <mailto:liridon.isma...@swisstxt.ch> liridon.isma...@swisstxt.ch <mailto:%22Ismaili, <mailto:%20liridon%20%28swiss%20txt%29%22%20%3cliridon.isma...@swisstxt.ch> %20liridon%20%28swiss%20txt%29%22%20%3cliridon.isma...@swisstxt.ch %3e>> Reply-To: <mailto:us...@cloudstack.apache.org> us...@cloudstack.apache.org mailto:us...@cloudstack.apache.org> us...@cloudstack.apache.org > To: <mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org < <mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org mailto:%22...@cloudstack.apache.org> %22...@cloudstack.apache.org <mailto:%22%20%3c...@cloudstack.apache.org> %22%20%3c...@cloudstack.apache.org %3e>>, <mailto:andrija.pa...@gmail.com> andrija.pa...@gmail.com < <mailto:andrija.pa...@gmail.com> andrija.pa...@gmail.com mailto:%22andrija.pa...@gmail.com> %22andrija.pa...@gmail.com <mailto:%22%20%3candrija.pa...@gmail.com> %22%20%3candrija.pa...@gmail.com %3e>>, <mailto:us...@cloudstack.apache.org> us...@cloudstack.apache.org < <mailto:us...@cloudstack.apache.org> us...@cloudstack.apache.org mailto:%22us...@cloudstack.apache.org> %22us...@cloudstack.apache.org <mailto:%22%20%3cus...@cloudstack.apache.org> %22%20%3cus...@cloudstack.apache.org %3e>> Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 Date: Mon, 04 May 2020 09:53:35 + Hi Rohit I'll test that and let you know. Regards Liridon -Original Message- From: Rohit Yadav < mailto:rohit.ya...@shapeblue.com> rohit.ya...@shapeblue.com >
Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Thanks for testing and sharing your results Liridon! Can you also test the case if the usage records have the correct time according to configured timezone (in global settings) if you're using a non-UTC timezone? I'll add the db.usage.url.paramsl as well in the PR. Regards, Rohit Yadav Software Architect, ShapeBlue https://www.shapeblue.com From: Ismaili, Liridon (SWISS TXT) Sent: Monday, May 4, 2020 15:38 To: dev@cloudstack.apache.org ; andrija.pa...@gmail.com ; us...@cloudstack.apache.org Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 Hi Rohit That did the trick! I did remove all the timezone information on my.cnf and only added the timezone information on the db.properties file. So I can confirm it fixes the issue. If you are using the usage service too you will also need to specify the timezone information for the usage DB: "db.usage.url.params=" in the /etc/cloudstack/management/db.properties file. Otherwise the usage service won't be able to start. This did also fix my issue and all my dates inside the db are now in the correct time zone! I'll also update the Github PR so we can track it there. Many thanks and Regards Liridon rohit.ya...@shapeblue.com www.shapeblue.com 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue -Original Message- From: "Ismaili, Liridon (SWISS TXT)" mailto:%22Ismaili,%20liridon%20%28swiss%20txt%29%22%20%3cliridon.isma...@swisstxt.ch%3e>> Reply-To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org> To: dev@cloudstack.apache.org mailto:%22...@cloudstack.apache.org%22%20%3c...@cloudstack.apache.org%3e>>, andrija.pa...@gmail.com mailto:%22andrija.pa...@gmail.com%22%20%3candrija.pa...@gmail.com%3e>>, us...@cloudstack.apache.org mailto:%22us...@cloudstack.apache.org%22%20%3cus...@cloudstack.apache.org%3e>> Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 Date: Mon, 04 May 2020 09:53:35 + Hi Rohit I'll test that and let you know. Regards Liridon -Original Message- From: Rohit Yadav < <mailto:rohit.ya...@shapeblue.com> rohit.ya...@shapeblue.com mailto:rohit%20yadav%20%3crohit.ya...@shapeblue.com> rohit%20yadav%20%3crohit.ya...@shapeblue.com %3e>> Reply-To: <mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org > To: Andrija Panic < <mailto:andrija.pa...@gmail.com> andrija.pa...@gmail.com mailto:andrija%20panic%20%3candrija.pa...@gmail.com> andrija%20panic%20%3candrija.pa...@gmail.com %3e>>, users < <mailto:us...@cloudstack.apache.org> us...@cloudstack.apache.org mailto:users%20%3cus...@cloudstack.apache.org> users%20%3cus...@cloudstack.apache.org %3e>>, <mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org < <mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org mailto:%22...@cloudstack.apache.org> %22...@cloudstack.apache.org <mailto:%22%20%3c...@cloudstack.apache.org> %22%20%3c...@cloudstack.apache.org %3e>> Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 Date: Mon, 04 May 2020 09:50:10 + Hi Andrija, all, While adding support for Java 11, the mysql-connector 8.x java dependency was introduced from previous 5.7x version. According to < <https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html> https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html > <https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html> https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html it seems we can specify the server time in connection parameters. Can any users test this workaround and confirm if it fixes their issue in their test/upgrade environments by adding "&serverTimezone=UTC" to the "db.cloud.url.params=" in the /etc/cloudstack/management/db.properties file, revert changes for mysql server and restart the management server. Draft PR proposed: < <https://github.com/apache/cloudstack/pull/4055/files> https://github.com/apache/cloudstack/pull/4055/files > <https://github.com/apache/cloudstack/pull/4055/files> https://github.com/apache/cloudstack/pull/4055/files We may then either discuss to either include the above PR or document this in our release/upgrade notes. Thanks. Regards, Rohit Yadav Software Architect, ShapeBlue < <https://www.shapeblue.com> https://www.shapeblue.com > <https://www.shapeblue.com> https://www.shapeblue.com From: Andrija Panic < mailto:andrija.pa...@gmail.com> andrija.pa...@gmail.com >
Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Hi Rohit That did the trick! I did remove all the timezone information on my.cnf and only added the timezone information on the db.properties file. So I can confirm it fixes the issue. If you are using the usage service too you will also need to specify the timezone information for the usage DB: "db.usage.url.params=" in the /etc/cloudstack/management/db.properties file. Otherwise the usage service won't be able to start. This did also fix my issue and all my dates inside the db are now in the correct time zone! I'll also update the Github PR so we can track it there. Many thanks and Regards Liridon -Original Message- From: "Ismaili, Liridon (SWISS TXT)" mailto:%22Ismaili,%20liridon%20%28swiss%20txt%29%22%20%3cliridon.isma...@swisstxt.ch%3e>> Reply-To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org> To: dev@cloudstack.apache.org mailto:%22...@cloudstack.apache.org%22%20%3c...@cloudstack.apache.org%3e>>, andrija.pa...@gmail.com mailto:%22andrija.pa...@gmail.com%22%20%3candrija.pa...@gmail.com%3e>>, us...@cloudstack.apache.org mailto:%22us...@cloudstack.apache.org%22%20%3cus...@cloudstack.apache.org%3e>> Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 Date: Mon, 04 May 2020 09:53:35 + Hi Rohit I'll test that and let you know. Regards Liridon -Original Message- From: Rohit Yadav < <mailto:rohit.ya...@shapeblue.com> rohit.ya...@shapeblue.com mailto:rohit%20yadav%20%3crohit.ya...@shapeblue.com> rohit%20yadav%20%3crohit.ya...@shapeblue.com %3e>> Reply-To: <mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org > To: Andrija Panic < <mailto:andrija.pa...@gmail.com> andrija.pa...@gmail.com mailto:andrija%20panic%20%3candrija.pa...@gmail.com> andrija%20panic%20%3candrija.pa...@gmail.com %3e>>, users < <mailto:us...@cloudstack.apache.org> us...@cloudstack.apache.org mailto:users%20%3cus...@cloudstack.apache.org> users%20%3cus...@cloudstack.apache.org %3e>>, <mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org < <mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org mailto:%22...@cloudstack.apache.org> %22...@cloudstack.apache.org <mailto:%22%20%3c...@cloudstack.apache.org> %22%20%3c...@cloudstack.apache.org %3e>> Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 Date: Mon, 04 May 2020 09:50:10 + Hi Andrija, all, While adding support for Java 11, the mysql-connector 8.x java dependency was introduced from previous 5.7x version. According to < <https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html> https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html > <https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html> https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html it seems we can specify the server time in connection parameters. Can any users test this workaround and confirm if it fixes their issue in their test/upgrade environments by adding "&serverTimezone=UTC" to the "db.cloud.url.params=" in the /etc/cloudstack/management/db.properties file, revert changes for mysql server and restart the management server. Draft PR proposed: < <https://github.com/apache/cloudstack/pull/4055/files> https://github.com/apache/cloudstack/pull/4055/files > <https://github.com/apache/cloudstack/pull/4055/files> https://github.com/apache/cloudstack/pull/4055/files We may then either discuss to either include the above PR or document this in our release/upgrade notes. Thanks. Regards, Rohit Yadav Software Architect, ShapeBlue < <https://www.shapeblue.com> https://www.shapeblue.com > <https://www.shapeblue.com> https://www.shapeblue.com From: Andrija Panic < mailto:andrija.pa...@gmail.com> andrija.pa...@gmail.com > <mailto:andrija.pa...@gmail.com> andrija.pa...@gmail.com Sent: Friday, May 1, 2020 22:38 To: users < mailto:us...@cloudstack.apache.org> us...@cloudstack.apache.org > <mailto:us...@cloudstack.apache.org> us...@cloudstack.apache.org ; Rohit Yadav < mailto:rohit.ya...@shapeblue.com> rohit.ya...@shapeblue.com > <mailto:rohit.ya...@shapeblue.com> rohit.ya...@shapeblue.com Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1 @Rohit Yadavmailto:rohit.ya...@shapeblue.com> rohit.ya...@shapeblue.com > <mailto:rohit.ya...@shapeblue.com> rohit.ya...@shapeblue.com can you possibly advice on the time zone issue? I've seen this on another ML thr
Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Hi Rohit
I'll test that and let you know.
Regards
Liridon
-Original Message-
From: Rohit Yadav
mailto:rohit%20yadav%20%3crohit.ya...@shapeblue.com%3e>>
Reply-To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
To: Andrija Panic
mailto:andrija%20panic%20%3candrija.pa...@gmail.com%3e>>,
users
mailto:users%20%3cus...@cloudstack.apache.org%3e>>,
dev@cloudstack.apache.org
mailto:%22...@cloudstack.apache.org%22%20%3c...@cloudstack.apache.org%3e>>
Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Date: Mon, 04 May 2020 09:50:10 +
Hi Andrija, all,
While adding support for Java 11, the mysql-connector 8.x java dependency was
introduced from previous 5.7x version.
According to
<https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html>
https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html
it seems we can specify the server time in connection parameters. Can any
users test this workaround and confirm if it fixes their issue in their
test/upgrade environments by adding "&serverTimezone=UTC" to the
"db.cloud.url.params=" in the /etc/cloudstack/management/db.properties file,
revert changes for mysql server and restart the management server.
Draft PR proposed:
<https://github.com/apache/cloudstack/pull/4055/files>
https://github.com/apache/cloudstack/pull/4055/files
We may then either discuss to either include the above PR or document this in
our release/upgrade notes. Thanks.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
<https://www.shapeblue.com>
https://www.shapeblue.com
From: Andrija Panic <
<mailto:andrija.pa...@gmail.com>
andrija.pa...@gmail.com
>
Sent: Friday, May 1, 2020 22:38
To: users <
<mailto:us...@cloudstack.apache.org>
us...@cloudstack.apache.org
>; Rohit Yadav <
<mailto:rohit.ya...@shapeblue.com>
rohit.ya...@shapeblue.com
>
Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
@Rohit Yadavmailto:rohit.ya...@shapeblue.com>
rohit.ya...@shapeblue.com
> can you possibly advice on the time zone issue? I've seen this on another ML
> thread as well. We are mostly in UTC (test envs) so this might be the reason
> we didn't see this...could be just a documentation update that is needed.
@Robert is there any specifics to your NFS server (i.e. a forbidden NFSv3 or
similar)? Also, can you please open a GitHub issue and provide the same there?
So we can track it and collaborate - I've not seen this one before.
What packages did you use for the installation? On the issue you'll raise,
please also include the relevant output from the /var/log/cloud.log from inside
the SSVM
Also not sure what is the relation between MySQL and JRE at all - they should
have nothing in common?
Thanks!
Andrija
<mailto:rohit.ya...@shapeblue.com>
rohit.ya...@shapeblue.com
<http://www.shapeblue.com>
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
On Fri, 1 May 2020 at 17:49, Robert Ward <
<mailto:rww...@gmail.com>
rww...@gmail.com
mailto:rww...@gmail.com>
rww...@gmail.com
>> wrote:
Hi all,
I too have run into an issues while performing a clean install:
Centos 7, MySQL 5.6, JRE 11
JRE 11 and MySQL 5.6 don't see to play well on two points:
Installing JRE before MySQL causes MYSQL to "lockup" on startup. I have found
that if I install JRE after MySQL that issue is resolved.
MySQL chokes with timezone error @ cloudstack-setup-management. In my case
MySQL doesn't like "EDT" as a timezone. Resolved by adding this to etc/my.cnf:
default-time-zone= "-05:00"
On my last point CS has difficulty with mounting secondary storage. I have
clipped the logs to the point where I think the problem lies:
2020-05-01 10:55:07,871 DEBUG [c.c.h.o.r.Ovm3HypervisorGuru]
(StatsCollector-5:ctx-35c593ba) (logid:aad9ed2a) getCommandHostDelegation:
class com.cloud.agent.api.GetStorageStatsCommand
2020-05-01 10:55:07,871 DEBUG [c.c.h.XenServerGuru]
(StatsCollector-5:ctx-35c593ba) (logid:aad9ed2a) We are returning the default
host to execute commands because the command is not of Copy type.
2020-05-01 10:55:07,910 DEBUG [c.c.a.t.Request] (AgentManager-Handler-8:null)
(logid:) Seq 2-4356951164504244991: Processing: { Ans: , MgmtId: 144345337593,
via: 2, Ver: v1, Flags: 10,
[{"com.cloud.agent.api.Answer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
GetRootDir for nfs://192.168.25.1/export/secondary<
<http://192.168.25.1/export/secondary>
http://192.168.25.1/export/secondary
> failed due to com.cloud.utils.exception.CloudRuntimeException: Unable to
>
Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Hi Andrija, all,
While adding support for Java 11, the mysql-connector 8.x java dependency was
introduced from previous 5.7x version.
According to
https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html
it seems we can specify the server time in connection parameters. Can any
users test this workaround and confirm if it fixes their issue in their
test/upgrade environments by adding "&serverTimezone=UTC" to the
"db.cloud.url.params=" in the /etc/cloudstack/management/db.properties file,
revert changes for mysql server and restart the management server.
Draft PR proposed:
https://github.com/apache/cloudstack/pull/4055/files
We may then either discuss to either include the above PR or document this in
our release/upgrade notes. Thanks.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
https://www.shapeblue.com
From: Andrija Panic
Sent: Friday, May 1, 2020 22:38
To: users ; Rohit Yadav
Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
@Rohit Yadav<mailto:rohit.ya...@shapeblue.com> can you possibly advice on the
time zone issue? I've seen this on another ML thread as well. We are mostly in
UTC (test envs) so this might be the reason we didn't see this...could be just
a documentation update that is needed.
@Robert is there any specifics to your NFS server (i.e. a forbidden NFSv3 or
similar)? Also, can you please open a GitHub issue and provide the same there?
So we can track it and collaborate - I've not seen this one before.
What packages did you use for the installation? On the issue you'll raise,
please also include the relevant output from the /var/log/cloud.log from inside
the SSVM
Also not sure what is the relation between MySQL and JRE at all - they should
have nothing in common?
Thanks!
Andrija
rohit.ya...@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
On Fri, 1 May 2020 at 17:49, Robert Ward
mailto:rww...@gmail.com>> wrote:
Hi all,
I too have run into an issues while performing a clean install:
Centos 7, MySQL 5.6, JRE 11
JRE 11 and MySQL 5.6 don't see to play well on two points:
Installing JRE before MySQL causes MYSQL to "lockup" on startup. I have found
that if I install JRE after MySQL that issue is resolved.
MySQL chokes with timezone error @ cloudstack-setup-management. In my case
MySQL doesn't like "EDT" as a timezone. Resolved by adding this to etc/my.cnf:
default-time-zone= "-05:00"
On my last point CS has difficulty with mounting secondary storage. I have
clipped the logs to the point where I think the problem lies:
2020-05-01 10:55:07,871 DEBUG [c.c.h.o.r.Ovm3HypervisorGuru]
(StatsCollector-5:ctx-35c593ba) (logid:aad9ed2a) getCommandHostDelegation:
class com.cloud.agent.api.GetStorageStatsCommand
2020-05-01 10:55:07,871 DEBUG [c.c.h.XenServerGuru]
(StatsCollector-5:ctx-35c593ba) (logid:aad9ed2a) We are returning the default
host to execute commands because the command is not of Copy type.
2020-05-01 10:55:07,910 DEBUG [c.c.a.t.Request] (AgentManager-Handler-8:null)
(logid:) Seq 2-4356951164504244991: Processing: { Ans: , MgmtId: 144345337593,
via: 2, Ver: v1, Flags: 10,
[{"com.cloud.agent.api.Answer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
GetRootDir for
nfs://192.168.25.1/export/secondary<http://192.168.25.1/export/secondary>
failed due to com.cloud.utils.exception.CloudRuntimeException: Unable to mount
192.168.25.1:/export/secondary at
/mnt/SecStorage/b7e9e158-ed80-3a62-a5d7-1992c991d829 due to mount.nfs:
requested NFS version or transport protocol is not supported\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getRootDir(NfsSecondaryStorageResource.java:2458)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:2208)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:292)\n\tat
com.cloud.storage.resource.PremiumSecondaryStorageResource.defaultAction(PremiumSecondaryStorageResource.java:64)\n\tat
com.cloud.storage.resource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:60)\n\tat
com.cloud.agent.Agent.processRequest(Agent.java:644)\n\tat
com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:1057)\n\tat
com.cloud.utils.nio.Task.call(Task.java:83)\n\tat
com.cloud.utils.nio.Task.call(Task.java:29)\n\tat
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)\n\tat
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
java.base/java.lang.Thread.run(Thread.j
Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
g into the Database I saw that all the date values are stored under UTC and not UTC+2 (as it was prior the upgrade). I believe the time zone information is required by Java JRE 11 and would like to ask if you have an advice (or anyone else) how to correct the values and may explain why the date values are shifted as I did setup the time zone UTC +2? Best Regards Liridon -Original Message- From: Andrija Panic mailto:andrija%20panic%20%3candrija.pa...@gmail.com%3e>> Reply-To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org> To: dev mailto:dev%20%3c...@cloudstack.apache.org%3e>>, users mailto:users%20%3cus...@cloudstack.apache.org%3e>> Subject: [VOTE] Apache CloudStack 4.14.0.0 RC1 Date: Wed, 29 Apr 2020 16:38:44 +0200 Hi All, I've created a 4.14.0.0 release (RC1), with the following artefacts up for testing and a vote: Git Branch and Commit SH: <https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.14.0.0-RC20200429T1355> https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.14.0.0-RC20200429T1355 Commit: 2c39b7180a9fb40cbdcad5e6a58be64a86913771 Source release (checksums and signatures are available at the same location): <https://dist.apache.org/repos/dist/dev/cloudstack/4.14.0.0/> https://dist.apache.org/repos/dist/dev/cloudstack/4.14.0.0/ PGP release keys (signed using 3DC01AE8): <https://dist.apache.org/repos/dist/release/cloudstack/KEYS> https://dist.apache.org/repos/dist/release/cloudstack/KEYS The vote will be open until Wednesday 06.May.2020. For sanity in tallying the vote, can PMC members please be sure to indicate "(binding)" with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Additional information: For users' convenience, I've built packages from 2c39b7180a9fb40cbdcad5e6a58be64a86913771 and published RC1 repository here (CentOS 7 and Debian/generic): <http://packages.shapeblue.com/testing/41400rc1/> http://packages.shapeblue.com/testing/41400rc1/ and here (Ubuntu 18.04 specific, thanks to Gabriel): <https://download.cloudstack.org/testing/4.14.0.0-RC20200429T1355/ubuntu/bionic/> https://download.cloudstack.org/testing/4.14.0.0-RC20200429T1355/ubuntu/bionic/ The release notes are still work-in-progress, but for the upgrade instructions (including new systemVM templates) you may refer the following URL: <https://acs-www.shapeblue.com/docs/WIP-PROOFING/pr87/upgrading/index.html> https://acs-www.shapeblue.com/docs/WIP-PROOFING/pr87/upgrading/index.html 4.14.0.0 systemVM templates are available from here: <http://download.cloudstack.org/systemvm/4.14/> http://download.cloudstack.org/systemvm/4.14/ Regards, Andrija Panić
[VOTE] Apache CloudStack 4.14.0.0 RC1
Hi All, I've created a 4.14.0.0 release (RC1), with the following artefacts up for testing and a vote: Git Branch and Commit SH: https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.14.0.0-RC20200429T1355 Commit: 2c39b7180a9fb40cbdcad5e6a58be64a86913771 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.14.0.0/ PGP release keys (signed using 3DC01AE8): https://dist.apache.org/repos/dist/release/cloudstack/KEYS The vote will be open until Wednesday 06.May.2020. For sanity in tallying the vote, can PMC members please be sure to indicate "(binding)" with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Additional information: For users' convenience, I've built packages from 2c39b7180a9fb40cbdcad5e6a58be64a86913771 and published RC1 repository here (CentOS 7 and Debian/generic): http://packages.shapeblue.com/testing/41400rc1/ and here (Ubuntu 18.04 specific, thanks to Gabriel): https://download.cloudstack.org/testing/4.14.0.0-RC20200429T1355/ubuntu/bionic/ The release notes are still work-in-progress, but for the upgrade instructions (including new systemVM templates) you may refer the following URL: https://acs-www.shapeblue.com/docs/WIP-PROOFING/pr87/upgrading/index.html 4.14.0.0 systemVM templates are available from here: http://download.cloudstack.org/systemvm/4.14/ Regards, Andrija Panić
