cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prasanna Santhanam <...@apache.org>
Subject Re: [MERGE] spring-modularization to master - Spring Modularization
Date Fri, 04 Oct 2013 04:57:55 GMT
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 <tsp@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.Huang@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.yang@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.shepherd@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


Mime
View raw message