Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Move TestReplication out of LargeTests into hbase-it instead?


Copy link to this message
-
Re: Move TestReplication out of LargeTests into hbase-it instead?
Given that this is the replication test, I would expect that it needs at
least two clusters. It is definitely possible to port this to hbase-it, but
some work might be needed.
On Thu, Dec 20, 2012 at 3:55 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> Any interest in setting up a consortium for a HBase testing facility? We
> can't make point contributions to ASF to go to a specific project, but it's
> not unreasonable to suggest a couple HBase dev shops could pitch in a few
> bucks a month for project administered EC2 account for spinning up
> hbase-it. (This would be minimum viable I think, EC2 is ok for functional
> and smoke testing at least.)
>
>
> On Thu, Dec 20, 2012 at 3:52 PM, Andrew Purtell <[EMAIL PROTECTED]>
> wrote:
>
> > This test is obviously not helpful as is. We're not losing coverage by
> > moving it out to integration tests. We're gaining sanity though.
> >
> >
> > On Thu, Dec 20, 2012 at 3:49 PM, Jesse Yates <[EMAIL PROTECTED]
> >wrote:
> >
> >> On Thu, Dec 20, 2012 at 1:31 PM, Stack <[EMAIL PROTECTED]> wrote:
> >>
> >> > On Thu, Dec 20, 2012 at 12:01 PM, Jesse Yates <
> [EMAIL PROTECTED]
> >> > >wrote:
> >> >
> >> > > Not being intimately familiar with the replication tests, how well
> >> > covered
> >> > > on that stuff are we by the remaining unit tests? Also, since the
> >> > hbase-it
> >> > > tests still get run, are we really gaining anything in terms of CI
> >> > > reliability?
> >> > >
> >> >
> >> > The hbase-it tests are not run up on jenkins Jesse, not at the moment
> at
> >> > least.
> >> >
> >> >
> >> I'm just a bit worried that we will break things and not have it caught
> on
> >> check-in (the real arbiter of what's a valid patch), meaning we will
> break
> >> the branch without realizing. :-/ We need some way to ensure that the
> >> underlying code is covered.
> >>
> >> At the minimum it needs to be part of the release checklist that we run
> >> the
> >> replication IT test on two real clusters (assuming this is a black-box
> >> test
> >> and not messing with things too much). I don't expect needing more than
> >> small functional clusters (say max 5 nodes?) to test this adequately.
> The
> >> Jenkins machines don't seem sufficient for this, so my gut feel is that
> it
> >> will have to be a release item that the RM needs to verify works (either
> >> personally or by proxy). This could even apply to all the hbase-it, for
> >> releases going forward
> >>
> >> Ideally, we will also have some unit tests that subsume some of the
> tested
> >> functionality when/if we move them to a more infrequent tests, though
> its
> >> hard to say how possible/useful this would be to manage in practice.
> >>
> >> Short term, maybe we disable them and file a Jira to get them rock solid
> >> (or on -it and tested regularly somehow)? This goes back to the long
> >> standing discussion that we should disable flappers until they tell us
> >> something useful.
> >>
> >> Again don't know those tests very well, so these are just general
> >> platitudes :)
> >>
> >>
> >> > Agree to moving TestReplication and perhaps some of the mapreduce
> tests
> >> out
> >> > of unit test core.
> >> >
> >> > That means we should set up a regular run of hbase-it tests somewhere
> >> > though?
> >> >
> >> > St.Ack
> >> >
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB