date:20140505

Fix super column filter conversion

patch by slebresne; reviewed by thobbs for CASSANDRA-7138


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7e8efd1b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7e8efd1b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7e8efd1b

Branch: refs/heads/cassandra-2.1
Commit: 7e8efd1bbc8e25c9503883bee895df168e5a99b8
Parents: 706afc3
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Mon May 5 09:21:46 2014 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Mon May 5 09:21:46 2014 +0200

--
 CHANGES.txt   |  1 +
 src/java/org/apache/cassandra/db/SuperColumns.java|  5 -
 .../org/apache/cassandra/thrift/CassandraServer.java  | 14 ++
 3 files changed, 15 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e8efd1b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5332c65..ddcb09c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
 2.1.0-rc1
  * Parallel streaming for sstableloader (CASSANDRA-3668)
+ * Fix bugs in supercolumns handling (CASSANDRA-7138)
 Merged from 2.0:
  * Make batchlog replica selection rack-aware (CASSANDRA-6551)
  * Suggest CTRL-C or semicolon after three blank lines in cqlsh 
(CASSANDRA-7142)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e8efd1b/src/java/org/apache/cassandra/db/SuperColumns.java
--
diff --git a/src/java/org/apache/cassandra/db/SuperColumns.java 
b/src/java/org/apache/cassandra/db/SuperColumns.java
index bab46eb..2006cbd 100644
--- a/src/java/org/apache/cassandra/db/SuperColumns.java
+++ b/src/java/org/apache/cassandra/db/SuperColumns.java
@@ -184,7 +184,10 @@ public class SuperColumns
 int i = 0;
 for (CellName name : filter.columns)
 {
-slices[i++] = name.slice();
+// Note that, because the filter in argument is the one from 
thrift, 'name' are SimpleDenseCellName.
+// So calling name.slice() would be incorrect, as simple cell 
names don't handle the EOC properly.
+// This is why we call toByteBuffer() and rebuild a  Composite 
of the right type before call slice().
+slices[i++] = type.make(name.toByteBuffer()).slice();
 }
 return new SliceQueryFilter(slices, false, slices.length, 1);
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e8efd1b/src/java/org/apache/cassandra/thrift/CassandraServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CassandraServer.java 
b/src/java/org/apache/cassandra/thrift/CassandraServer.java
index 069cec7..5a296f3 100644
--- a/src/java/org/apache/cassandra/thrift/CassandraServer.java
+++ b/src/java/org/apache/cassandra/thrift/CassandraServer.java
@@ -381,12 +381,18 @@ public class CassandraServer implements Cassandra.Iface
 
 private SliceQueryFilter toInternalFilter(CFMetaData metadata, 
ColumnParent parent, SliceRange range)
 {
+if (metadata.isSuper())
+{
+CellNameType columnType = new 
SimpleDenseCellNameType(metadata.comparator.subtype(parent.isSetSuper_column() 
? 1 : 0));
+Composite start = columnType.fromByteBuffer(range.start);
+Composite finish = columnType.fromByteBuffer(range.finish);
+SliceQueryFilter filter = new SliceQueryFilter(start, finish, 
range.reversed, range.count);
+return SuperColumns.fromSCSliceFilter(metadata.comparator, 
parent.bufferForSuper_column(), filter);
+}
+
 Composite start = metadata.comparator.fromByteBuffer(range.start);
 Composite finish = metadata.comparator.fromByteBuffer(range.finish);
-SliceQueryFilter filter = new SliceQueryFilter(start, finish, 
range.reversed, range.count);
-if (metadata.isSuper())
-filter = SuperColumns.fromSCSliceFilter(metadata.comparator, 
parent.bufferForSuper_column(), filter);
-return filter;
+return new SliceQueryFilter(start, finish, range.reversed, 
range.count);
 }
 
 private IDiskAtomFilter toInternalFilter(CFMetaData metadata, ColumnParent 
parent, SlicePredicate predicate)

[1/4] git commit: Fixup for CASSANDRA-6831 on 2.1

Repository: cassandra
Updated Branches:
  refs/heads/trunk f3945bce7 - ddd2ff7d6


Fixup for CASSANDRA-6831 on 2.1


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/706afc30
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/706afc30
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/706afc30

Branch: refs/heads/trunk
Commit: 706afc300d9b298cb9456671a514cc9580b94ecc
Parents: a5266bc
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Mon May 5 09:20:18 2014 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Mon May 5 09:20:18 2014 +0200

--
 interface/cassandra.thrift  |   3 +-
 .../org/apache/cassandra/config/CFMetaData.java | 108 +--
 .../cassandra/config/ColumnDefinition.java  |  34 +++---
 .../cassandra/config/ColumnDefinitionTest.java  |   2 +-
 4 files changed, 72 insertions(+), 75 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/706afc30/interface/cassandra.thrift
--
diff --git a/interface/cassandra.thrift b/interface/cassandra.thrift
index 51d6786..4beb2eb 100644
--- a/interface/cassandra.thrift
+++ b/interface/cassandra.thrift
@@ -467,7 +467,6 @@ struct CfDef {
 33: optional double bloom_filter_fp_chance,
 34: optional string caching=keys_only,
 37: optional double dclocal_read_repair_chance = 0.0,
-38: optional bool populate_io_cache_on_flush,
 39: optional i32 memtable_flush_period_in_ms,
 40: optional i32 default_time_to_live,
 42: optional string speculative_retry=NONE,
@@ -501,6 +500,8 @@ struct CfDef {
 /** @deprecated */
 31: optional i32 row_cache_keys_to_save,
 /** @deprecated */
+38: optional bool populate_io_cache_on_flush,
+/** @deprecated */
 41: optional i32 index_interval,
 }
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/706afc30/src/java/org/apache/cassandra/config/CFMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java 
b/src/java/org/apache/cassandra/config/CFMetaData.java
index 2e531e8..2df42ae 100644
--- a/src/java/org/apache/cassandra/config/CFMetaData.java
+++ b/src/java/org/apache/cassandra/config/CFMetaData.java
@@ -58,7 +58,6 @@ import 
org.apache.cassandra.cql3.statements.CreateTableStatement;
 import org.apache.cassandra.db.AbstractCell;
 import org.apache.cassandra.db.AtomDeserializer;
 import org.apache.cassandra.db.CFRowAdder;
-import org.apache.cassandra.db.Cell;
 import org.apache.cassandra.db.ColumnFamily;
 import org.apache.cassandra.db.ColumnFamilyStore;
 import org.apache.cassandra.db.ColumnFamilyType;
@@ -69,7 +68,6 @@ import org.apache.cassandra.db.Mutation;
 import org.apache.cassandra.db.OnDiskAtom;
 import org.apache.cassandra.db.RangeTombstone;
 import org.apache.cassandra.db.Row;
-import org.apache.cassandra.db.SuperColumns;
 import org.apache.cassandra.db.SystemKeyspace;
 import org.apache.cassandra.db.compaction.AbstractCompactionStrategy;
 import org.apache.cassandra.db.compaction.LeveledCompactionStrategy;
@@ -97,6 +95,7 @@ import org.apache.cassandra.io.compress.CompressionParameters;
 import org.apache.cassandra.io.compress.LZ4Compressor;
 import org.apache.cassandra.io.sstable.Descriptor;
 import org.apache.cassandra.serializers.MarshalException;
+import org.apache.cassandra.thrift.CfDef;
 import org.apache.cassandra.thrift.CqlResult;
 import org.apache.cassandra.thrift.CqlRow;
 import org.apache.cassandra.tracing.Tracing;
@@ -999,45 +998,18 @@ public final class CFMetaData
 }
 }
 
-public static CFMetaData fromThrift(org.apache.cassandra.thrift.CfDef 
cf_def) throws InvalidRequestException, ConfigurationException
+public static CFMetaData fromThrift(CfDef cf_def) throws 
InvalidRequestException, ConfigurationException
 {
-CFMetaData cfm = internalFromThrift(cf_def);
-
-if (cf_def.isSetKey_alias()  !(cfm.keyValidator instanceof 
CompositeType))
-
cfm.addOrReplaceColumnDefinition(ColumnDefinition.partitionKeyDef(cfm, 
cf_def.key_alias, cfm.keyValidator, null));
-
-return cfm.rebuild();
+return internalFromThrift(cf_def, 
Collections.ColumnDefinitionemptyList());
 }
 
-public static CFMetaData 
fromThriftForUpdate(org.apache.cassandra.thrift.CfDef cf_def, CFMetaData 
toUpdate) throws InvalidRequestException, ConfigurationException
+public static CFMetaData fromThriftForUpdate(CfDef cf_def, CFMetaData 
toUpdate) throws InvalidRequestException, ConfigurationException
 {
-CFMetaData cfm = internalFromThrift(cf_def);
-
-// Thrift update can't have CQL metadata, and so we'll copy the ones 
of the updated metadata (to make
-

[4/4] git commit: Merge branch 'cassandra-2.1' into trunk

Merge branch 'cassandra-2.1' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ddd2ff7d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ddd2ff7d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ddd2ff7d

Branch: refs/heads/trunk
Commit: ddd2ff7d63c9a9977eb2dd25936cecbb2ecd1cfb
Parents: f3945bc 3aa41fb
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Mon May 5 09:28:12 2014 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Mon May 5 09:28:12 2014 +0200

--
 CHANGES.txt |   2 +
 interface/cassandra.thrift  |   3 +-
 .../org/apache/cassandra/config/CFMetaData.java | 108 +--
 .../cassandra/config/ColumnDefinition.java  |  34 +++---
 .../org/apache/cassandra/db/SuperColumns.java   |   5 +-
 .../composites/CompoundDenseCellNameType.java   |   8 +-
 .../cassandra/thrift/CassandraServer.java   |  14 ++-
 .../cassandra/config/ColumnDefinitionTest.java  |   2 +-
 8 files changed, 92 insertions(+), 84 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ddd2ff7d/CHANGES.txt
--
diff --cc CHANGES.txt
index bc6db0d,2f55eee..f587a55
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,13 -1,7 +1,15 @@@
 +3.0
 + * Move sstable RandomAccessReader to nio2, which allows using the
 +   FILE_SHARE_DELETE flag on Windows (CASSANDRA-4050)
 + * Remove CQL2 (CASSANDRA-5918)
 + * Add Thrift get_multi_slice call (CASSANDRA-6757)
 + * Optimize fetching multiple cells by name (CASSANDRA-6933)
 + * Allow compilation in java 8 (CASSANDRA-7208)
 +
  2.1.0-rc1
   * Parallel streaming for sstableloader (CASSANDRA-3668)
+  * Fix bugs in supercolumns handling (CASSANDRA-7138)
+  * Fix ClassClassException on composite dense tables (CASSANDRA-7112)
  Merged from 2.0:
   * Make batchlog replica selection rack-aware (CASSANDRA-6551)
   * Suggest CTRL-C or semicolon after three blank lines in cqlsh 
(CASSANDRA-7142)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ddd2ff7d/interface/cassandra.thrift
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ddd2ff7d/src/java/org/apache/cassandra/config/CFMetaData.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ddd2ff7d/src/java/org/apache/cassandra/config/ColumnDefinition.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ddd2ff7d/src/java/org/apache/cassandra/thrift/CassandraServer.java
--

[2/4] git commit: Fix super column filter conversion

Fix super column filter conversion

patch by slebresne; reviewed by thobbs for CASSANDRA-7138


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7e8efd1b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7e8efd1b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7e8efd1b

Branch: refs/heads/trunk
Commit: 7e8efd1bbc8e25c9503883bee895df168e5a99b8
Parents: 706afc3
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Mon May 5 09:21:46 2014 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Mon May 5 09:21:46 2014 +0200

--
 CHANGES.txt   |  1 +
 src/java/org/apache/cassandra/db/SuperColumns.java|  5 -
 .../org/apache/cassandra/thrift/CassandraServer.java  | 14 ++
 3 files changed, 15 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e8efd1b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5332c65..ddcb09c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
 2.1.0-rc1
  * Parallel streaming for sstableloader (CASSANDRA-3668)
+ * Fix bugs in supercolumns handling (CASSANDRA-7138)
 Merged from 2.0:
  * Make batchlog replica selection rack-aware (CASSANDRA-6551)
  * Suggest CTRL-C or semicolon after three blank lines in cqlsh 
(CASSANDRA-7142)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e8efd1b/src/java/org/apache/cassandra/db/SuperColumns.java
--
diff --git a/src/java/org/apache/cassandra/db/SuperColumns.java 
b/src/java/org/apache/cassandra/db/SuperColumns.java
index bab46eb..2006cbd 100644
--- a/src/java/org/apache/cassandra/db/SuperColumns.java
+++ b/src/java/org/apache/cassandra/db/SuperColumns.java
@@ -184,7 +184,10 @@ public class SuperColumns
 int i = 0;
 for (CellName name : filter.columns)
 {
-slices[i++] = name.slice();
+// Note that, because the filter in argument is the one from 
thrift, 'name' are SimpleDenseCellName.
+// So calling name.slice() would be incorrect, as simple cell 
names don't handle the EOC properly.
+// This is why we call toByteBuffer() and rebuild a  Composite 
of the right type before call slice().
+slices[i++] = type.make(name.toByteBuffer()).slice();
 }
 return new SliceQueryFilter(slices, false, slices.length, 1);
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e8efd1b/src/java/org/apache/cassandra/thrift/CassandraServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CassandraServer.java 
b/src/java/org/apache/cassandra/thrift/CassandraServer.java
index 069cec7..5a296f3 100644
--- a/src/java/org/apache/cassandra/thrift/CassandraServer.java
+++ b/src/java/org/apache/cassandra/thrift/CassandraServer.java
@@ -381,12 +381,18 @@ public class CassandraServer implements Cassandra.Iface
 
 private SliceQueryFilter toInternalFilter(CFMetaData metadata, 
ColumnParent parent, SliceRange range)
 {
+if (metadata.isSuper())
+{
+CellNameType columnType = new 
SimpleDenseCellNameType(metadata.comparator.subtype(parent.isSetSuper_column() 
? 1 : 0));
+Composite start = columnType.fromByteBuffer(range.start);
+Composite finish = columnType.fromByteBuffer(range.finish);
+SliceQueryFilter filter = new SliceQueryFilter(start, finish, 
range.reversed, range.count);
+return SuperColumns.fromSCSliceFilter(metadata.comparator, 
parent.bufferForSuper_column(), filter);
+}
+
 Composite start = metadata.comparator.fromByteBuffer(range.start);
 Composite finish = metadata.comparator.fromByteBuffer(range.finish);
-SliceQueryFilter filter = new SliceQueryFilter(start, finish, 
range.reversed, range.count);
-if (metadata.isSuper())
-filter = SuperColumns.fromSCSliceFilter(metadata.comparator, 
parent.bufferForSuper_column(), filter);
-return filter;
+return new SliceQueryFilter(start, finish, range.reversed, 
range.count);
 }
 
 private IDiskAtomFilter toInternalFilter(CFMetaData metadata, ColumnParent 
parent, SlicePredicate predicate)

[jira] [Commented] (CASSANDRA-7148) Auto pagination finds 999 791 out of 1 000 000 rows


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989336#comment-13989336
 ] 

Sylvain Lebresne commented on CASSANDRA-7148:
-

Have you tried using QUORUM consistency for writes and reads instead of CAS? 
You might also want to give a shot at C* 2.0.7 too since there has been a few 
paging related fix in that release.

 Auto pagination finds 999 791 out of 1 000 000 rows
 ---

 Key: CASSANDRA-7148
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7148
 Project: Cassandra
  Issue Type: Bug
Reporter: bodrin

 In a cluster of 3 nodes cassandra 2.0.6 with replication factor=3 and with 
 the following schema:
 CREATE TABLE IF NOT EXISTS test (
   org varchar,
   department varchar,
   id varchar,
   area varchar,
   value text, // json
   PRIMARY KEY ((org), department, id)
 );
 CREATE INDEX IF NOT EXISTS ON test(area);
 I have inserted 1 000 000 rows this way:
 String insert = INSERT INTO test (org, department, id, area, value) VALUES 
 (?, ?, ?, ?, ?);
   for (int organization = 0; organization  500; organization++) {
  for (int department = 0; department  2; department++) {
 for (int area = 0; area  2; area++) {
for (int id = 0; id  500; id++) {
   String orgValue = org + organization;
   String departmentValue = department + 
 department;
   String areaValue = area + area;
   String idValue = 
 UUID.randomUUID().toString();
   // insert a single row here
 ...
 Then just read them all:
   int count = 0;
   ResultSet rs = session.execute(select * from test limit 100);
   IteratorRow i = rs.iterator();
   while (i.hasNext()) {
  Row row = i.next();
  count++;
   }
 
 and the count is 999791 (this tooks 33 seconds)
 while at the same time 
 cqlsh:t2 select count(*) from test limit 100;
  count
 -
  100
  I have also verified that all the queries of kind
  select * from test where area=areaXXX
  return 500 entries as expected and 2000*500 is 1 000 000



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6696) Drive replacement in JBOD can cause data to reappear.

2014-05-05 Thread Marcus Eriksson (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-6696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989356#comment-13989356
]

Marcus Eriksson commented on CASSANDRA-6696:

summing up the discussion;

* one stripe is one vnode
* we flush to big files in L0, file per disk or perhaps group a bunch of vnodes
together to increase the amount of parallel compactions we can do L0 - L1

for STCS:
* we introduce L0 for STCS
* when we end up with a given number of overlapping L0 files (4), we compact
those together and create per-vnode L1 files.
* major compaction: include all files in compaction, write #vnodes files

for LCS:
* We introduce a leveled manifest per vnode
* L0 is global
* when doing L0 - L1 compactions, we end up with one file per involved
vnode-stripe in L1, here we can gain a lot by not flushing too big L0 files.
* we still do STCS within L0 if we get too much data here, making sure we only
compact overlapping files

anything i missed/misunderstood?

Drive replacement in JBOD can cause data to reappear.
--

Key: CASSANDRA-6696
URL: https://issues.apache.org/jira/browse/CASSANDRA-6696
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: sankalp kohli
Assignee: Marcus Eriksson
Fix For: 3.0

In JBOD, when someone gets a bad drive, the bad drive is replaced with a new
empty one and repair is run.
This can cause deleted data to come back in some cases. Also this is true for
corrupt stables in which we delete the corrupt stable and run repair.
Here is an example:
Say we have 3 nodes A,B and C and RF=3 and GC grace=10days.
row=sankalp col=sankalp is written 20 days back and successfully went to all
three nodes.
Then a delete/tombstone was written successfully for the same row column 15
days back.
Since this tombstone is more than gc grace, it got compacted in Nodes A and B
since it got compacted with the actual data. So there is no trace of this row
column in node A and B.
Now in node C, say the original data is in drive1 and tombstone is in drive2.
Compaction has not yet reclaimed the data and tombstone.
Drive2 becomes corrupt and was replaced with new empty drive.
Due to the replacement, the tombstone in now gone and row=sankalp col=sankalp
has come back to life.
Now after replacing the drive we run repair. This data will be propagated to
all nodes.
Note: This is still a problem even if we run repair every gc grace.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7152) DevCenter results copy

2014-05-05 Thread JIRA


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

Kévin LOVATO updated CASSANDRA-7152:


Issue Type: Improvement  (was: Bug)

 DevCenter results copy
 --

 Key: CASSANDRA-7152
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7152
 Project: Cassandra
  Issue Type: Improvement
Reporter: Kévin LOVATO

 It's great that we now can copy the results to a CSV or Insert statement, but 
 handling CTRL+C / CTRL+Insert would be nice.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7154) Add application icon for DevCenter in taskbar

2014-05-05 Thread Antoine Blanchet (JIRA)

Antoine Blanchet created CASSANDRA-7154:
---

 Summary: Add application icon for DevCenter in taskbar
 Key: CASSANDRA-7154
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7154
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
 Environment: Windows 7 64bit
Reporter: Antoine Blanchet
Priority: Minor


Please add an application icon for DevCenter on Windows, it's a bit uggly in 
the taskbar.

Note : The taskbar icon is OK during the splashscreen, and then turn default 
when the actual application starts.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CASSANDRA-7152) DevCenter results copy


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

Sylvain Lebresne resolved CASSANDRA-7152.
-

Resolution: Invalid

See CASSANDRA-7150

 DevCenter results copy
 --

 Key: CASSANDRA-7152
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7152
 Project: Cassandra
  Issue Type: Improvement
Reporter: Kévin LOVATO

 It's great that we now can copy the results to a CSV or Insert statement, but 
 handling CTRL+C / CTRL+Insert would be nice.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Git Push Summary

Repository: cassandra
Updated Tags:  refs/tags/2.1.0-beta2-tentative [deleted] 48727b4cc

Git Push Summary

Repository: cassandra
Updated Tags:  refs/tags/cassandra-2.1.0-beta2 [created] 3bb78e53d

[jira] [Updated] (CASSANDRA-7053) USING TIMESTAMP for batches does not work


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

Sylvain Lebresne updated CASSANDRA-7053:


Fix Version/s: (was: 2.1 beta2)

 USING TIMESTAMP for batches does not work
 -

 Key: CASSANDRA-7053
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7053
 Project: Cassandra
  Issue Type: Bug
Reporter: Robert Supencheck
Assignee: Mikhail Stepura
  Labels: cqlsh
 Fix For: 2.0.8

 Attachments: cassandra-2.0-7053.patch


 When using the USING TIMESTAMP timestamp syntax for a batch statement, 
 the supplied timestamp is ignored.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6696) Drive replacement in JBOD can cause data to reappear.

2014-05-05 Thread Marcus Eriksson (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-6696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989537#comment-13989537
]

Marcus Eriksson commented on CASSANDRA-6696:

bq. we can gain a lot by not flushing too big L0 files.
if we flush to one big file, we would have to involve all L1 sstables when
compacting L0 - L1, if we flush smaller files, we can do more compactions in
parallel and we don't have to wait for all ongoing L1 - L2 compactions to
finish before starting L0 - L1

Drive replacement in JBOD can cause data to reappear.
--

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6973) timestamp data type does ISO 8601 formats with 'Z' as time zone.


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989541#comment-13989541
 ] 

Sylvain Lebresne commented on CASSANDRA-6973:
-

It does seems like 'X' is the right thing to do, but won't removing the 
patterns with a 'Z' make use refuse date strings (non-ISO 8601 ones) that we 
use to accept. Also, why do we need a parttern with 1 'X' and one with 3 'X' 
but not, say, with 2 'X' (if that's specified by SimpleDateFormat, this has 
escaped me)?

But as a side note, I really wish we weren't doing all this manually. And/or 
that we had unit tests for it. 

 timestamp data type does ISO 8601 formats with 'Z' as time zone.
 

 Key: CASSANDRA-6973
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6973
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Juho Mäkinen
Assignee: Chander S Pechetty
Priority: Trivial
 Attachments: trunk-6973.txt


 The timestamp data type does not support format where time zone is specified 
 with 'Z' (as in zulu aka. UTC+0 aka + time zone). Example:
 create table foo(ts timestamp primary key);
 insert into foo(ts) values('2014-04-01T20:17:35+'); -- this works
 cqlsh:test insert into foo(ts) values('2014-04-01T20:17:35Z');
 Bad Request: unable to coerce '2014-04-01T20:17:35Z' to a  formatted date 
 (long)
 The example date was copied directly from ISO 8601 Wikipedia page. The 
 standard says that If the time is in UTC, add a Z directly after the time 
 without a space. Z is the zone designator for the zero UTC offset.
 Tested with cqlsh with 2.0.6 version.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6696) Drive replacement in JBOD can cause data to reappear.

2014-05-05 Thread Tupshin Harper (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-6696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989543#comment-13989543
]

Tupshin Harper commented on CASSANDRA-6696:
---

I may be misunderstanding, but this seems to be optimizing for compaction
throughput/parallelization, but at the expense of doing more total compaction
activity (number of compactions per mutation over the life of that mutation, a
form of write-amplification) by starting with smaller tables.

If that's not the case, then please ignore, but it is important to note that
for the largest scale, highest velocity, longest retained use cases, it's the
number of recompactions/write amplification that really hurts.

Drive replacement in JBOD can cause data to reappear.
--

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6696) Drive replacement in JBOD can cause data to reappear.

2014-05-05 Thread Marcus Eriksson (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-6696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989549#comment-13989549
]

Marcus Eriksson commented on CASSANDRA-6696:

not really, note that we take the memtable, split it in X parts and write those
parts to disk;

for example, say we have 100 vnodes, meaning we have 100 L1 non-intersecting
sstables, if we then flush one file that intersects with all those sstables, we
would have to include all those files when we compact L0 - L1. If we instead
flush to 10 non-intersecting sstables in L0, we can do those L0 - L1
compactions independently, but the mutations are recompacted as many times

does that make sense?

Drive replacement in JBOD can cause data to reappear.
--

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6696) Drive replacement in JBOD can cause data to reappear.

2014-05-05 Thread Tupshin Harper (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-6696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989553#comment-13989553
]

Tupshin Harper commented on CASSANDRA-6696:
---

It does, thanks.

Drive replacement in JBOD can cause data to reappear.
--

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7156) Add a new seed provider for Apache Cloudstack platforms


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

Pierre-Yves Ritschard updated CASSANDRA-7156:
-

Issue Type: Improvement  (was: Bug)

 Add a new seed provider for Apache Cloudstack platforms
 ---

 Key: CASSANDRA-7156
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7156
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: needs access to a cloudstack API endpoint
Reporter: Pierre-Yves Ritschard
Priority: Minor
 Fix For: 2.0.8, 2.1.1

 Attachments: 0001-initial-work-on-a-cloudstack-seed-provider.patch


 The attached patch adds a new seed provider which queries a cloudstack API 
 endpoint for instances having a specific tag.
 The tag key and value can be controlled in the configuration file and 
 
 will default to 'cassandra_seed' and 'default'.   
 
 The Cloudstack endpoint is configured by three parameters in the  
 
 configuration file: 'cloudstack_api_endpoint', 'cloudstack_api_key' and   
 
 'cloudstack_api_secret'   
 
 By default, CloudstackSeedProvider fetchs the ipaddress of the first  
 
 interface, if another index should be used, the nic_index parameter will hold 
 it.
 A typical configuration file would thus have:
 {code:yaml}
 seed_provider:
 - class_name: org.apache.cassandra.locator.CloudstackSeedProvider
   parameters:
   - cloudstack_api_endpoint: https://some.cloudstack.host;
 cloudstack_api_key: X
 cloudstack_api_secret: X
 tag_value: my_cluster_name
 {code}
 This introduces no new dependency.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7156) Add a new seed provider for Apache Cloudstack platforms

Pierre-Yves Ritschard created CASSANDRA-7156:


 Summary: Add a new seed provider for Apache Cloudstack platforms
 Key: CASSANDRA-7156
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7156
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: needs access to a cloudstack API endpoint
Reporter: Pierre-Yves Ritschard
Priority: Minor
 Fix For: 2.0.8, 2.1.1
 Attachments: 0001-initial-work-on-a-cloudstack-seed-provider.patch

The attached patch adds a new seed provider which queries a cloudstack API 
endpoint for instances having a specific tag.

The tag key and value can be controlled in the configuration file and   
  
will default to 'cassandra_seed' and 'default'. 
  

The Cloudstack endpoint is configured by three parameters in the
  
configuration file: 'cloudstack_api_endpoint', 'cloudstack_api_key' and 
  
'cloudstack_api_secret' 
  

By default, CloudstackSeedProvider fetchs the ipaddress of the first
  
interface, if another index should be used, the nic_index parameter will hold 
it.

A typical configuration file would thus have:

{code:yaml}
seed_provider:
- class_name: org.apache.cassandra.locator.CloudstackSeedProvider
  parameters:
  - cloudstack_api_endpoint: https://some.cloudstack.host;
cloudstack_api_key: X
cloudstack_api_secret: X
tag_value: my_cluster_name
{code}

This introduces no new dependency.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7157) BulkRecordWriter enters infinite loop of swallowed exceptions when streaming fails.

2014-05-05 Thread James Campbell (JIRA)

James Campbell created CASSANDRA-7157:
-

 Summary: BulkRecordWriter enters infinite loop of swallowed 
exceptions when streaming fails.
 Key: CASSANDRA-7157
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7157
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: James Campbell
Priority: Trivial
 Attachments: patch.diff





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7157) BulkRecordWriter enters infinite loop of swallowed exceptions when streaming fails.

2014-05-05 Thread James Campbell (JIRA)


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

James Campbell updated CASSANDRA-7157:
--

Description: If streaming fails, BulkRecordWriter's close() method 
continues to call future.get() despite exceptions.

 BulkRecordWriter enters infinite loop of swallowed exceptions when streaming 
 fails.
 ---

 Key: CASSANDRA-7157
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7157
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: James Campbell
Priority: Trivial
 Attachments: patch.diff


 If streaming fails, BulkRecordWriter's close() method continues to call 
 future.get() despite exceptions.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7156) Add a new seed provider for Apache Cloudstack platforms


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989595#comment-13989595
 ] 

Jeremiah Jordan commented on CASSANDRA-7156:


I don't know that we should be hosting this in tree.  We don't currently host 
any alternate seed providers in tree.  It should be easy enough to put this up 
on github or something for people who want it.

 Add a new seed provider for Apache Cloudstack platforms
 ---

 Key: CASSANDRA-7156
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7156
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: needs access to a cloudstack API endpoint
Reporter: Pierre-Yves Ritschard
Priority: Minor
 Fix For: 2.0.8, 2.1.1

 Attachments: 0001-initial-work-on-a-cloudstack-seed-provider.patch


 The attached patch adds a new seed provider which queries a cloudstack API 
 endpoint for instances having a specific tag.
 The tag key and value can be controlled in the configuration file and 
 
 will default to 'cassandra_seed' and 'default'.   
 
 The Cloudstack endpoint is configured by three parameters in the  
 
 configuration file: 'cloudstack_api_endpoint', 'cloudstack_api_key' and   
 
 'cloudstack_api_secret'   
 
 By default, CloudstackSeedProvider fetchs the ipaddress of the first  
 
 interface, if another index should be used, the nic_index parameter will hold 
 it.
 A typical configuration file would thus have:
 {code:yaml}
 seed_provider:
 - class_name: org.apache.cassandra.locator.CloudstackSeedProvider
   parameters:
   - cloudstack_api_endpoint: https://some.cloudstack.host;
 cloudstack_api_key: X
 cloudstack_api_secret: X
 tag_value: my_cluster_name
 {code}
 This introduces no new dependency.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7156) Add a new seed provider for Apache Cloudstack platforms


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989600#comment-13989600
 ] 

Pierre-Yves Ritschard commented on CASSANDRA-7156:
--

Hi Jeremiah,

I definitely will publish this as a separate JAR if it doesn't make it in the 
tree. Since there is already a CloudstackSnitch provider and this doesn't add a 
lot of bloat I think it would make sense to put this in tree.

I don't think it makes a huge amount of sense outside of the tree since you 
lose the 'zeroconf' nice property that you get from having it locally.

 Add a new seed provider for Apache Cloudstack platforms
 ---

 Key: CASSANDRA-7156
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7156
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: needs access to a cloudstack API endpoint
Reporter: Pierre-Yves Ritschard
Priority: Minor
 Fix For: 2.0.8, 2.1.1

 Attachments: 0001-initial-work-on-a-cloudstack-seed-provider.patch


 The attached patch adds a new seed provider which queries a cloudstack API 
 endpoint for instances having a specific tag.
 The tag key and value can be controlled in the configuration file and 
 
 will default to 'cassandra_seed' and 'default'.   
 
 The Cloudstack endpoint is configured by three parameters in the  
 
 configuration file: 'cloudstack_api_endpoint', 'cloudstack_api_key' and   
 
 'cloudstack_api_secret'   
 
 By default, CloudstackSeedProvider fetchs the ipaddress of the first  
 
 interface, if another index should be used, the nic_index parameter will hold 
 it.
 A typical configuration file would thus have:
 {code:yaml}
 seed_provider:
 - class_name: org.apache.cassandra.locator.CloudstackSeedProvider
   parameters:
   - cloudstack_api_endpoint: https://some.cloudstack.host;
 cloudstack_api_key: X
 cloudstack_api_secret: X
 tag_value: my_cluster_name
 {code}
 This introduces no new dependency.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7156) Add a new seed provider for Apache Cloudstack platforms


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989606#comment-13989606
 ] 

Jeremiah Jordan commented on CASSANDRA-7156:


We are not going to default to this seed provider, so you are never going to 
have zeroconf without starting from a custom package, where you could easily 
include the jar. ¯\_(ツ)_/¯

 Add a new seed provider for Apache Cloudstack platforms
 ---

 Key: CASSANDRA-7156
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7156
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: needs access to a cloudstack API endpoint
Reporter: Pierre-Yves Ritschard
Priority: Minor
 Fix For: 2.0.8, 2.1.1

 Attachments: 0001-initial-work-on-a-cloudstack-seed-provider.patch


 The attached patch adds a new seed provider which queries a cloudstack API 
 endpoint for instances having a specific tag.
 The tag key and value can be controlled in the configuration file and 
 
 will default to 'cassandra_seed' and 'default'.   
 
 The Cloudstack endpoint is configured by three parameters in the  
 
 configuration file: 'cloudstack_api_endpoint', 'cloudstack_api_key' and   
 
 'cloudstack_api_secret'   
 
 By default, CloudstackSeedProvider fetchs the ipaddress of the first  
 
 interface, if another index should be used, the nic_index parameter will hold 
 it.
 A typical configuration file would thus have:
 {code:yaml}
 seed_provider:
 - class_name: org.apache.cassandra.locator.CloudstackSeedProvider
   parameters:
   - cloudstack_api_endpoint: https://some.cloudstack.host;
 cloudstack_api_key: X
 cloudstack_api_secret: X
 tag_value: my_cluster_name
 {code}
 This introduces no new dependency and together with CASSANDRA-7147 gives an 
 easy way of getting started on cloudstack platforms



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7156) Add a new seed provider for Apache Cloudstack platforms

2014-05-05 Thread Jonathan Ellis (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989605#comment-13989605
 ] 

Jonathan Ellis commented on CASSANDRA-7156:
---

I get that we don't want to host permutations of every possible custom seed 
provider, but ISTM that one per major cloud is reasonable if we can agree on 
what constitutes best practices.  Then if you want to wander off the beaten 
path you're on your own.

 Add a new seed provider for Apache Cloudstack platforms
 ---

 Key: CASSANDRA-7156
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7156
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: needs access to a cloudstack API endpoint
Reporter: Pierre-Yves Ritschard
Priority: Minor
 Fix For: 2.0.8, 2.1.1

 Attachments: 0001-initial-work-on-a-cloudstack-seed-provider.patch


 The attached patch adds a new seed provider which queries a cloudstack API 
 endpoint for instances having a specific tag.
 The tag key and value can be controlled in the configuration file and 
 
 will default to 'cassandra_seed' and 'default'.   
 
 The Cloudstack endpoint is configured by three parameters in the  
 
 configuration file: 'cloudstack_api_endpoint', 'cloudstack_api_key' and   
 
 'cloudstack_api_secret'   
 
 By default, CloudstackSeedProvider fetchs the ipaddress of the first  
 
 interface, if another index should be used, the nic_index parameter will hold 
 it.
 A typical configuration file would thus have:
 {code:yaml}
 seed_provider:
 - class_name: org.apache.cassandra.locator.CloudstackSeedProvider
   parameters:
   - cloudstack_api_endpoint: https://some.cloudstack.host;
 cloudstack_api_key: X
 cloudstack_api_secret: X
 tag_value: my_cluster_name
 {code}
 This introduces no new dependency and together with CASSANDRA-7147 gives an 
 easy way of getting started on cloudstack platforms



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7156) Add a new seed provider for Apache Cloudstack platforms


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989607#comment-13989607
 ] 

Jeremiah Jordan commented on CASSANDRA-7156:


bq. I get that we don't want to host permutations of every possible custom seed 
provider, but ISTM that one per major cloud is reasonable if we can agree on 
what constitutes best practices. Then if you want to wander off the beaten path 
you're on your own.

works for me

 Add a new seed provider for Apache Cloudstack platforms
 ---

 Key: CASSANDRA-7156
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7156
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: needs access to a cloudstack API endpoint
Reporter: Pierre-Yves Ritschard
Priority: Minor
 Fix For: 2.0.8, 2.1.1

 Attachments: 0001-initial-work-on-a-cloudstack-seed-provider.patch


 The attached patch adds a new seed provider which queries a cloudstack API 
 endpoint for instances having a specific tag.
 The tag key and value can be controlled in the configuration file and 
 
 will default to 'cassandra_seed' and 'default'.   
 
 The Cloudstack endpoint is configured by three parameters in the  
 
 configuration file: 'cloudstack_api_endpoint', 'cloudstack_api_key' and   
 
 'cloudstack_api_secret'   
 
 By default, CloudstackSeedProvider fetchs the ipaddress of the first  
 
 interface, if another index should be used, the nic_index parameter will hold 
 it.
 A typical configuration file would thus have:
 {code:yaml}
 seed_provider:
 - class_name: org.apache.cassandra.locator.CloudstackSeedProvider
   parameters:
   - cloudstack_api_endpoint: https://some.cloudstack.host;
 cloudstack_api_key: X
 cloudstack_api_secret: X
 tag_value: my_cluster_name
 {code}
 This introduces no new dependency and together with CASSANDRA-7147 gives an 
 easy way of getting started on cloudstack platforms



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Issue Comment Deleted] (CASSANDRA-7156) Add a new seed provider for Apache Cloudstack platforms


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

Jeremiah Jordan updated CASSANDRA-7156:
---

Comment: was deleted

(was: We are not going to default to this seed provider, so you are never going 
to have zeroconf without starting from a custom package, where you could 
easily include the jar. ¯\_(ツ)_/¯)

 Add a new seed provider for Apache Cloudstack platforms
 ---

 Key: CASSANDRA-7156
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7156
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: needs access to a cloudstack API endpoint
Reporter: Pierre-Yves Ritschard
Priority: Minor
 Fix For: 2.0.8, 2.1.1

 Attachments: 0001-initial-work-on-a-cloudstack-seed-provider.patch


 The attached patch adds a new seed provider which queries a cloudstack API 
 endpoint for instances having a specific tag.
 The tag key and value can be controlled in the configuration file and 
 
 will default to 'cassandra_seed' and 'default'.   
 
 The Cloudstack endpoint is configured by three parameters in the  
 
 configuration file: 'cloudstack_api_endpoint', 'cloudstack_api_key' and   
 
 'cloudstack_api_secret'   
 
 By default, CloudstackSeedProvider fetchs the ipaddress of the first  
 
 interface, if another index should be used, the nic_index parameter will hold 
 it.
 A typical configuration file would thus have:
 {code:yaml}
 seed_provider:
 - class_name: org.apache.cassandra.locator.CloudstackSeedProvider
   parameters:
   - cloudstack_api_endpoint: https://some.cloudstack.host;
 cloudstack_api_key: X
 cloudstack_api_secret: X
 tag_value: my_cluster_name
 {code}
 This introduces no new dependency and together with CASSANDRA-7147 gives an 
 easy way of getting started on cloudstack platforms



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7156) Add a new seed provider for Apache Cloudstack platforms


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989611#comment-13989611
 ] 

Jeremiah Jordan commented on CASSANDRA-7156:


[~pyritschard] did you test this with enabling password authentication?  I have 
seen some other custom seed providers fail to correctly interact with the code 
that checks am I a seed? if so make the default super user account.

 Add a new seed provider for Apache Cloudstack platforms
 ---

 Key: CASSANDRA-7156
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7156
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: needs access to a cloudstack API endpoint
Reporter: Pierre-Yves Ritschard
Priority: Minor
 Fix For: 2.0.8, 2.1.1

 Attachments: 0001-initial-work-on-a-cloudstack-seed-provider.patch


 The attached patch adds a new seed provider which queries a cloudstack API 
 endpoint for instances having a specific tag.
 The tag key and value can be controlled in the configuration file and 
 
 will default to 'cassandra_seed' and 'default'.   
 
 The Cloudstack endpoint is configured by three parameters in the  
 
 configuration file: 'cloudstack_api_endpoint', 'cloudstack_api_key' and   
 
 'cloudstack_api_secret'   
 
 By default, CloudstackSeedProvider fetchs the ipaddress of the first  
 
 interface, if another index should be used, the nic_index parameter will hold 
 it.
 A typical configuration file would thus have:
 {code:yaml}
 seed_provider:
 - class_name: org.apache.cassandra.locator.CloudstackSeedProvider
   parameters:
   - cloudstack_api_endpoint: https://some.cloudstack.host;
 cloudstack_api_key: X
 cloudstack_api_secret: X
 tag_value: my_cluster_name
 {code}
 This introduces no new dependency and together with CASSANDRA-7147 gives an 
 easy way of getting started on cloudstack platforms



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7156) Add a new seed provider for Apache Cloudstack platforms


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

Pierre-Yves Ritschard updated CASSANDRA-7156:
-

Description: 
The attached patch adds a new seed provider which queries a cloudstack API 
endpoint for instances having a specific tag.

The tag key and value can be controlled in the configuration file and   
  
will default to 'cassandra_seed' and 'default'. 
  

The Cloudstack endpoint is configured by three parameters in the
  
configuration file: 'cloudstack_api_endpoint', 'cloudstack_api_key' and 
  
'cloudstack_api_secret' 
  

By default, CloudstackSeedProvider fetchs the ipaddress of the first
  
interface, if another index should be used, the nic_index parameter will hold 
it.

A typical configuration file would thus have:

{code:yaml}
seed_provider:
- class_name: org.apache.cassandra.locator.CloudstackSeedProvider
  parameters:
  - cloudstack_api_endpoint: https://some.cloudstack.host;
cloudstack_api_key: X
cloudstack_api_secret: X
tag_value: my_cluster_name
{code}

This introduces no new dependency and together with CASSANDRA-7147 gives an 
easy way of getting started on cloudstack platforms

  was:
The attached patch adds a new seed provider which queries a cloudstack API 
endpoint for instances having a specific tag.

The tag key and value can be controlled in the configuration file and   
  
will default to 'cassandra_seed' and 'default'. 
  

The Cloudstack endpoint is configured by three parameters in the
  
configuration file: 'cloudstack_api_endpoint', 'cloudstack_api_key' and 
  
'cloudstack_api_secret' 
  

By default, CloudstackSeedProvider fetchs the ipaddress of the first
  
interface, if another index should be used, the nic_index parameter will hold 
it.

A typical configuration file would thus have:

{code:yaml}
seed_provider:
- class_name: org.apache.cassandra.locator.CloudstackSeedProvider
  parameters:
  - cloudstack_api_endpoint: https://some.cloudstack.host;
cloudstack_api_key: X
cloudstack_api_secret: X
tag_value: my_cluster_name
{code}

This introduces no new dependency and together with CLOUDSTACK-7147 gives an 
easy way of getting started on cloudstack platforms


 Add a new seed provider for Apache Cloudstack platforms
 ---

 Key: CASSANDRA-7156
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7156
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: needs access to a cloudstack API endpoint
Reporter: Pierre-Yves Ritschard
Priority: Minor
 Fix For: 2.0.8, 2.1.1

 Attachments: 0001-initial-work-on-a-cloudstack-seed-provider.patch


 The attached patch adds a new seed provider which queries a cloudstack API 
 endpoint for instances having a specific tag.
 The tag key and value can be controlled in the configuration file and 
 
 will default to 'cassandra_seed' and 'default'.   
 
 The Cloudstack endpoint is configured by three parameters in the  
 
 configuration file: 'cloudstack_api_endpoint', 'cloudstack_api_key' and   
 
 'cloudstack_api_secret'   
 
 By default, CloudstackSeedProvider fetchs the ipaddress of the first

[jira] [Commented] (CASSANDRA-7156) Add a new seed provider for Apache Cloudstack platforms