[jira] [Updated] (CASSANDRA-4322) Error in CLI when updating keyspace

2012-09-10 Thread Jonathan Ellis (JIRA) 

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

Jonathan Ellis updated CASSANDRA-4322:
--

 Reviewer: dbros...@apache.org  (was: richardlow)
Fix Version/s: 1.1.6
 Assignee: Pavel Yaskevich  (was: Dave Brosius)

 Error in CLI when updating keyspace
 ---

 Key: CASSANDRA-4322
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4322
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.1
Reporter: Richard Low
Assignee: Pavel Yaskevich
Priority: Minor
 Fix For: 1.1.6

 Attachments: auth_for_mod_ks.txt, CASSANDRA-4322.patch


 To repro:
 1. Open the cli
 2. Create a keyspace:
   create keyspace ks1 with placement_strategy = SimpleStrategy and 
 strategy_options = {replication_factor:1};
 3. Update the keyspace:
   update keyspace ks1 with strategy_options = {replication_factor:3};
 The output is:
 [default@unknown] create keyspace ks1 with placement_strategy = 
 SimpleStrategy and strategy_options = {replication_factor:1}; 
   
 8ecd5e16-e0f7-37e7-850e-38ee1a3a510e
 Waiting for schema agreement...
 ... schemas agree across the cluster
 [default@unknown] update keyspace ks1 with strategy_options = 
 {replication_factor:3};
 857af387-6677-3e39-bdf6-e1132673c25b
 Waiting for schema agreement...
 ... schemas agree across the cluster
 org.apache.thrift.protocol.TProtocolException: Required field 'keyspace' was 
 not present! Struct: describe_keyspace_args(keyspace:null)
 [default@unknown]
 The problem is that the patch in CASSANDRA-4052 assumes the CLI is 
 authenticated to a working keyspace.  getKSMetaData in executeUpdateKeySpace 
 is called with keySpace, which is null.
 Changing this to keyspaceName partially solves it, we now get:
 [default@unknown] update keyspace ks1 with strategy_options = 
 {replication_factor:3};
 Not authenticated to a working keyspace.
 18d750fc-19d9-30f0-b8b9-18b2e4a0a0d4
 Waiting for schema agreement...
 ... schemas agree across the cluster
 Not authenticated to a working keyspace.
 This comes from replayAssumptions in getKSMetaData.
 It seems that the refresh code needs to be reworked slightly to not assume 
 the CLI is authenticated to a keyspace.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4322) Error in CLI when updating keyspace

2012-09-08 Thread Pavel Yaskevich (JIRA) 

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

Pavel Yaskevich updated CASSANDRA-4322:
---

Attachment: CASSANDRA-4322.patch

patch allows to create keyspace without being authorized to one + fixes 
describe.

 Error in CLI when updating keyspace
 ---

 Key: CASSANDRA-4322
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4322
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.1
Reporter: Richard Low
Assignee: Dave Brosius
Priority: Minor
 Attachments: auth_for_mod_ks.txt, CASSANDRA-4322.patch


 To repro:
 1. Open the cli
 2. Create a keyspace:
   create keyspace ks1 with placement_strategy = SimpleStrategy and 
 strategy_options = {replication_factor:1};
 3. Update the keyspace:
   update keyspace ks1 with strategy_options = {replication_factor:3};
 The output is:
 [default@unknown] create keyspace ks1 with placement_strategy = 
 SimpleStrategy and strategy_options = {replication_factor:1}; 
   
 8ecd5e16-e0f7-37e7-850e-38ee1a3a510e
 Waiting for schema agreement...
 ... schemas agree across the cluster
 [default@unknown] update keyspace ks1 with strategy_options = 
 {replication_factor:3};
 857af387-6677-3e39-bdf6-e1132673c25b
 Waiting for schema agreement...
 ... schemas agree across the cluster
 org.apache.thrift.protocol.TProtocolException: Required field 'keyspace' was 
 not present! Struct: describe_keyspace_args(keyspace:null)
 [default@unknown]
 The problem is that the patch in CASSANDRA-4052 assumes the CLI is 
 authenticated to a working keyspace.  getKSMetaData in executeUpdateKeySpace 
 is called with keySpace, which is null.
 Changing this to keyspaceName partially solves it, we now get:
 [default@unknown] update keyspace ks1 with strategy_options = 
 {replication_factor:3};
 Not authenticated to a working keyspace.
 18d750fc-19d9-30f0-b8b9-18b2e4a0a0d4
 Waiting for schema agreement...
 ... schemas agree across the cluster
 Not authenticated to a working keyspace.
 This comes from replayAssumptions in getKSMetaData.
 It seems that the refresh code needs to be reworked slightly to not assume 
 the CLI is authenticated to a keyspace.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4322) Error in CLI when updating keyspace

2012-06-09 Thread Jonathan Ellis (JIRA) 

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

Jonathan Ellis updated CASSANDRA-4322:
--

Reviewer: thepaul

 Error in CLI when updating keyspace
 ---

 Key: CASSANDRA-4322
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4322
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.1
Reporter: Richard Low
Assignee: Dave Brosius
Priority: Minor
 Attachments: auth_for_mod_ks.txt


 To repro:
 1. Open the cli
 2. Create a keyspace:
   create keyspace ks1 with placement_strategy = SimpleStrategy and 
 strategy_options = {replication_factor:1};
 3. Update the keyspace:
   update keyspace ks1 with strategy_options = {replication_factor:3};
 The output is:
 [default@unknown] create keyspace ks1 with placement_strategy = 
 SimpleStrategy and strategy_options = {replication_factor:1}; 
   
 8ecd5e16-e0f7-37e7-850e-38ee1a3a510e
 Waiting for schema agreement...
 ... schemas agree across the cluster
 [default@unknown] update keyspace ks1 with strategy_options = 
 {replication_factor:3};
 857af387-6677-3e39-bdf6-e1132673c25b
 Waiting for schema agreement...
 ... schemas agree across the cluster
 org.apache.thrift.protocol.TProtocolException: Required field 'keyspace' was 
 not present! Struct: describe_keyspace_args(keyspace:null)
 [default@unknown]
 The problem is that the patch in CASSANDRA-4052 assumes the CLI is 
 authenticated to a working keyspace.  getKSMetaData in executeUpdateKeySpace 
 is called with keySpace, which is null.
 Changing this to keyspaceName partially solves it, we now get:
 [default@unknown] update keyspace ks1 with strategy_options = 
 {replication_factor:3};
 Not authenticated to a working keyspace.
 18d750fc-19d9-30f0-b8b9-18b2e4a0a0d4
 Waiting for schema agreement...
 ... schemas agree across the cluster
 Not authenticated to a working keyspace.
 This comes from replayAssumptions in getKSMetaData.
 It seems that the refresh code needs to be reworked slightly to not assume 
 the CLI is authenticated to a keyspace.

--
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-4322) Error in CLI when updating keyspace

2012-06-09 Thread Jonathan Ellis (JIRA) 

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

Jonathan Ellis updated CASSANDRA-4322:
--

Reviewer: richardlow  (was: thepaul)

 Error in CLI when updating keyspace
 ---

 Key: CASSANDRA-4322
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4322
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.1
Reporter: Richard Low
Assignee: Dave Brosius
Priority: Minor
 Attachments: auth_for_mod_ks.txt


 To repro:
 1. Open the cli
 2. Create a keyspace:
   create keyspace ks1 with placement_strategy = SimpleStrategy and 
 strategy_options = {replication_factor:1};
 3. Update the keyspace:
   update keyspace ks1 with strategy_options = {replication_factor:3};
 The output is:
 [default@unknown] create keyspace ks1 with placement_strategy = 
 SimpleStrategy and strategy_options = {replication_factor:1}; 
   
 8ecd5e16-e0f7-37e7-850e-38ee1a3a510e
 Waiting for schema agreement...
 ... schemas agree across the cluster
 [default@unknown] update keyspace ks1 with strategy_options = 
 {replication_factor:3};
 857af387-6677-3e39-bdf6-e1132673c25b
 Waiting for schema agreement...
 ... schemas agree across the cluster
 org.apache.thrift.protocol.TProtocolException: Required field 'keyspace' was 
 not present! Struct: describe_keyspace_args(keyspace:null)
 [default@unknown]
 The problem is that the patch in CASSANDRA-4052 assumes the CLI is 
 authenticated to a working keyspace.  getKSMetaData in executeUpdateKeySpace 
 is called with keySpace, which is null.
 Changing this to keyspaceName partially solves it, we now get:
 [default@unknown] update keyspace ks1 with strategy_options = 
 {replication_factor:3};
 Not authenticated to a working keyspace.
 18d750fc-19d9-30f0-b8b9-18b2e4a0a0d4
 Waiting for schema agreement...
 ... schemas agree across the cluster
 Not authenticated to a working keyspace.
 This comes from replayAssumptions in getKSMetaData.
 It seems that the refresh code needs to be reworked slightly to not assume 
 the CLI is authenticated to a keyspace.

--
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-4322) Error in CLI when updating keyspace

2012-06-08 Thread Dave Brosius (JIRA) 

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

Dave Brosius updated CASSANDRA-4322:


Attachment: auth_for_mod_ks.txt

don't allow updating or dropping of a keyspace unless you authenticate to it 
(use ks).

 Error in CLI when updating keyspace
 ---

 Key: CASSANDRA-4322
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4322
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.1
Reporter: Richard Low
Assignee: Dave Brosius
Priority: Minor
 Attachments: auth_for_mod_ks.txt


 To repro:
 1. Open the cli
 2. Create a keyspace:
   create keyspace ks1 with placement_strategy = SimpleStrategy and 
 strategy_options = {replication_factor:1};
 3. Update the keyspace:
   update keyspace ks1 with strategy_options = {replication_factor:3};
 The output is:
 [default@unknown] create keyspace ks1 with placement_strategy = 
 SimpleStrategy and strategy_options = {replication_factor:1}; 
   
 8ecd5e16-e0f7-37e7-850e-38ee1a3a510e
 Waiting for schema agreement...
 ... schemas agree across the cluster
 [default@unknown] update keyspace ks1 with strategy_options = 
 {replication_factor:3};
 857af387-6677-3e39-bdf6-e1132673c25b
 Waiting for schema agreement...
 ... schemas agree across the cluster
 org.apache.thrift.protocol.TProtocolException: Required field 'keyspace' was 
 not present! Struct: describe_keyspace_args(keyspace:null)
 [default@unknown]
 The problem is that the patch in CASSANDRA-4052 assumes the CLI is 
 authenticated to a working keyspace.  getKSMetaData in executeUpdateKeySpace 
 is called with keySpace, which is null.
 Changing this to keyspaceName partially solves it, we now get:
 [default@unknown] update keyspace ks1 with strategy_options = 
 {replication_factor:3};
 Not authenticated to a working keyspace.
 18d750fc-19d9-30f0-b8b9-18b2e4a0a0d4
 Waiting for schema agreement...
 ... schemas agree across the cluster
 Not authenticated to a working keyspace.
 This comes from replayAssumptions in getKSMetaData.
 It seems that the refresh code needs to be reworked slightly to not assume 
 the CLI is authenticated to a keyspace.

--
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