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 Plain View
HBase >> mail # dev >> Move TestReplication out of LargeTests into hbase-it instead?


+
Andrew Purtell 2012-12-20, 19:54
+
Jesse Yates 2012-12-20, 20:01
+
Stack 2012-12-20, 21:31
+
Ted Yu 2012-12-20, 21:33
+
Nick Dimiduk 2012-12-20, 22:17
Copy link to this message
-
Re: Move TestReplication out of LargeTests into hbase-it instead?
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
>
+
Andrew Purtell 2012-12-20, 23:52
+
Andrew Purtell 2012-12-20, 23:55
+
Enis Söztutar 2012-12-21, 00:03
+
Stack 2012-12-21, 18:37
+
Stack 2013-01-08, 20:23
+
Enis Söztutar 2013-01-08, 21:10
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