Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Message-ID: <29987418.75761292108522278.JavaMail.jira@thor>
Date: Sat, 11 Dec 2010 18:02:02 -0500 (EST)
From: "Peter Tillotson (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Subject: [jira] Commented: (CASSANDRA-874) System tests against multiple
 nodes
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970537#action_12970537 ] 

Peter Tillotson commented on CASSANDRA-874:
-------------------------------------------

I think that this may already be largely possible via a virtual network, though it presents an ideal case. Libvirt on Linux allows you to set up virtual network interfaces on a given host so you could get multiple instances of Cassandra running on the same local hardware, one could probably simulate failing nodes.
see:  virsh --net-create for examples


> System tests against multiple nodes
> -----------------------------------
>
>                 Key: CASSANDRA-874
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-874
>             Project: Cassandra
>          Issue Type: Test
>          Components: Tools
>            Reporter: Jonathan Ellis
>
> We have a system test suite (see http://wiki.apache.org/cassandra/HowToContribute ) but it only runs against the local machine, which is suboptimal even if we didn't have a bunch of optimizations to make writes to a local node skip most of the messaging layer.
> We'd like to automate testing against a whole cluster.  Paul has some code using libcloud to do stress tests against an ephemeral rackspace cloud servers cluster at http://github.com/pquerna/ccb, which is probably useful as a starting point, but rather than running stress.py you'd want to put together a more comprehensive suite, based on the existing system tests but also explicitly covering things like range queries that span multiple nodes and failure conditions like Hinted Handoff (see http://wiki.apache.org/cassandra/HintedHandoff ) and repair (http://wiki.apache.org/cassandra/ArchitectureAntiEntropy ) resulting from deliberately disabling a node temporarily.
> Adding tests for ops tasks like http://wiki.apache.org/cassandra/Operations would be awesome too.
> Finally, CASSANDRA-561 might make something like this possible using a simulator instead of hardware-level virtualization, which would be both more convenient and less expensive.  But someone just dumped a huge zip in our laps w/o really trying to collaborate with us there, so if you want to try to resurrect that code or otherwise go that route, be more open about what you're doing. :)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.