[jira] [Commented] (CASSANDRA-5322) Make dtest logging more granular

["Ryan McGuire (JIRA)" <ji...@apache.org>]

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

Ryan McGuire commented on CASSANDRA-5322:
-----------------------------------------

Pasting what I wrote from an offline discussion:

I think there is a bit of ambiguity in the original request: There's logging in the python code for dtests, and there's logging in cassandra itself. The conf/log4-server.properties that Brandon mentioned is in C* (not dtests) for controlling how much logging a single C* class generates. The only problem with it, is that since it's a static file, the classes that it sets to DEBUG will be spewing out lots of logs over the course of every test that dtests defines. If I understand Brandon's request, he wants a way so that we turn on debugging for a single C* class for the duration of a single dtest only.

To do that we need to make dtests (or possibly ccm) check for an environment variable to turn on a different debugging strategy for a given dtest. Here's my idea:

We have the default conf/log4-server.properties file, we make a copy of that file someplace for each dtest configuration we need. Let's assume that the upgrade_through_versions_test.py exercises the org.apache.cassandra.io.sstable.SSTableMetadata class and we want to debug that (I don't know that it actually does, this is just an example.) We don't necessarily want that class to output debugging for all dtests, just upgrade_through_versions_test.py. So we make a copy of conf/log4-server.properties and add debugging for SSTableMetadata. Then we create an environment variable like this: DTEST_LOG4_PROPERTIES=upgrade_through_versions_test:/path/to/our/modified_log4-server.properties|some_other_test:/path/to/another/properties . Dtests (or ccm) takes that environment variable and when it finds it specifies an alternate config for a dtest, it uses the alternate log4-server.properties file when starting up C*.

Since we're invoking ccm's cluster.populate() directly in the dtests I see two options:

* Add this environment variable check and config file swap inside ccm
* Refactor all of the cluster.populate() calls to a dtest utility function that creates the cluster in the way we want (adds the right log4j-server.properties file to each node.)

The former is easier, but it adds complexity to ccm. The second way means we have to refactor pretty much all of our tests, but it gives dtests more control over the environment, which I think is a win.
                
> 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