Hi Prasanna,
If we are running BVT or regression on specific branch, marvin should also from same branch right ? but we always getting marvin from master branch job "cloudstack-marvin" Regards, Rayees -----Original Message----- From: Prasanna Santhanam [mailto:t...@apache.org] Sent: Wednesday, October 02, 2013 10:06 PM To: dev@cloudstack.apache.org Subject: Re: [MERGE] spring-modularization to master - Spring Modularization 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<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<mailto: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<mailto: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<mailto: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
