cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Zarutin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5322) Make dtest logging more granular
Date Fri, 17 May 2013 09:11:16 GMT

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

Alex Zarutin commented on CASSANDRA-5322:
-----------------------------------------

Hello Sylvain

My name is Alex Zarutin, just recently joined DataStax as SDET. I am working on JIRA ticket,
https://issues.apache.org/jira/browse/CASSANDRA-5322 please see it for details. The idea behind
this ticket is ability to turn on/off logging by making changes in Cassandra <instance>/conf/log4j-server.properties
during the time, cassandra-dtest tests are running.

So workflow of this task is create the cluster ( = ccm create -v 1.1.9 test-1.1.9) => populate
number of the nodes ( = ccm populate -n 3) => update the log4j-server.properties to the
new one => startup the cluster (= ccm start) - reasonably simple. For the cassandra-dtest,
it is implemented in its base class that is inherited in each test's derived class.

The question is the implementation. I discussed it to Brandon and Ryan, and we have two options:

I) Since updating log4j-server.properties is the part of the cluster configuration, we implement
updatelog4jconfig as a command in ccm ( as ccm <node_name> updatelog4jconfig <new
log4j config file> ). So, inside the test, just before initialization the base class, we
specify the path of new log4j config, "pass" it into the base class, and execute cluster.updatelog4jconfig()
there.

II) Upon the fact to do not overload the functionality of ccm, alternative solution is do
not modify ccm at all, and do all the work inside base class of cassandra-dtest tests such
as create the cluster, etc, and just before starting it, we call node.get_path(), and just
copy log4j-server.properties under each node by using the basic python methods, and after
that startup the cluster using cluster.start()

Ryan, Brandon, and me discussed about these options and we have a controversial opinions and
I would like to get your input of what you think of how to implement it better, since you
are the original author of ccm.

Thanks,
Alex 
                
> Make dtest logging more granular 
> ---------------------------------
>
>                 Key: CASSANDRA-5322
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5322
>             Project: Cassandra
>          Issue Type: Test
>            Reporter: Ryan McGuire
>            Assignee: Alex Zarutin
>
> From Brandon: We need a way (might need to go in ccm, I haven't looked) to just set one
class to DEBUG or TRACE, like we'd do in conf/log4-server.properties but with an env var preferably,
so I can control it via buildbot, since it's better at reproducing some issues than I am sometimes,
but I don't want to run the full hammer debug all the time. Also, a way to set Tester.allow_log_errors
to false via an env var, since sometimes there's an error there that takes a while to fix
but is cosmetic, and in the meantime I want to catch new failures so we don't fall behind.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message