Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of imusayev@webmd.net designates
 65.55.88.14 as permitted sender)
Received-SPF: softfail (mail216-tx2: transitioning domain of webmd.net does
 not designate 207.138.251.40 as permitted sender) client-ip=207.138.251.40;
 envelope-from=imusayev@webmd.net;
 helo=exht02l-crp-03.webmdhealth.net ;mdhealth.net ;
From: "Musayev, Ilya" <imusayev@webmd.net>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Subject: RE: [MERGE] Merge VMSync improvement branch into master
Thread-Topic: [MERGE] Merge VMSync improvement branch into master
Thread-Index: 
 AQHOa3wLaYFPvoRw3UWwONcT7pqJbZk6lwaA//+Vj4CAAIxvgP//sS+AgABW++CAAZPdgIAMsrKAgAADsYCAASoPgP//z4TwAAjyXoAABAyGgAADlQWAAAFb8QAAAK/VAAAck5QAABc81wAAfaHk8A==
Date: Mon, 1 Jul 2013 17:15:51 +0000
Message-ID: 
 <D2EE6B3265AD864EB3EA4F5C670D256F2700170F@EXMBX01L-CRP-03.webmdhealth.net>
References: 
 <2C97F788CCC013428671BC3A5FC2F64D230AC0@c-mail.cloud-valley.com.cn>
 <CDE62E71.49FEF%kelven.yang@citrix.com>
 <20CF38CB4385CE4D9D1558D52A0FC058054975@SJCPEX01CL03.citrite.net>
 <7CE78D93-BC4C-4C7B-BF09-D7D8A0FBCC9C@GMAIL.com>
 <EE761693-A8B3-4879-AA02-87228326590D@basho.com>
 <D2EE6B3265AD864EB3EA4F5C670D256F26FFD41A@EXMBX01L-CRP-03.webmdhealth.net>
 <8045747C-D690-4044-B6AF-E295694BA43E@basho.com>
 <B590F667-9833-40E9-9047-03831AC1AF92@GMAIL.com>
 <CAKprHVZZcJgXO4=ufOfx7P+K-CWPirKcM06_vM7XrutNwK7Z=Q@mail.gmail.com>
 <8320619886336370178@unknownmsgid>
 <C1BB04E0-E291-4C13-B983-4A59C00B6EB2@GMAIL.com>
 <07B22C5ED940BF49B3438A3983DB57750758F0@SJCPEX01CL03.citrite.net>
 <20CF38CB4385CE4D9D1558D52A0FC058056D25@SJCPEX01CL03.citrite.net>
In-Reply-To: <20CF38CB4385CE4D9D1558D52A0FC058056D25@SJCPEX01CL03.citrite.net>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Alex,

I completely understand. Please keep us in the loop on the progress. If its=
 functional to some extent - i.e. at least build succeeds without errors an=
d major functionality is there, I can merge the code into CloudSand CS dist=
ro - to test it out and share it with whoever wants to try it.=20

Thanks
ilya

> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Friday, June 28, 2013 9:16 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [MERGE] Merge VMSync improvement branch into master
>=20
> Given the current state of BVT, I don't think we can reliably merge this =
into
> master.  It will have to wait for 4.3.  I apologize to those who really w=
ant to
> see this feature in.  I myself have slaved over this for some weeks, incl=
uding
> missing the collab conference, but I just cannot conscientiously push it =
in
> under the current circumstances.
>=20
> --Alex
>=20
> > -----Original Message-----
> > From: Sudha Ponnaganti [mailto:sudha.ponnaganti@citrix.com]
> > Sent: Friday, June 28, 2013 7:11 AM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [MERGE] Merge VMSync improvement branch into master
> >
> > Ideally I would like to see all validation to be done on feature
> > branch - BVTs and also manual validation of the P1 test cases from VM
> > Sync test plan just like object store validation - sadhu has signed up
> > for it along with Ilya. This would help us to identify feature specific=
 issues.
> >
> > We are running BVTs right now which have high failure rate. Focusing
> > on this part right now to reach parity with Master branch.
> >
> >
> > -----Original Message-----
> > From: Trippie [mailto:trippie@gmail.com] On Behalf Of Hugo Trippaers
> > Sent: Thursday, June 27, 2013 5:32 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [MERGE] Merge VMSync improvement branch into master
> >
> > I agree with John that a change like this is very hard to test in an
> > automated fashion. Still i have been looking at the numbers for the
> > code coverage with cobertura. I was a bit disappointed to find that we
> > have not made any progress with this merge with regards to unit tests a=
nd
> total code coverage.
> > We do not seem to be in a worse shape than before.
> >
> > @Sudha, it would be nice if you could add your view on this patch from
> > the QA perspective? How would this patch affect your planning for
> example?
> >
> > Cheers,
> >
> > Hugo
> >
> > On Jun 27, 2013, at 5:12 PM, John Burwell <jburwell@basho.com> wrote:
> >
> > > @David The types of concurrency changes introduced in this patch are
> > > extremely difficult to completely test in an automated fashion.
> > > Therefore, code review for correctness is critical to ensure quality.
> > > To be clear, I am not questioning the value of automated testing.  I
> > > am just noting that it's next to impossible to achieve full
> > > coverage, and code review is an critical supplement.
> > >
> > > @Ilya I plan to review this patch, but I will be able to start until
> > > next week.  I am also still reviewing object_store (a separate
> > > procedural issue for another thread), and need to complete solidfire.
> > > This backlog is precisely why need to be reviewing iteratively
> > > throughout the dev cycle.
> > >
> > > Thanks,
> > > -John
> > >
> > > On Jun 27, 2013, at 7:35 PM, David Nalley <david@gnsa.us> wrote:
> > >
> > >> On Thu, Jun 27, 2013 at 5:51 PM, Hugo Trippaers <hugo@trippaers.nl>
> > wrote:
> > >>>
> > >>> I think Ilya offers is great, my current stance is also to see how
> > >>> we can
> > bring this forward.
> > >>>
> > >>> I've had the opportunity to meet with several people at the Citrix
> > >>> office
> > in Santa Clara, i'm actually working from their office at this moment.
> > I think it's also the responsibility of someone who put in a -1 to
> > work with the original committer to get the situation resolved. So
> > i'll invest the time to help with the review as well.
> > >>>
> > >>> It would be great if Alex or Kelven could take the time to explain
> > >>> how
> > this feature has been tested. That would give the community some
> > insight as well.
> > >>>
> > >>> My main technical problem with this merge is that stuff is moving
> > >>> all over
> > the place without having even the slightest idea why. Now having
> > discussed this with Alex in person i get the general idea of this
> > merge, so can actually try to review it.
> > >>>
> > >>> I think that John have nicely explained what we could do to
> > >>> prevent
> > situations like this in advance. I fully understand that big features
> > or rewrites don't happen overnight and might show up near the end of th=
e
> release cycle.
> > With the time based release cycle it's always a risk that some feature
> > might not make it in on time. Getting more people involved and
> > chunking the commits into master will greatly speed up the reviewing
> process.
> > >>>
> > >>> I'll get back to this after spending some time on reviewing the
> > >>> actual
> > patch. In fact i would like to ask more people to have a look at this
> > patch and reply to this thread with comments or remarks.
> > >>>
> > >>> Cheers,
> > >>>
> > >>> Hugo
> > >>
> > >> So the problem in my mind, is that we don't have a way of verifying
> > >> that master isn't broken, and won't be broken by any given merge. I
> > >> look at even the minimal level of automated testing that I see
> > >> today, and ~20% of integration tests are failing[1]. The regression
> > >> set of tests (which isn't running as often) is seeing 75% of tests
> > >> failing[2]. Heaping on more change when we are demonstrably already
> > >> failing in many places is not behaving responsibly IMO.
> > >> The question I'd pose is this - running the various automated tests
> > >> is pretty cheap - whats the output of that compared to the current
> > >> test output on master? Better or worse? If it hasn't been done, why
> not?
> > >> I desperately want these features, but not necessarily at the cost
> > >> of further destabilizing what we have now in master - we can't
> > >> continue accruing technical debt.
> > >>
> > >> --David
> > >>
> > >> [1]
> > >> http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-ma
> > >> tr ix/lastCompletedBuild/testReport/ [2]
> > >> http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-regressi
> > >> on
> > >> -matrix/28/testReport/
>=20