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 >>> > >>>> >>> > >>>> >>> > >>>> >>> > >> >
