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
