You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Peter Schuller (Created) (JIRA)" <ji...@apache.org> on 2011/12/04 05:16:40 UTC
[jira] [Created] (CASSANDRA-3570) barrier-of-entry: make
./bin/cassandra -f work out of the box by changing default cassandra.yaml
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
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
[jira] [Commented] (CASSANDRA-3570) barrier-of-entry: make
./bin/cassandra -f work out of the box by changing default cassandra.yaml
Posted by "Jonathan Ellis (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163283#comment-13163283 ]
Jonathan Ellis commented on CASSANDRA-3570:
-------------------------------------------
As the only? committer not using a Unix-based primary workstation, I suppose it falls to me to point out that /var/* is not a cross-platform standard either.
> 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
[jira] [Commented] (CASSANDRA-3570) barrier-of-entry: make
./bin/cassandra -f work out of the box by changing default cassandra.yaml
Posted by "Peter Schuller (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162295#comment-13162295 ]
Peter Schuller 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.
And note that this JIRA isn't just about that paragraph you quoted.
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".
> 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
[jira] [Resolved] (CASSANDRA-3570) barrier-of-entry: make
./bin/cassandra -f work out of the box by changing default cassandra.yaml
Posted by "Peter Schuller (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Schuller resolved CASSANDRA-3570.
---------------------------------------
Resolution: Won't Fix
WONTFIX due to lack of buy-in.
> 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
[jira] [Commented] (CASSANDRA-3570) barrier-of-entry: make
./bin/cassandra -f work out of the box by changing default cassandra.yaml
Posted by "Eric Evans (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164403#comment-13164403 ]
Eric Evans commented on CASSANDRA-3570:
---------------------------------------
bq. As the only? committer not using a Unix-based primary workstation, I suppose it falls to me to point out that /var/* is not a cross-platform standard either.
Yeah, fair enough. Though if this is something that falls into the category of cant-be-guessed-so-recommend, then an FHS-based recommendation is still the clear choice. Maybe there should be some entries adjacent to these, commented out, which include the corresponding recommended Windows paths.
Also, I just had one other thought. Paths in {{cassandra.yaml}} are all expected to be absolute. The startup scripts are smart enough to work with relative paths when called from elsewhere, but a relative path of db/ placed in {{cassandra.yaml}} will fail unless $PWD at startup is the top-level directory. I know this is meant to optimize for that case, but that's still kind of dodgy.
> 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
[jira] [Commented] (CASSANDRA-3570) barrier-of-entry: make
./bin/cassandra -f work out of the box by changing default cassandra.yaml
Posted by "Peter Schuller (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162622#comment-13162622 ]
Peter Schuller commented on CASSANDRA-3570:
-------------------------------------------
I didn't know about test-run, no. Thanks! I've had some scripts that re-configure and switch around data directories and such that have facilitated switching between versions. But, they were always hacky.
If you're saying people are actually using the default then maybe it's worth keeping. I'm just not seeing who is using it. If you're the developer or user patching manually in the working copy, ./db seems convenient. If you're packaging, you're gonna configure it properly anyway. If you're deploying a non-packaged version, aren't you then also making an active choice as to where you'll put the database?
Anyways, I'm not too fussed. It doesn't affect me all that much. I just remember a couple of times introducing people and it being an annoyance that the very first experience requires you to change settings you don't know anything about, before being able to run it.
Maybe this is different for the binary distribution; honestly I've never even used it :)
Anyway, if there's no +1 soon I'll just WONTFIX this one.
> 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
[jira] [Updated] (CASSANDRA-3570) barrier-of-entry: make
./bin/cassandra -f work out of the box by changing default cassandra.yaml
Posted by "Peter Schuller (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Schuller updated CASSANDRA-3570:
--------------------------------------
Attachment: CASSANDRA_3570-dbpath.txt
> 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
[jira] [Commented] (CASSANDRA-3570) barrier-of-entry: make
./bin/cassandra -f work out of the box by changing default cassandra.yaml
Posted by "Eric Evans (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162292#comment-13162292 ]
Eric Evans commented on CASSANDRA-3570:
---------------------------------------
bq. 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.
Just playing Devil's advocate here, but is this really optimizing for the new/first-time users, or for someone who does a lot of ad hoc testing?
> 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
[jira] [Commented] (CASSANDRA-3570) barrier-of-entry: make
./bin/cassandra -f work out of the box by changing default cassandra.yaml
Posted by "Eric Evans (Commented) (JIRA)" <ji...@apache.org>.
[ 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