Hey Darren, the build appears to be broken on spring-modularization. Actually a test is broken. If fixed I could generate some packages for testing.
http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-yumrepo-refresh/3028/console On Fri, Oct 04, 2013 at 10:27:55AM +0530, Prasanna Santhanam wrote: > Thanks. I will first run a baseline against master since we don't have > one and then one on spring modularization. The baseline against 4.2 > shows this result: > > http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-regression-matrix/252/testReport/ > > On Thu, Oct 03, 2013 at 09:19:23AM -0700, Darren Shepherd wrote: > > This should be fixed on the spring-modularization branch. > > > > Darren > > > > On Wed, Oct 2, 2013 at 10:05 PM, Prasanna Santhanam <t...@apache.org> wrote: > > > I switched the test infrastructure on jenkins.buildacloud.org to run > > > the bvts [1] against master last week. Couple of weeks before that the > > > simulator [2] tests were switched to run against master. Both are > > > broken unfortunately and the bvt and checkin tests aren't running. > > > > > > I've filed a bug here: > > > https://issues.apache.org/jira//browse/CLOUDSTACK-4791 > > > > > > [1] http://jenkins.buildacloud.org/view/cloudstack-qa/ > > > [2] http://jenkins.buildacloud.org/view/simulator/ > > > > > > Anyone who has access to the jenkins can run the bvts on their desired > > > branch. Simply login and change the test-yumrepo-refresh job to point > > > to your branch. Build that to refresh the remote repository with the > > > packages made from your branch. Then switch test-matrix to point to > > > the same development branch and fire a build. That's about it. > > > > > > On Wed, Oct 02, 2013 at 05:42:54PM -0700, Darren Shepherd wrote: > > >> Yes agreed. I've extensively tested this, but that is never enough. > > >> How do I get the BVTs ran against this. Due to the cross cutting > > >> nature of this I want to get this merged as fast as possible. > > >> > > >> Darren > > >> > > >> > On Oct 2, 2013, at 4:43 PM, Alex Huang <alex.hu...@citrix.com> wrote: > > >> > > > >> > +1 on running the BVT on it. We've been through this one once before. > > >> > Should be careful. > > >> > > > >> > --Alex > > >> > > > >> >> -----Original Message----- > > >> >> From: Kelven Yang [mailto:kelven.y...@citrix.com] > > >> >> Sent: Wednesday, October 2, 2013 4:39 PM > > >> >> To: dev@cloudstack.apache.org > > >> >> Subject: Re: [MERGE] spring-modularization to master - Spring > > >> >> Modularization > > >> >> > > >> >> Darren, > > >> >> > > >> >> This looks really nice. A few questions on Spring AOP replacement. > > >> >> > > >> >> 1) Spring AOP is proxy-based, the reason we ended up of using > > >> >> customized > > >> >> AOP is mainly due to that inside existing CloudStack codebase, we > > >> >> have many > > >> >> places that are doing run-time type-casting, the code in these places > > >> >> assumes a real object that implements all interfaces in the semantics > > >> >> context. > > >> >> At the time when I initially converted to Spring, I couldn't ensure > > >> >> that > > >> >> switching to proxy-based AOP can have 100% coverage for these run-time > > >> >> cases. What is your approach to address this run-time type-casting > > >> >> issue? > > >> >> > > >> >> 2) We've run into a huge-memory footprint issue that may be caused by > > >> >> conflicts of CGLIB usage in Spring AOP and the CGLIB usage in > > >> >> CloudStack Dao > > >> >> layer. Do you have a chance to run a memory analysis in the heap after > > >> >> management server is started. > > >> >> > > >> >> I might be good to run BVT test on the branch before the merge, could > > >> >> someone initiate the effort? > > >> >> > > >> >> kelven > > >> >> > > >> >> > > >> >> > > >> >> On 10/2/13 3:48 PM, "Darren Shepherd" <darren.s.sheph...@gmail.com> > > >> >> wrote: > > >> >> > > >> >>> Not sure how this works... I would like to merge in the new > > >> >>> modularized Spring setup to master. There is info on the wiki about > > >> >>> it > > >> >>> [1] [2] [3]. The primary change is to break apart the monolithic > > >> >>> applicationContext.xml and componentContext.xml files such that each > > >> >>> plugin can maintain and contribute its own configuration. > > >> >>> > > >> >>> In addition to breaking up the configuration we no longer use ACS > > >> >>> custom AOP and it is now fully Spring AOP. > > >> >>> > > >> >>> Now adding/removing a plug-in is a matter of just adding a jar to the > > >> >>> classpath (exception being commands.properties, I'll address that in > > >> >>> a > > >> >>> different thread). Unfortunately this branch does not have the > > >> >>> changes > > >> >>> to package things in different RPMs. So it would be great if > > >> >>> somebody > > >> >>> could take up the packaging effort to split out all the plugins into > > >> >>> different RPMs. > > >> >>> > > >> >>> Darren > > >> >>> > > >> >>> [1] > > >> >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Modularize+Sp > > >> >> rin > > >> >>> g > > >> >>> [2] > > >> >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Plug- > > >> >> ins%2C+Modu > > >> >>> les > > >> >>> %2C+and+Extensions > > >> >>> [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Extensions > > >> > > > > > > > -- > > > Prasanna., > > > > > > ------------------------ > > > Powered by BigRock.com > > > > > -- > Prasanna., > > ------------------------ > Powered by BigRock.com -- Prasanna., ------------------------ Powered by BigRock.com
