Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of shadowsor@gmail.com
 designates 209.85.128.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <B1DF26ECC0458748AC97CECE2DA98D41012FA449DD1A@SJCPMAILBOX01.citrite.net>
References: 
 <B1DF26ECC0458748AC97CECE2DA98D41012FA449DD1A@SJCPMAILBOX01.citrite.net>
Date: Fri, 25 Jan 2013 22:15:04 -0700
Message-ID: 
 <CALFpzo52DEHti0TuyW6E6r3jGzLYApXg0Nr4nvTaMDHc4q5yaw@mail.gmail.com>
Subject: Re: [MERGE][ACS41] javelin to master
From: Marcus Sorensen <shadowsor@gmail.com>
To: cloudstack-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=bcaec51b15e574d50a04d42a20d2

--bcaec51b15e574d50a04d42a20d2
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jan 25, 2013 at 9:43 PM, Alex Huang <Alex.Huang@citrix.com> wrote:

> >
> > We are requesting merge from javelin to master.  We have merged all
> > changes from master as of 1/24/2013.  Will do another merge to make sure
> > javelin is updated once it's passed the 72 hours.
> >
> > The content of the merge is the storage framework refactoring and
> > converting everything use Spring.  The storage refactoring is put in as
> an
> > independent piece that is not hooked into CloudStack yet.  Edison is
> working
> > on the hookins in another branch.  We like to get this into 4.1 because
> several
> > of the components added to Cloudstack will require the Spring framework
> or
> > they have to be redone.
>

For mt own clarification, the storage refactoring code is in javelin, but
cloudstack is currently not using it, correct? At this point I was thinking
to myself that the storage refactor was not going to make 4.1, due to some
of the discussions and updates. Or if it did that we wouldn't have time to
work on making anything utilize it.

So at least for the storage part, it sounds like the storage refactor code
will be there, but it's still a question on whether it will be hooked in
for 4.1 (I assume). By voting to merge this are we committing to having to
potentially push back code freeze if the things you mention don't get fixed
in time, or if this means that we have to wait for the storage hook-up
branch?

Are you saying there is stuff already in master that will be broken without
Spring, or that other feature branches (besides the storage refactor) rely
on it?


> >
> > Javelin has been checked with marvin integration testing to make sure the
> > server behaves the same.  skipTests has been turned off and the unit
> tests
> > are running clean.  Non-oss is also converted over but there might be a
> small
> > issue with VmWare.  Usage and awsapi also have small issues but we
> believe
> > we can fix those within the 72 hour waiting period.


Is the integration coverage good enough now that we trust it for a change
this large? Not to be pessimistic, and perhaps this has nothing to do with
the merge request itself, but two weeks ago when we were trying to add a
test to the test_volumes.py we found that it was only partially working to
begin with. Ryan fixed that one up. So I'm wondering if the integration
testing worked because the tests have been fixed up, or if you just mean
that the results are the same (tests that failed before still fail,
successes still succeed).

>
> > --Alex
>
>

--bcaec51b15e574d50a04d42a20d2--