cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philip Thompson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8557) Default install from tarball is a bit puzzling
Date Sun, 04 Jan 2015 01:32:34 GMT

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

Philip Thompson commented on CASSANDRA-8557:
--------------------------------------------

bq. 4. Why does cassandra-cli exist? It even tells the user "This is being deprecated." It's
confusing figuring out whether to use cqlsh or cassandra-cli.
cassandra-cli is being removed in Cassandra 3.0. It currently exists as it provides a different
interface to Cassandra than cqlsh, and some existing users from old versions still rely on
its functionality. How can we improve the deprecation message to make it clearer that cqlsh
should be used? 

bq. 5. Running the cassandra script creates a background job that keeps running--if you control-c
the script, the process continues running.

If you want the process to be launched in the foreground, use the -f flag. It may be possible
for the CassandraDaemon, once launched, to check if the launch script was user-terminated,
and if so, terminate itself.

6 and 8 sound like valid documentation problems and should be fixed. Hopefully someone else
should be able to explain why the default values are the way they are for 1, 2, and 3.

> Default install from tarball is a bit puzzling
> ----------------------------------------------
>
>                 Key: CASSANDRA-8557
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8557
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Config, Tools
>         Environment: Tested with Crunchbang Waldorf built on Debian 7 Wheezy.
> Java version:
> {noformat}
> $ java -version
> java version "1.8.0_25"
> Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
> {noformat}
> Python version:
> {noformat}
> $ python --version
> Python 2.7.3
> {noformat}
> I suspect this applies to all *nix tarball installs.
>            Reporter: Chris E
>              Labels: documentation, easyfix
>
> The default tarball installation of Apache Cassandra is kind of confusing for a newcomer.
> There are several different points of confusion:
> 1. The default installation doesn't allow remote connections.
> 2. The config file (cassandra.yaml) specifies the use of the AllowAllAuthenticator. This
is almost immmediately replaced during setup by the PasswordAuthenticator. Why not start there?
> 3. The config file (cassandra.yaml) specifies the use of the AllowAllAuthorizer. This
is almost immediately replaced during setup by the CassandraAuthorizer. Why not start there?
> 4. Why does cassandra-cli exist? It even tells the user "This is being deprecated." It's
confusing figuring out whether to use cqlsh or cassandra-cli.
> 5. Running the cassandra script creates a background job that keeps running--if you control-c
the script, the process continues running.
> 6. The config file (cassandra.yaml) has rpc_interface and rpc_address, and the docs there
don't spell out that that address is *also* required for using remote logins from cqlsh.
> 7. On a freshly-created VM, the localhost flag to rpc_address doesn't appear to work
(though this may be due to a misconfiguration of the VM). It seems to need the assigned IP
address of the VM to get it accepting external connections.
> 8. The config file (cassandra.yaml) has the request_scheduler using NoScheduler--which
is fine, but the docs are unclear as to whether or not this means that client requests won't
be scheduled (at all).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message