Re: NGCC?

[Mark Dewey]

Blot out the sun and talk about Cassandra? Seems kind of on the nose, right?

On Fri, Jun 2, 2017 at 8:53 AM Russell Bradberry 
wrote:

> I’m just throwing this out there, mostly because I’m a science nerd, but
> why not August 21st in the viewability range for the Solar eclipse?  Here
> is a map showing the best viewing areas.
> http://www.eclipse2017.org/2017/maps.htm (
>
>
> Thanks,
> -Russ
>
>
> On 6/1/17, 2:03 PM, "Jason Brown"  wrote:
>
> I kind of agree with Russ, here. However, at the same time, a
> once-a-year,
> in-person meeting that not everyone can physically attend isn't the
> only
> avenue to bring up issues for discussion. All
> influencers/developers/power
> users/whatevers should be encouraged to start discussions on the dev@
> ML,
> at anytime. In addition to being more in the Apache Way, it's
> trackable,
> maintains history, and is publicly open to everyone. Traditionally, we
> as a
> community haven't done so well with dev@ discussions, although I
> think it's
> better than a few years ago and we are improving.
>
> All this being said, I think having an in-person get together of the
> developers (and any others) to help discuss roadmap, new and crazy
> ideas
> wrt implementation, and just generally hang out is good thing. As space
> usually follows budget, if we end up constrained for a NGCC, we may
> need to
> be more (or less) selective than in years past -  I don't know how
> that'll
> happen, but perhaps we can find a way with PMC voting or something
> along
> those lines.
>
> I like the idea of a NGCC, but we shouldn't subscribe to it as the only
> medium for discussions of big issues/features/concerns.
>
> -Jason
>
> p.s. Yes, Jira can serve a similar purpose as a dev@ thread, but it's
> usually not a great place to have design discussions of large features
> (I'm
> guilty of this).
>
> On Thu, Jun 1, 2017 at 10:09 AM, K.Tomita 
> wrote:
>
> > I'm organizer for Cassandra Summit Tokyo.
> > we are Cassandra user's group of Japan.
> > We're planning to hold a conference by Tokyo to invite some
> committers
> > at a first week in October.
> > I'm preparing in order to announce it while being close.
> >
> > And I welcome NGCC.
> > As far as possible , I'd like to cooperate.
> >
> >
> > ** I hope tomorrow will be a good day **
> >
> >Tomita Kazutaka
> >
> >  mailto:tomitakazut...@gmail.com
> >  blog  : http://www.intheforest.jp/blog/
> >  twitter:http://twitter.com/railute
> > *       
> >
> >
> > 2017-06-02 1:02 GMT+09:00 Russell Bradberry :
> > >> read: developers *of* Cassandra
> > >
> > > Historically it has not only been developers of Cassandra but also
> > specific power users, influencers, and experts.  If you want to be
> > successful in deciding the direction of a product, you need more
> than its
> > developers present.  For instance, I am not a Cassandra developer,
> but I
> > have been invited every year. Same with folks like Peter Bailis, Rick
> > Branson, and others who come in with a wealth of knowledge around
> varying
> > use cases.  Unfortunately, I missed that last two years, but was
> hoping to
> > make it this year.
> > >
> > > -Russ
> > >
> > > On 6/1/17, 11:53 AM, "Eric Evans" 
> wrote:
> > >
> > > On Wed, May 31, 2017 at 2:19 PM, Eric Evans <
> > john.eric.ev...@gmail.com> wrote:
> > > > Hi,
> > > >
> > > > Is anyone working on an NGCC event for this year? Given all
> of the
> > > > recent changes, it seems like it could be really useful. If
> not, is
> > > > there interest? When would be good, September? October? What
> about
> > > > location? I think we could get the space to host such an
> even in
> > > > either San Antonio (centrally located), or San Francisco (San
> > > > Franciscoly located).
> > > >
> > > > Thoughts?
> > >
> > > And to be clear:
> > >
> > > NGCC == Next Generation Cassandra Conference
> > >
> > > And conference may or may not be a misnomer here.  I think
> what we're
> > > talking about is more of a meeting of Cassandra developers
> (read:
> > > developers *of* Cassandra), to discuss their respective needs /
> > plans,
> > > and to talk about how that might fit into a project road map.
> > >
> > > IMO, a successful event would result in ideas and help inform
> > > consensus about where the project is going, what is important,
> and
> > who
> > > is willing to collaborate on what.  I do not see this as a
> place
> > where
> > > actual decisions would be 

Re: splitting CQL parser & spec into separate repo

[Mark Dewey]

I can immediately think of a project I would use that in. +1

On Tue, Mar 21, 2017 at 12:18 PM Jonathan Haddad  wrote:

> I created CASSANDRA-13284 a few days ago with the intent of starting a
> discussion around the topic of breaking the CQL parser out into a separate
> project.  I see a few benefits to doing it and was wondering what the folks
> here thought as well.
>
> First off, the Java CQL parser would obviously continue to be the reference
> parser.  I'd love to see other languages have CQL parsers as well, but the
> intent here isn't for the OSS C* team to be responsible for maintaining
> that.  My vision here is simply the ability to have some high level
> CQLParser.parse(statement) call that returns the parse tree, nothing more.
>
> It would be nice to be able to leverage that parser in other projects such
> as IDEs, code gen tools, etc.  It would be outstanding to be able to create
> the parser tests in such a way that they can be referenced by other parsers
> in other languages.  Yay code reuse.  It also has the benefit of making the
> codebase a little more modular and a bit easier to understand.
>
> Thoughts?
>
> Jon
>

Re: Can I replace a 2.0.9 node with a 2.1.14 node in a cluster?

[Mark Dewey]

If by one-by-one you mean you want to upgrade one after the other doing a
rolling restart of each node along the way, yes, that is doable and
recommended. C* guarantees interoperability between minor versions, ie
2.0.x and 2.1.x in this example. Check your changes.txt file for any
upgrade gotchas like new mandatory configs and the like.

What Carlos was warning you against is upgrading just one and leaving it
that way for a long time.

Mark

On Fri, May 6, 2016 at 2:41 AM Carlos Rolo  wrote:

> Don't do that.
>
> In any case an upgrade between 2.0.x and 2.1.x is not so complex and
> difficult to do. And it is "downtime free". I would get the opportunity to
> do a full cluster upgrade.
>
> Regards,
>
> Carlos Juzarte Rolo
> Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
>
> Pythian - Love your data
>
> rolo@pythian | Twitter: @cjrolo | Skype: cjr2k3 | Linkedin:
> *linkedin.com/in/carlosjuzarterolo
> *
> Mobile: +351 918 918 100
> www.pythian.com
>
> On Thu, May 5, 2016 at 4:54 PM, Li, Guangxing 
> wrote:
>
> > Hi,
> >
> > due to internal infrastructure changes, we have to replace all nodes with
> > new nodes. All the existing nodes are running Cassandra Community version
> > 2.0.9. I was thinking may be this is also an opportunity for us to
> upgrade
> > to Cassandra Community version 2.1.14. I hope I am not asking a crazy
> > question: But can I replace a 2.0.9 node with a 2.1.14 node in the
> cluster,
> > i.e. can 2.0.9 nodes and 2.1.14 nodes work peacefully together in a
> cluster
> > if I replace 2.0.9 nodes with 2.1.14 nodes one by one?
> >
> > Thanks.
> >
> > George.
> >
>
> --
>
>
> --
>
>
>
>

Re: Versioning policy?

[Mark Dewey]

Let's do a couple examples:

   1. Current release: 3.4.0, bug found in 3.1.0 that also exists in
   subsequent versions; the bug fix will be ported back to 3.0.x and 3.5.0.
   2. Current release 3.3.0, bug found in 3.3.0; the bug fix will be ported
   back to 3.0.x and 3.4.0. In rare cases, a 3.3.1 may also be released (we've
   already seen one example of this).
   3. Current release 3.6.0, bug found in 3.1.0; the bug fix will be ported
   back to 3.0.x and 3.7.

Essentially, any bug fixes will be released in the next minor version and
backported to the 3.0.x branches (unless the feature doesn't exist in 3.0).
We have seen one instance where we released a point version as well, but
that was for a major regression that was discovered almost immediately
after a release.

On Wed, Jan 13, 2016 at 12:55 PM Maciek Sakrejda  wrote:

> Can anyone chime in here? We're getting ready to run a decent number of
> nodes; we'd like to have a better idea of what to expect with respect to
> patching and upgrading. A clear versioning policy like the one laid out by
> Postgres would be very helpful.
> ​
>

nosetests

[Mark Dewey]

I thought I followed the instructions to set up the nose tests, but when I
run them all they do is (slowly) print out .E and then hang. Any clues?

Mark

Re: nosetests

[Mark Dewey]

PS I got the following trace when I aborted.

Traceback (most recent call last):
  File /usr/bin/nosetests, line 9, in module
load_entry_point('nose==0.11.4', 'console_scripts', 'nosetests')()
  File /usr/lib/pymodules/python2.7/nose/core.py, line 117, in __init__
**extra_args)
  File /usr/lib/python2.7/unittest/main.py, line 95, in __init__
self.runTests()
  File /usr/lib/pymodules/python2.7/nose/core.py, line 196, in runTests
result = self.testRunner.run(self.test)
  File /usr/lib/pymodules/python2.7/nose/core.py, line 61, in run
test(result)
  File /usr/lib/pymodules/python2.7/nose/suite.py, line 176, in __call__
return self.run(*arg, **kw)
  File /usr/lib/pymodules/python2.7/nose/suite.py, line 223, in run
test(orig)
  File /usr/lib/pymodules/python2.7/nose/suite.py, line 176, in __call__
return self.run(*arg, **kw)
  File /usr/lib/pymodules/python2.7/nose/suite.py, line 223, in run
test(orig)
  File /usr/lib/pymodules/python2.7/nose/suite.py, line 176, in __call__
return self.run(*arg, **kw)
  File /usr/lib/pymodules/python2.7/nose/suite.py, line 223, in run
test(orig)
  File /usr/lib/pymodules/python2.7/nose/suite.py, line 176, in __call__
return self.run(*arg, **kw)
  File /usr/lib/pymodules/python2.7/nose/suite.py, line 223, in run
test(orig)
  File /usr/lib/pymodules/python2.7/nose/case.py, line 44, in __call__
return self.run(*arg, **kwarg)
  File /usr/lib/pymodules/python2.7/nose/case.py, line 132, in run
self.runTest(result)
  File /usr/lib/pymodules/python2.7/nose/case.py, line 150, in runTest
test(result)
  File /usr/lib/python2.7/unittest/case.py, line 385, in __call__
return self.run(*args, **kwds)
  File /usr/lib/python2.7/unittest/case.py, line 312, in run
self.setUp()
  File /usr/lib/pymodules/python2.7/nose/case.py, line 367, in setUp
try_run(self.inst, ('setup', 'setUp'))
  File /usr/lib/pymodules/python2.7/nose/util.py, line 491, in try_run
return func()
  File /home/mildewey/Projects/cassandra/test/system/__init__.py, line
113, in setUp
self.define_schema()
  File /home/mildewey/Projects/cassandra/test/system/__init__.py, line
180, in define_schema
self.client.system_add_keyspace(ks)
  File
/home/mildewey/Projects/cassandra/interface/thrift/gen-py/cassandra/Cassandra.py,
line 1440, in system_add_keyspace
return self.recv_system_add_keyspace()
  File
/home/mildewey/Projects/cassandra/interface/thrift/gen-py/cassandra/Cassandra.py,
line 1451, in recv_system_add_keyspace
(fname, mtype, rseqid) = self._iprot.readMessageBegin()
  File
/usr/local/lib/python2.7/dist-packages/thrift/protocol/TBinaryProtocol.py,
line 137, in readMessageBegin
name = self.trans.readAll(sz)
  File
/usr/local/lib/python2.7/dist-packages/thrift/transport/TTransport.py,
line 58, in readAll
chunk = self.read(sz-have)
  File
/usr/local/lib/python2.7/dist-packages/thrift/transport/TTransport.py,
line 272, in read
self.readFrame()
  File
/usr/local/lib/python2.7/dist-packages/thrift/transport/TTransport.py,
line 276, in readFrame
buff = self.__trans.readAll(4)
  File
/usr/local/lib/python2.7/dist-packages/thrift/transport/TTransport.py,
line 58, in readAll
chunk = self.read(sz-have)
  File
/usr/local/lib/python2.7/dist-packages/thrift/transport/TSocket.py, line
94, in read
buff = self.handle.recv(sz)


On Sat, Apr 14, 2012 at 1:34 PM, Mark Dewey milde...@gmail.com wrote:

 I thought I followed the instructions to set up the nose tests, but when I
 run them all they do is (slowly) print out .E and then hang. Any clues?

 Mark

Re: nosetests

[Mark Dewey]

With the =ve I got 92 copies of this (one for each test):

==
ERROR: system.test_thrift_server.TestTruncate.test_truncate
--
Traceback (most recent call last):
  File /usr/lib/pymodules/python2.7/nose/case.py, line 367, in setUp
try_run(self.inst, ('setup', 'setUp'))
  File /usr/lib/pymodules/python2.7/nose/util.py, line 491, in try_run
return func()
  File /home/mildewey/Projects/cassandra/test/system/__init__.py, line
68, in setUp
sys.exit()
SystemExit:
  begin captured stdout  -
Unclean shutdown detected,
(/home/mildewey/Projects/cassandra/system_test.pid found)

-  end captured stdout  --


On Sat, Apr 14, 2012 at 2:33 PM, Brandon Williams dri...@gmail.com wrote:

 Try nosetests -ve to see which one is failing and exit on the first error.
 On Apr 14, 2012 1:34 PM, Mark Dewey milde...@gmail.com wrote:

 I thought I followed the instructions to set up the nose tests, but when I
 run them all they do is (slowly) print out .E and then hang. Any clues?

 Mark

CASSANDRA-3885

[Mark Dewey]

I realize multiple people may be working on this, so maybe some discussion
would help?

CASSANDRA-3885 https://issues.apache.org/jira/browse/CASSANDRA-3885

Should we just copy the way this is handled in NamesQueryFilter? Or am I
missing something obvious?

Mark

Re: CASSANDRA-3885

[Mark Dewey]

I can't seem to divine from the code what count is being used for. Is it
describing the number of elements that are being accessed? Is it the third
dimension on the columns being accessed?

On another note, and I asked something about this earlier, but I may have
been using the wrong terminology: Is there a preferred way to store these
pairs of start and end columns? A list? A sorted set? should the elements
be stored in pairs? or just assumed to be put into the list/set in pairs?

Mark

On Sat, Apr 7, 2012 at 5:30 PM, Jonathan Ellis jbel...@gmail.com wrote:

 In the sense that you have a collection of columns to select from the
 given row, yes, this is pretty straightforward.  The only real wrinkle
 is, it's clear that you need pairs of start + end columns to select,
 but what about count?  Should there be a sub-count per slice, or one
 master count for the entire filter?

 On Sat, Apr 7, 2012 at 4:20 PM, Mark Dewey milde...@gmail.com wrote:
  I realize multiple people may be working on this, so maybe some
 discussion
  would help?
 
  CASSANDRA-3885 https://issues.apache.org/jira/browse/CASSANDRA-3885
 
  Should we just copy the way this is handled in NamesQueryFilter? Or am I
  missing something obvious?
 
  Mark



 --
 Jonathan Ellis
 Project Chair, Apache Cassandra
 co-founder of DataStax, the source for professional Cassandra support
 http://www.datastax.com