[
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
