[
https://issues.apache.org/jira/browse/CASSANDRA-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162433#comment-13162433
]
Eric Evans commented on CASSANDRA-3570:
---------------------------------------
{quote}
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.
{quote}
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 environments.
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: https://issues.apache.org/jira/browse/CASSANDRA-3570
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
