cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Evans (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3570) barrier-of-entry: make ./bin/cassandra -f work out of the box by changing default cassandra.yaml
Date Sun, 04 Dec 2011 18:09:40 GMT


Eric Evans commented on CASSANDRA-3570:

It's that too. And even with proper distributed testing across real clusters, it's still useful
to be able to switch around between different versions and just start Cassandra. Not all testing,
particularly when iterating something, is best done by Super Proper Distributed Test Setup.
In this particular case all I wanted to do was to start Cassandra and test with the latest
version of G1 (looking for very specific behavior), and there is no reason to do the thing
I wanted to do in any any less ad-hoc fashion. I have no trouble admitting that I some times
want to run Cassandra out of my working copy; it is not indicative of bad testing practices
because the two are not mutually exclusive. And it's not just about testing; I have had plenty
of cases where I have been tracking down bugs by repeatedly re-starting a single node-local
Cassandra and watching for debug printouts. There's no reason to make that more complicated
by running said Super Proper Distributed Test Setup.

Are you aware that (on trunk at least) you can simple run {{ant test-run}} from a source tree?

bq. And note that this JIRA isn't just about that paragraph you quoted.

Sorry, I quoted all of it this time. :)

bq. Basically, is anyone helped by the default config being non-usable for non-root? If not,
it seems like a small thing that is just annoying in certain situation that might as well
just be changed. And I won't have to hymn and haw when I can't quite tell someone "Just clone
it, typ ant, and run ./bin/cassandra -f".

A default is just that, default.  There is no possible way to use settings that will work
for everyone, all of the time (if there were, we wouldn't need a config). The aim is to use
what will work for most, most of the time, and to document recommendations for the rest.

The /var/{lib,log}/cassandra paths are the recommendation we've been making to users for production

I'm not saying, "you are wrong, it should be left as-is", I'm asking, "does {{./db}} better
serve a majority of users the majority of time?"  You and I are naturally biased toward the
use-case of ad hoc testing (FWIW, I added the {{test-run}} target specifically for this reason),
so I believe that's a fair question to pose.

> barrier-of-entry: make ./bin/cassandra -f work out of the box by changing default cassandra.yaml
> ------------------------------------------------------------------------------------------------
>                 Key: CASSANDRA-3570
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Peter Schuller
>            Assignee: Peter Schuller
>            Priority: Trivial
>         Attachments: CASSANDRA_3570-dbpath.txt
> This is probably going to be controversial. But how about the attached simple patch to
just have ./db exist, and then have Cassandra configured to use that by default? This makes
it a lot easier for people to just run Cassandra out of the working copy, whether you are
a developer or a user who wants to apply a patch when being assisted by a Cassandra developer.
> A real deployment with packaging should properly override these paths anyway, and the
default /var/lib stuff is pretty useless. Even if you are root on the machine, who it is much
cleaner to just run self-contained.
> Yes, I am aware that you can over-ride the configuration but honestly, that's just painful.
Especially when switching between various versions of Cassandra.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message