[jira] [Assigned] (CASSANDRA-15316) Regarding timestamp documentation

2019-09-30 Thread Tanaka (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tanaka reassigned CASSANDRA-15316:
--

Assignee: Tanaka

> Regarding timestamp documentation
> -
>
> Key: CASSANDRA-15316
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15316
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Pramod
>Assignee: Tanaka
>Priority: Normal
>
> In the documentation, 
> [https://cassandra.apache.org/doc/latest/cql/types.html#working-with-timestamps]
>  
> {color:#1d1c1d}As per the ISO 8601, the dates should be in the form of either 
> MMDD or -MM-DD but the example in the documentation shows 
> -DD-MM{color}
> {color:#1d1c1d}Am I right, if so can the documentation be updated.{color}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Comment Edited] (CASSANDRA-14288) Document compaction-stress

2019-09-12 Thread Tanaka (Jira)


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

Tanaka edited comment on CASSANDRA-14288 at 9/12/19 11:36 AM:
--

[~hkroger] Documentation for Cassandra-stress tool is live on the website: 
[http://cassandra.apache.org/doc/latest/tools/cassandra_stress.html]

(I did not update documentation, just verifying ticket)

This ticket is ready to be resolved.


was (Author: tanakarm):
[~hkroger] Documentation for Cassandra-stress tool is live on the website: 
[http://cassandra.apache.org/doc/latest/tools/cassandra_stress.html]

This ticket is ready to be resolved.

> Document compaction-stress
> --
>
> Key: CASSANDRA-14288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14288
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Hannu Kröger
>Assignee: Tanaka
>Priority: Normal
>
> Cassandra tools section should also document compaction-stress command:
> [http://cassandra.apache.org/doc/latest/tools/index.html]
> Currently it's not documented there.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-14288) Document compaction-stress

2019-09-12 Thread Tanaka (Jira)


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

Tanaka commented on CASSANDRA-14288:


[~hkroger] Documentation for Cassandra-stress tool is live on the website: 
[http://cassandra.apache.org/doc/latest/tools/cassandra_stress.html]

This ticket is ready to be resolved.

> Document compaction-stress
> --
>
> Key: CASSANDRA-14288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14288
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Hannu Kröger
>Assignee: Tanaka
>Priority: Normal
>
> Cassandra tools section should also document compaction-stress command:
> [http://cassandra.apache.org/doc/latest/tools/index.html]
> Currently it's not documented there.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-14012) Document gossip protocol

2019-09-12 Thread Tanaka (Jira)


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

Tanaka commented on CASSANDRA-14012:


[~Wulf4096] This ticket has not been updated in almost 2 years. I found the 
following page about Cassandra's Gossip Protocol: 
[https://cwiki.apache.org/confluence/display/CASSANDRA2/ArchitectureGossip]

Does the information there resolve your issue?

> Document gossip protocol
> 
>
> Key: CASSANDRA-14012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14012
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Jörn Heissler
>Assignee: Tanaka
>Priority: Low
>  Labels: Documentation
>
> I had an issue today with two nodes communicating with each other; there's a 
> flaw in my configuration (wrong broadcast address).
> I saw a little bit of traffic on port 7000, but I couldn't understand it for 
> lack of documentation.
> With documentation I would have understood my issue very quickly (7f 00 01 01 
> is a bad broadcast address!). But I didn't recognize those 4 bytes as the bc 
> address.
> Could you please document the gossip protocol?



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Assigned] (CASSANDRA-14258) document process of changing token count by adding a new DC

2019-09-09 Thread Tanaka (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tanaka reassigned CASSANDRA-14258:
--

Assignee: Tanaka

> document process of changing token count by adding a new DC
> ---
>
> Key: CASSANDRA-14258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14258
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Jon Haddad
>Assignee: Tanaka
>Priority: Normal
>
> also provide warnings around not adding instances of different sizes to try 
> to migrate and why it's horrible.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Assigned] (CASSANDRA-14288) Document compaction-stress

2019-09-09 Thread Tanaka (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tanaka reassigned CASSANDRA-14288:
--

Assignee: Tanaka

> Document compaction-stress
> --
>
> Key: CASSANDRA-14288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14288
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Hannu Kröger
>Assignee: Tanaka
>Priority: Normal
>
> Cassandra tools section should also document compaction-stress command:
> [http://cassandra.apache.org/doc/latest/tools/index.html]
> Currently it's not documented there.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-10248) Document compatibilities between native specs and Cassandra versions

2019-08-16 Thread Tanaka (JIRA)


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

Tanaka commented on CASSANDRA-10248:


[~thibaultcha] Thank you very much for your feedback. I never looked at this 
issue from the perspective of the maintainers of client drivers so thank you 
for pointing that out to me. 

I'm relatively new to the Apache Cassandra community and my mentor advised me 
to look & possibly solve documentation related issues in order to learn more 
about this project. 

Given your feedback, I think I can create such a matrix and submit my feature 
for consideration. 

Take care.

> Document compatibilities between native specs and Cassandra versions
> 
>
> Key: CASSANDRA-10248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10248
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Thibault Charbonnier
>Assignee: Tanaka
>Priority: Low
>  Labels: documentation
>
> Nowhere in the native specs is specified for which Cassandra version it is 
> compatible with. This has been confusing to me when implementing a given 
> protocol in a Lua driver, and has apparently been confusing other people [1].
> I remember seeing a table specifying which specs were compatible with which 
> Cassandra version somewhere in the Python driver documentation but I am 
> currently unable to find it.
> Proposed solution: maybe include a small table in each specification file 
> describing the compatibilities between Cassandra and the current (and 
> eventually older) specs.
> [1] 
> http://mail-archives.apache.org/mod_mbox/cassandra-dev/201504.mbox/%3ca87729c9-fa6a-4b34-bb7b-b324e154c...@datastax.com%3E



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13753) The documentation website can be fitted well on device width.

2019-08-16 Thread Tanaka (JIRA)


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

Tanaka commented on CASSANDRA-13753:


[~ashish1269] Hi. So I went through some of the issues expressed on this ticket

1) Went through the provided link on different laptops with different 
resolutions (Mac & PC) and I did not have to scroll horizontally. 

2) When I scroll to the bottom of the documentation pages, it doesn't shoot me 
back up.

3) Spent some time going through the website on mobile. It's not the best 
mobile experience I've ever had but I wouldn't say it is not mobile-friendly.

Granted this ticket was created 2 years ago so maybe in that changes were made 
& this ticket wasn't updated?

> The documentation website can be fitted well on device width.
> -
>
> Key: CASSANDRA-13753
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13753
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
> Environment: *Operating System : *Ubuntu
> *Browsers: *
> * Firefox
> * Google Chrome
>Reporter: Ashish Tomer
>Assignee: Ashish Tomer
>Priority: Low
>  Labels: Responsive, UI, documentation, website
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> The following shortcomings/ issues are noticed on the pages of cassandra 
> documentation website ([http://cassandra.apache.org/doc/latest/])
> *1.* On laptop screen with resolution 1366 × 768 the width of the 
> webpage is more than the width of the screen. The content of the website is 
> going left and user has to scroll horizontally to read the lines. The 
> horizontal scrollbar at the bottom needs to be removed.
> *2.* When some pages are scrolled down the whole page fluctuate and jump back 
> to top of the page. {color:red}Example link - 
> {color}[http://cassandra.apache.org/doc/latest/architecture/overview.html]
> *3.* The website is not mobile friendly and can be made responsive.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Comment Edited] (CASSANDRA-10248) Document compatibilities between native specs and Cassandra versions

2019-08-16 Thread Tanaka (JIRA)


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

Tanaka edited comment on CASSANDRA-10248 at 8/16/19 1:19 PM:
-

[~thibaultcha] [~benedict] In regards to this issue, every driver on this page: 
[Client 
Drivers|[http://cassandra.apache.org/doc/latest/getting_started/drivers.html?highlight=python]]
 has documentation that states what version of Apache Cassandra is compatible 
with each driver but it is hosted on their own websites/repos. Do you think it 
makes sense to have the compatibility tables on Cassandra's official documents? 


was (Author: tanakarm):
[~thibaultcha] In regards to this issue, every driver on this page: [Client 
Drivers|[http://cassandra.apache.org/doc/latest/getting_started/drivers.html?highlight=python]]
 has documentation that states what version of Apache Cassandra is compatible 
with each driver but it is hosted on their own websites/repos. Do you think it 
makes sense to have the compatibility tables on Cassandra's official documents? 

> Document compatibilities between native specs and Cassandra versions
> 
>
> Key: CASSANDRA-10248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10248
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Thibault Charbonnier
>Assignee: Tanaka
>Priority: Low
>  Labels: documentation
>
> Nowhere in the native specs is specified for which Cassandra version it is 
> compatible with. This has been confusing to me when implementing a given 
> protocol in a Lua driver, and has apparently been confusing other people [1].
> I remember seeing a table specifying which specs were compatible with which 
> Cassandra version somewhere in the Python driver documentation but I am 
> currently unable to find it.
> Proposed solution: maybe include a small table in each specification file 
> describing the compatibilities between Cassandra and the current (and 
> eventually older) specs.
> [1] 
> http://mail-archives.apache.org/mod_mbox/cassandra-dev/201504.mbox/%3ca87729c9-fa6a-4b34-bb7b-b324e154c...@datastax.com%3E



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-10248) Document compatibilities between native specs and Cassandra versions

2019-08-15 Thread Tanaka (JIRA)


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

Tanaka commented on CASSANDRA-10248:


[~thibaultcha] In regards to this issue, every driver on this page: [Client 
Drivers|[http://cassandra.apache.org/doc/latest/getting_started/drivers.html?highlight=python]]
 has documentation that states what version of Apache Cassandra is compatible 
with each driver but it is hosted on their own websites/repos. Do you think it 
makes sense to have the compatibility tables on Cassandra's official documents? 

> Document compatibilities between native specs and Cassandra versions
> 
>
> Key: CASSANDRA-10248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10248
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Thibault Charbonnier
>Assignee: Tanaka
>Priority: Low
>  Labels: documentation
>
> Nowhere in the native specs is specified for which Cassandra version it is 
> compatible with. This has been confusing to me when implementing a given 
> protocol in a Lua driver, and has apparently been confusing other people [1].
> I remember seeing a table specifying which specs were compatible with which 
> Cassandra version somewhere in the Python driver documentation but I am 
> currently unable to find it.
> Proposed solution: maybe include a small table in each specification file 
> describing the compatibilities between Cassandra and the current (and 
> eventually older) specs.
> [1] 
> http://mail-archives.apache.org/mod_mbox/cassandra-dev/201504.mbox/%3ca87729c9-fa6a-4b34-bb7b-b324e154c...@datastax.com%3E



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-8557) Default install from tarball is a bit puzzling

2019-08-02 Thread Tanaka (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-8557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tanaka updated CASSANDRA-8557:
--
Labels: doc-impacting documentation easyfix  (was: documentation easyfix)

> 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: Legacy/Tools, Local/Config
> 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
>Assignee: Tanaka
>Priority: Low
>  Labels: doc-impacting, 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
(v7.6.14#76016)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Comment Edited] (CASSANDRA-8557) Default install from tarball is a bit puzzling

2019-08-02 Thread Tanaka (JIRA)


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

Tanaka edited comment on CASSANDRA-8557 at 8/2/19 1:59 PM:
---

 
{quote}1. The default installation doesn’t allow remote connections
{quote}
 
 * There is no mention of setting up remote access on the installation page
 * Follow this guide: [Setting up Cassandra for remote access · 
GitHub|https://gist.github.com/andykuszyk/7644f334586e8ce29eaf8b93ec6418c4]
 * Follow this guide to JMX remote access: 
[Documentation|http://cassandra.apache.org/doc/latest/operating/security.html?highlight=remote%20access]

 
{quote}2. The config file (cassandra.yaml) specifies the use of the 
AllowAllAuthenticator. This is almost immediately replaced during setup by the 
PasswordAuthenticator. Why not start there?
{quote}
 
 * Cassandra ships with two options included in the default distribution.
 * By default, Cassandra is configured with AllowAllAuthenticator which 
performs no authentication checks and therefore requires no credentials. It is 
used to disable authentication completely. Note that authentication is a 
necessary condition of Cassandra’s permissions subsystem, so if authentication 
is disabled, effectively so are permissions.
 * The default distribution also includes PasswordAuthenticator, which stores 
encrypted credentials in a system table. This can be used to enable simple 
username/password authentication.

 
{quote}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?
{quote}
 
 * Cassandra ships with two options included in the default distribution.
 * By default, Cassandra is configured with AllowAllAuthorizer which performs 
no checking and so effectively grants all permissions to all roles. This must 
be used if AllowAllAuthenticator is the configured authenticator.
 * The default distribution also includes CassandraAuthorizer, which does 
implement full permissions management functionality and stores its data in 
Cassandra system tables.


was (Author: tanakarm):
 
{quote}1. The default installation doesn’t allow remote connections
{quote} * There is no mention of setting up remote access on the installation 
page

 * Follow this guide: [Setting up Cassandra for remote access · 
GitHub|https://gist.github.com/andykuszyk/7644f334586e8ce29eaf8b93ec6418c4]
 * Follow this guide to JMX remote access: 
[Documentation|http://cassandra.apache.org/doc/latest/operating/security.html?highlight=remote%20access]

 
{quote}2. The config file (cassandra.yaml) specifies the use of the 
AllowAllAuthenticator. This is almost immediately replaced during setup by the 
PasswordAuthenticator. Why not start there?
{quote} * Cassandra ships with two options included in the default distribution.

 * By default, Cassandra is configured with AllowAllAuthenticator which 
performs no authentication checks and therefore requires no credentials. It is 
used to disable authentication completely. Note that authentication is a 
necessary condition of Cassandra’s permissions subsystem, so if authentication 
is disabled, effectively so are permissions.
 * The default distribution also includes PasswordAuthenticator, which stores 
encrypted credentials in a system table. This can be used to enable simple 
username/password authentication.

 
{quote}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?
{quote} * Cassandra ships with two options included in the default distribution.

 * By default, Cassandra is configured with AllowAllAuthorizer which performs 
no checking and so effectively grants all permissions to all roles. This must 
be used if AllowAllAuthenticator is the configured authenticator.
 * The default distribution also includes CassandraAuthorizer, which does 
implement full permissions management functionality and stores its data in 
Cassandra system tables.

> 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: Legacy/Tools, Local/Config
> 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
>   

[jira] [Comment Edited] (CASSANDRA-8557) Default install from tarball is a bit puzzling

2019-08-02 Thread Tanaka (JIRA)


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

Tanaka edited comment on CASSANDRA-8557 at 8/2/19 1:55 PM:
---

 
{quote}1. The default installation doesn’t allow remote connections
{quote} * There is no mention of setting up remote access on the installation 
page

 * Follow this guide: [Setting up Cassandra for remote access · 
GitHub|https://gist.github.com/andykuszyk/7644f334586e8ce29eaf8b93ec6418c4]
 * Follow this guide to JMX remote access: 
[Documentation|http://cassandra.apache.org/doc/latest/operating/security.html?highlight=remote%20access]

 
{quote}2. The config file (cassandra.yaml) specifies the use of the 
AllowAllAuthenticator. This is almost immediately replaced during setup by the 
PasswordAuthenticator. Why not start there?
{quote} * Cassandra ships with two options included in the default distribution.

 * By default, Cassandra is configured with AllowAllAuthenticator which 
performs no authentication checks and therefore requires no credentials. It is 
used to disable authentication completely. Note that authentication is a 
necessary condition of Cassandra’s permissions subsystem, so if authentication 
is disabled, effectively so are permissions.
 * The default distribution also includes PasswordAuthenticator, which stores 
encrypted credentials in a system table. This can be used to enable simple 
username/password authentication.

 
{quote}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?
{quote} * Cassandra ships with two options included in the default distribution.

 * By default, Cassandra is configured with AllowAllAuthorizer which performs 
no checking and so effectively grants all permissions to all roles. This must 
be used if AllowAllAuthenticator is the configured authenticator.
 * The default distribution also includes CassandraAuthorizer, which does 
implement full permissions management functionality and stores its data in 
Cassandra system tables.


was (Author: tanakarm):
{quote}1. The default installation doesn’t allow remote connections
{quote} * There is no mention of setting up remote access on the installation 
page
 * Follow this guide: [Setting up Cassandra for remote access · 
GitHub|https://gist.github.com/andykuszyk/7644f334586e8ce29eaf8b93ec6418c4]
 * Follow this guide to JMX remote access: 
[Documentation|http://cassandra.apache.org/doc/latest/operating/security.html?highlight=remote%20access]

 
{quote}2. The config file (cassandra.yaml) specifies the use of the 
AllowAllAuthenticator. This is almost immediately replaced during setup by the 
PasswordAuthenticator. Why not start there?
{quote} * Cassandra ships with two options included in the default distribution.
 * By default, Cassandra is configured with AllowAllAuthenticator which 
performs no authentication checks and therefore requires no credentials. It is 
used to disable authentication completely. Note that authentication is a 
necessary condition of Cassandra’s permissions subsystem, so if authentication 
is disabled, effectively so are permissions.
 * The default distribution also includes PasswordAuthenticator, which stores 
encrypted credentials in a system table. This can be used to enable simple 
username/password authentication.

 
{quote}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?
{quote} * Cassandra ships with two options included in the default distribution.
 * By default, Cassandra is configured with AllowAllAuthorizer which performs 
no checking and so effectively grants all permissions to all roles. This must 
be used if AllowAllAuthenticator is the configured authenticator.
 * The default distribution also includes CassandraAuthorizer, which does 
implement full permissions management functionality and stores its data in 
Cassandra system tables.

> 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: Legacy/Tools, Local/Config
> 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
>Assig

[jira] [Commented] (CASSANDRA-8557) Default install from tarball is a bit puzzling

2019-08-02 Thread Tanaka (JIRA)


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

Tanaka commented on CASSANDRA-8557:
---

{quote}1. The default installation doesn’t allow remote connections
{quote} * There is no mention of setting up remote access on the installation 
page
 * Follow this guide: [Setting up Cassandra for remote access · 
GitHub|https://gist.github.com/andykuszyk/7644f334586e8ce29eaf8b93ec6418c4]
 * Follow this guide to JMX remote access: 
[Documentation|http://cassandra.apache.org/doc/latest/operating/security.html?highlight=remote%20access]

 
{quote}2. The config file (cassandra.yaml) specifies the use of the 
AllowAllAuthenticator. This is almost immediately replaced during setup by the 
PasswordAuthenticator. Why not start there?
{quote} * Cassandra ships with two options included in the default distribution.
 * By default, Cassandra is configured with AllowAllAuthenticator which 
performs no authentication checks and therefore requires no credentials. It is 
used to disable authentication completely. Note that authentication is a 
necessary condition of Cassandra’s permissions subsystem, so if authentication 
is disabled, effectively so are permissions.
 * The default distribution also includes PasswordAuthenticator, which stores 
encrypted credentials in a system table. This can be used to enable simple 
username/password authentication.

 
{quote}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?
{quote} * Cassandra ships with two options included in the default distribution.
 * By default, Cassandra is configured with AllowAllAuthorizer which performs 
no checking and so effectively grants all permissions to all roles. This must 
be used if AllowAllAuthenticator is the configured authenticator.
 * The default distribution also includes CassandraAuthorizer, which does 
implement full permissions management functionality and stores its data in 
Cassandra system tables.

> 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: Legacy/Tools, Local/Config
> 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
>Assignee: Tanaka
>Priority: Low
>  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
(v7.6.14#76016)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Assigned] (CASSANDRA-14012) Document gossip protocol

2019-07-18 Thread Tanaka (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tanaka reassigned CASSANDRA-14012:
--

Assignee: Tanaka

> Document gossip protocol
> 
>
> Key: CASSANDRA-14012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14012
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Jörn Heissler
>Assignee: Tanaka
>Priority: Low
>  Labels: Documentation
>
> I had an issue today with two nodes communicating with each other; there's a 
> flaw in my configuration (wrong broadcast address).
> I saw a little bit of traffic on port 7000, but I couldn't understand it for 
> lack of documentation.
> With documentation I would have understood my issue very quickly (7f 00 01 01 
> is a bad broadcast address!). But I didn't recognize those 4 bytes as the bc 
> address.
> Could you please document the gossip protocol?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Assigned] (CASSANDRA-10248) Document compatibilities between native specs and Cassandra versions

2019-07-18 Thread Tanaka (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tanaka reassigned CASSANDRA-10248:
--

Assignee: Tanaka

> Document compatibilities between native specs and Cassandra versions
> 
>
> Key: CASSANDRA-10248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10248
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Thibault Charbonnier
>Assignee: Tanaka
>Priority: Low
>  Labels: documentation
>
> Nowhere in the native specs is specified for which Cassandra version it is 
> compatible with. This has been confusing to me when implementing a given 
> protocol in a Lua driver, and has apparently been confusing other people [1].
> I remember seeing a table specifying which specs were compatible with which 
> Cassandra version somewhere in the Python driver documentation but I am 
> currently unable to find it.
> Proposed solution: maybe include a small table in each specification file 
> describing the compatibilities between Cassandra and the current (and 
> eventually older) specs.
> [1] 
> http://mail-archives.apache.org/mod_mbox/cassandra-dev/201504.mbox/%3ca87729c9-fa6a-4b34-bb7b-b324e154c...@datastax.com%3E



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Assigned] (CASSANDRA-8557) Default install from tarball is a bit puzzling

2019-07-18 Thread Tanaka (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-8557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tanaka reassigned CASSANDRA-8557:
-

Assignee: Tanaka

> 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: Legacy/Tools, Local/Config
> 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
>Assignee: Tanaka
>Priority: Low
>  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
(v7.6.14#76016)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-8557) Default install from tarball is a bit puzzling

2019-07-17 Thread Tanaka (JIRA)


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

Tanaka commented on CASSANDRA-8557:
---

[~crertel] Hi, I'm relatively new to Apache Cassandra and thus feel as though 
this would be a great task for me to work through and document. Would you mind 
assigning this task to me? 

> 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: Legacy/Tools, Local/Config
> 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
>Priority: Low
>  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
(v7.6.14#76016)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13749) add documentation about upgrade process to docs

2019-07-17 Thread Tanaka (JIRA)


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

Tanaka commented on CASSANDRA-13749:


[~sumanth.pasupuleti] No worries, best of luck!

> add documentation about upgrade process to docs
> ---
>
> Key: CASSANDRA-13749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13749
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Jon Haddad
>Assignee: Sumanth Pasupuleti
>Priority: Normal
>  Labels: documentation
>
> The docs don't have any information on how to upgrade.  This question gets 
> asked constantly on the mailing list.
> Seems like it belongs under the "Operating Cassandra" section.
> https://cassandra.apache.org/doc/latest/operating/index.html



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13749) add documentation about upgrade process to docs

2019-07-17 Thread Tanaka (JIRA)


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

Tanaka commented on CASSANDRA-13749:


[~rustyrazorblade] Hi, is this ticket up for grabs? If so, I would like to work 
on the documentation for this!

> add documentation about upgrade process to docs
> ---
>
> Key: CASSANDRA-13749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13749
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Jon Haddad
>Assignee: Sumanth Pasupuleti
>Priority: Normal
>  Labels: documentation
>
> The docs don't have any information on how to upgrade.  This question gets 
> asked constantly on the mailing list.
> Seems like it belongs under the "Operating Cassandra" section.
> https://cassandra.apache.org/doc/latest/operating/index.html



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org