We don’t need to do anything for upgrade testing, in the release this feature is disabled, so there will be no issues when upgrading a stock release.
However it might be worth mentioning that if the admin switched to the HA procedure he should either disable this before upgrading or make sure he uses the noredist build when upgrading. I’m not familiar with “felton", what is that? Cheers, Hugo On 27 feb. 2014, at 10:02, Santhosh Edukulla <santhosh.eduku...@citrix.com> wrote: > Does this all warrant a process sign off of upgrade testing? HA working in > production and upgrading to felton with changes below? > > Thanks! > Santhosh > ________________________________________ > From: Trippie [trip...@gmail.com] on behalf of Hugo Trippaers > [h...@trippaers.nl] > Sent: Thursday, February 27, 2014 3:51 AM > To: <dev@cloudstack.apache.org> > Subject: Re: developers and mysql > > Done > > commit a0f932437c9ac9a0a82cc9b45b1aa6f17e8a478a > Author: Hugo Trippaers <htrippa...@schubergphilis.com> > Date: Thu Feb 27 09:48:55 2014 +0100 > > Move mysql ha strategy to a plugin. Activate this plugin using the mysqlha > profile or the noredist flag > > > > On 27 feb. 2014, at 09:25, Hugo Trippaers <trip...@gmail.com> wrote: > >> >> On 27 feb. 2014, at 09:09, Alex Huang <alex.hu...@citrix.com> wrote: >> >>> Abhi, >>> >>> It's not licensing issue that troubles me. It's the fact that mysql's been >>> made a compile dependency when it wasn't before. It encourages people to >>> adopt more mysql functionality into the cloudstack code. Eventually that >>> means we get more and more tied in with mysql once the trend has started. >> >> Agreed, that is a risk. We need to keep paying attention that new additions >> don’t introduce something we are not comfortable with. We maybe could make a >> jenkins check that will alert if the dependency list changes from a previous >> compile. Should be possible with a little creative scripting. >> >>> >>> I would prefer the entire file is not in CloudStack as it really has >>> nothing to do with CloudStack itself. But, I'm fine with Hugo suggestion >>> of this being put into pluginin enabled by noredist and mysql is only >>> dependent upon in that plugin's pom.xml. >> >> My reasoning here is that somebody took the time and effort to write >> something to either improve cloudstack or fix a problem. We should try to >> include this if we reasonably can, every contribution is valuable. That said >> i would be curious to know if anyone is relying on this at the moment. >> >>> >>> --Alex >>> >>>> -----Original Message----- >>>> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] >>>> Sent: Wednesday, February 26, 2014 9:54 PM >>>> To: dev@cloudstack.apache.org; Damoder Reddy >>>> Subject: Re: developers and mysql >>>> >>>> Immediately if there are no specific licensing issues we should maintain >>>> the >>>> status-quo. >>>> The fact is that some other HA solutions will not work as all the schema >>>> related scripts are mysql engine specific. >>>> >>>> When we decide to move the mysql dependency out of cloudstack we >>>> should do it for all such dependencies. >>>> If there is an agreement here we can file a ticket to track this. >>>> >>>> -abhi >>>> >>>> >>>> On 27/02/14 11:16 am, "Abhinandan Prateek" >>>> <abhinandan.prat...@citrix.com> >>>> wrote: >>>> >>>>> StaticStrategy is overriding the Mysql¹s HA Strategy. So it is more a >>>>> part of the mysql jdbc driver providing a specific strategy that works >>>>> as per the documented HA procedure. >>>>> >>>>> I think moving it to a separate github project that generates the >>>>> additional mysql connector jar should be ok (any licensing issues). >>>>> We can then document that anyone configuring DB-HA as per the >>>> suggested >>>>> procedure should download this and add it to the classpath. >>>>> >>>>> -abhi >>>>> >>>>> >>>>> On 27/02/14 10:54 am, "Alex Huang" <alex.hu...@citrix.com> wrote: >>>>> >>>>>> Hi Damoder, >>>>>> >>>>>> I don't think I follow. There's clearly compile dependency on mysql >>>>>> in StaticStrategy. >>>>>> >>>>>> To me, when I look at StaticStartegy, it makes sense to move that into >>>>>> separate project in github and reference people to it if they want to >>>>>> use the specific setup outlined in the DB HA wiki. That to me would >>>>>> make it a runtime dependency only. >>>>>> >>>>>> --Alex >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Damoder Reddy >>>>>>> Sent: Wednesday, February 26, 2014 9:20 PM >>>>>>> To: Alex Huang; dev@cloudstack.apache.org >>>>>>> Subject: RE: developers and mysql >>>>>>> >>>>>>> Hi Alex, >>>>>>> >>>>>>> The mysql dependency is on for only " StaticStrategy.java" as >>>>>>> mentioned by you. And this is not used anywhere in the code base as a >>>>>>> compile time dependency rather used as a run time dependency in >>>>>>> db.properties. this will be passed to mysql driver as part of mysql >>>>>>> Database URL construction. >>>>>>> >>>>>>> This StaticStrategy.java will become mute if we move out of mysql >>>>>>> driver as it has only runtime dependency. >>>>>>> >>>>>>> Thanks & Regards >>>>>>> Damodar/ >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Alex Huang >>>>>>> Sent: Thursday, February 27, 2014 4:13 AM >>>>>>> To: dev@cloudstack.apache.org >>>>>>> Cc: Damoder Reddy >>>>>>> Subject: RE: developers and mysql >>>>>>> >>>>>>> @Hugo >>>>>>> >>>>>>> The mysql scripts is a legacy of we used to dump the mysql db to >>>>>>> create the create-schema sql but it is at worst still a runtime >>>>>>> dependency. We should fix it but I don't think it's as high a >>>>>>> priority as the compile time dependency that has been introduced. >>>>>>> >>>>>>> @Damoder, >>>>>>> >>>>>>> Can you take a look at StaticStrategy.java? This is the only file >>>>>>> that requires mysql but I couldn't find anywhere in the code that >>>>>>> references this class. I then looked at the bug and wiki and it >>>>>>> also doesn't mentioned that dependency on mysql has been added. It >>>>>>> doesn't make sense for CloudStack to include this automatically. >>>>>>> There are many ways to provide DB HA and incorporate it into our >>>>>>> code just limits the possibilities. We can for example document >>>>>>> this as a way to do it in on the wiki for example but I just don't >>>>>>> see why we would use code to limit it. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> --Alex >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Hugo Trippaers [mailto:trip...@gmail.com] >>>>>>>> Sent: Tuesday, February 25, 2014 2:02 PM >>>>>>>> To: dev@cloudstack.apache.org >>>>>>>> Cc: dev@cloudstack.apache.org >>>>>>>> Subject: Re: developers and mysql >>>>>>>> >>>>>>>> We are already pretty much locked in as all our database scripts >>>>>>>> are MySQL specific. If we want to be neutral we should fix that. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Hugo >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>>> On 25 feb. 2014, at 22:57, David Nalley <da...@gnsa.us> wrote: >>>>>>>>> >>>>>>>>> git blame showed that it came from the HA/replication work from >>>>>>> Damoder. >>>>>>>>> I didn't speak up at the time, but I am really reluctant for >>>>>>>>> mysql-specific features to sneak in and lock us in. >>>>>>>>> >>>>>>>>>> On Tue, Feb 25, 2014 at 4:44 PM, Alex Huang >>>>>>> <alex.hu...@citrix.com> >>>>>>>> wrote: >>>>>>>>>> Who added the dependency on mysql for framework-db? We >>>>>>>>>> actually >>>>>>>> worked hard to keep that depending on jdbc only. It should not >>>>>>> depend >>>>>>>> on mysql. We need to fix that. >>>>>>>>>> >>>>>>>>>> --Alex >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo >>>>>>>>>>> Trippaers >>>>>>>>>>> Sent: Tuesday, February 25, 2014 3:34 AM >>>>>>>>>>> To: <dev@cloudstack.apache.org> >>>>>>>>>>> Subject: Re: developers and mysql >>>>>>>>>>> >>>>>>>>>>> Heya, >>>>>>>>>>> >>>>>>>>>>> Just pushed a change that will make the database work again. >>>>>>>>>>> :-) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> @Alex. The mysql jar used to be pulled in as a dependency from >>>>>>>>>>> framework- db. As the client target is responsible for >>>>>>>>>>> building the war file for the packages including this in the >>>>>>>>>>> client pom would also put it in the war file and in the packages. >>>>>>>>>>> >>>>>>>>>>> I think i have an elegant solution, its now included as a >>>>>>>>>>> dependency for both the database deploy and the jetty:run target. >>>>>>>>>>> Which makes it effectively a "provided" library for the >>>>>>>>>>> purpose >>>>>>> of >>>>>>>>>>> our maven build. See commit >>>>>>>>>>> 8e6b86ae23dce802044388c5420ff61511d7115b and >>>>>>> e883877c7a6f9df04b572afd4ee5f10d265bcc3a. >>>>>>>>>>> >>>>>>>>>>> I can deploy a database and start the jetty:run target now >>>>>>> without >>>>>>>>>>> any trouble (at least not more trouble than usual ;-) ) >>>>>>>>>>> >>>>>>>>>>> My next step is to clean up some of the dependencies. I think >>>>>>> that >>>>>>>>>>> only cloud-framework-db should have a provided dependency on >>>>>>> mysql. >>>>>>>>>>> It's the only piece of source code that actually needs the >>>>>>>>>>> mysql driver to be present during compilation for the optional >>>>>>>>>>> HA configuration. There are some test classes that depend on >>>>>>> database >>>>>>>>>>> functionally but those should be moved to an integration test >>>>>>>>>>> profile that could include the database driver, those tests >>>>>>>>>>> are disabled >>>>>>>> anyway so they don't cause any trouble now. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> Hugo >>>>>>>>>>> >>>>>>>>>>>> On 25 feb. 2014, at 06:39, Rajani Karuturi >>>>>>>>>>>> <rajani.karut...@citrix.com> >>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Can we move the mysql-connector-java dependency to the >>>> parent >>>>>>>>>>> POM(SOURCE-ROOT/pom.xml) and define it different scopes for >>>>>>>>>>> each >>>>>>>> profile? >>>>>>>>>>>> >>>>>>>>>>>> ie) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> <profile> >>>>>>>>>>>> <id>developer</id> >>>>>>>>>>>> <dependencies> >>>>>>>>>>>> <dependency> >>>>>>>>>>>> <groupId>mysql</groupId> >>>>>>>>>>>> <artifactId>mysql-connector-java</artifactId> >>>>>>>>>>>> <scope>compile</scope> >>>>>>>>>>>> </dependency> >>>>>>>>>>>> </dependencies> >>>>>>>>>>>> </profile> >>>>>>>>>>>> <profile> >>>>>>>>>>>> <id>production</id> >>>>>>>>>>>> <dependencies> >>>>>>>>>>>> <dependency> >>>>>>>>>>>> <groupId>mysql</groupId> >>>>>>>>>>>> <artifactId>mysql-connector-java</artifactId> >>>>>>>>>>>> <scope>provided</scope> >>>>>>>>>>>> </dependency> >>>>>>>>>>>> </dependencies> >>>>>>>>>>>> </profile> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> ~Rajani >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 24-Feb-2014, at 11:41 pm, Hugo Trippaers >>>>>>>>>>> <trip...@gmail.com<mailto:trip...@gmail.com>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Indeed, >>>>>>>>>>>> >>>>>>>>>>>> I've been fighting with maven all day to get the development >>>>>>>>>>>> profile to include MySql. No luck yet, will give it another >>>>>>>>>>>> shot tomorrow :-) >>>>>>>>>>>> >>>>>>>>>>>> Hugo >>>>>>>>>>>> >>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>> >>>>>>>>>>>> On 24 feb. 2014, at 18:21, David Nalley >>>>>>>>>>> <da...@gnsa.us<mailto:da...@gnsa.us>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> So it should be ok to include the jar in non-default builds. >>>>>>>>>>>> developer and deploydb are not what we'd expect a normal user >>>>>>>>>>>> to >>>>>>>> consume. >>>>>>>>>>>> (Anyone else's head spinning?) >>>>>>>>>>>> >>>>>>>>>>>> --David >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Feb 24, 2014 at 11:44 AM, John Kinsella >>>>>>>>>>> <j...@stratosec.co<mailto:j...@stratosec.co>> wrote: >>>>>>>>>>>> I created CLOUDSTACK-6157 over the weekend to track this. Not >>>>>>>>>>>> sure >>>>>>>>>>> adding the jar after compile will help the deploydb target, >>>>>>>>>>> but will give it a try this morning. >>>>>>>>>>>> >>>>>>>>>>>> Could we set up the pom.xmls to use the jar for execution if >>>>>>> it's >>>>>>>>>>>> found in >>>>>>>>>>> the user/system classpaths while respecting the legal >>>>>>> requirements? >>>>>>>>>>>> >>>>>>>>>>>> Rayees' suggestion for cloud.spec makes sense for the RPM >>>>>>> builds, >>>>>>>>>>>> but >>>>>>>>>>> doesn't affect the developer issues. >>>>>>>>>>>> >>>>>>>>>>>> -He who needs more maven experience >>>>>>>>>>>> >>>>>>>>>>>> On Feb 24, 2014, at 7:36 AM, Hugo Trippaers >>>>>>>>>>> <h...@trippaers.nl<mailto:h...@trippaers.nl>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Heya, >>>>>>>>>>>> >>>>>>>>>>>> as the mysql dependency is now set to provided in all the >>>>>>>>>>>> poms >>>>>>> to >>>>>>>>>>>> fix our >>>>>>>>>>> license compliancy the jetty target and the deployed targets >>>>>>>>>>> are not >>>>>>>> working. >>>>>>>>>>>> >>>>>>>>>>>> I'm trying to configure an optional profile to enable those >>>>>>>>>>>> targets to include >>>>>>>>>>> the mysql dependency while executing, but so far no luck. If >>>>>>>>>>> anyone has some bright ideas on how to do this i'm all ears. >>>>>>>>>>> In the meantime the best solutions i've found to continue >>>>>>>>>>> working is to copy the mysql jar file into the directory >>>>>>>>>>> client/target/cloud-client-ui-4.4.0-SNAPSHOT/WEB-INF/lib/ by >>>>>>>>>>> hand after running mvm install and before running the jetty >>>>>>>>>>> target (just don't >>>>>>>> run mvn clean). >>>>>>>>>>>> >>>>>>>>>>>> Hopefully a better solution in the near future. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> >>>>>>>>>>>> Hugo >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>> >>> >> >
