Re: Use of OpOrder in memtable

[Benedict Elliott Smith]

Right.  Although IIRC there is another OpOrder that coordinates the
migration of readers from memtables to the sstables that replace them (and
the reclamation of any off-heap memory associated with the memtable)

On 13 February 2018 at 22:59, Tyagi, Preetika 
wrote:

> Ah I see. That makes sense.
> And it doesn't have to anything with the read requests going on in
> parallel with write requests, right?
> I mean we read the data from memtable depending on whatever has been
> written into memtable so far and return it to the client (of course
> including SSTable read and timestamp comparison etc.)
>
> -Original Message-
> From: Benedict Elliott Smith [mailto:bened...@apache.org]
> Sent: Tuesday, February 13, 2018 2:25 PM
> To: dev@cassandra.apache.org
> Subject: Re: Use of OpOrder in memtable
>
> If you look closely, there can be multiple memtables extant at once.
> While all "new" writes are routed to the latest memtable, there may still
> be writes that have begun but not yet completed.  The memtable cannot be
> flushed until any stragglers have completed, and some stragglers *may*
> still need to be routed to their designated memtable (if they had only just
> begun when the flush triggered).  It helps avoid these race conditions on
> either side of the equation.
>
> On 13 February 2018 at 22:09, Tyagi, Preetika 
> wrote:
>
> > Hi all,
> >
> > I'm trying to understand the behavior of memtable when writes/flush
> > operations are going on in parallel.
> >
> > In my understanding, once a memtable is full it is queued for flushing
> > and a new memtable is created for ongoing write operations.
> > However, I was looking at the code and it looks like the OpOrder class
> > is used (don't understand all details) to ensure the synchronization
> > between producers (writes) and consumers (batch flushes).
> > So I am a bit confused about when exactly it is needed. There will
> > always be only one latest memtable for write operations and all old
> > memtables are flushed so where this producer/consumer interaction on
> > the same memtable is needed?
> >
> > Thanks,
> > Preetika
> >
> >
>

Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

[Jason Brown]

Thank you, Kurt. I'll get to it within the next 12-24 hours (kids' homework
time in the U.S. now ;) )

-Jason

On Tue, Feb 13, 2018 at 5:10 PM, kurt greaves  wrote:

> CASSANDRA-14234 
> patch
> in for ReadCommandTest if anyone wants to take a look.
>
> On 14 February 2018 at 00:45, kurt greaves  wrote:
>
> > ​ReadCommandTest is still not passing. I would be a happy maintainer if
> >> someone could step up and analyze and contribute a patch; I will review.
> >
> >
> > Having a look. Appears to be just a case of using the same CF for
> multiple
> > tests and metrics (tombstone histograms) aren't cleared in between.
> >
>

Re: row tombstones as a separate sstable citizen

[Carl Mueller]

I'm particularly interested in getting the tombstones to "promote" up the
levels of LCS more quickly. Currently they get attached at the low level
and don't propagate up to higher levels until enough activity at a lower
level promotes the data. Meanwhile, LCS means compactions can occur in
parallel at each level. So row tombstones in their own sstable could be up
promoted the LCS levels preferentially before normal processes would move
them up.

So if the delete-only sstables could move up more quickly, the compaction
at the levels would happen more quickly.

The threshold stuff is nice if I read 7019 correctly, but what is the %
there? % of rows? % of columns? or % of the size of the sstable? Row
tombstones are pretty compact being just the rowkey and the tombstone
marker. So if 7019 is triggered at 10% of the sstable size, even a crapton
of tombstones deleting practially the entire database would only be a small
% size of the sstable.

Since the row tombstones are so compact, that's why I think they are good
candidates for special handling.

On Tue, Feb 13, 2018 at 5:22 PM, J. D. Jordan 
wrote:

> Have you taken a look at the new stuff introduced by
> https://issues.apache.org/jira/browse/CASSANDRA-7019 ?  I think it may go
> a ways to reducing the need for something complicated like this.
> Though it is an interesting idea as special handling for bulk deletes.  If
> they were truly just sstables that only contained deletes the logic from
> 7109 would probably go a long ways. Though if you are bulk inserting
> deletes that is what you would end up with, so maybe it already works.
>
> -Jeremiah
>
> > On Feb 13, 2018, at 6:04 PM, Jeff Jirsa  wrote:
> >
> > On Tue, Feb 13, 2018 at 2:38 PM, Carl Mueller <
> carl.muel...@smartthings.com>
> > wrote:
> >
> >> In process of doing my second major data purge from a cassandra system.
> >>
> >> Almost all of my purging is done via row tombstones. While performing
> this
> >> the second time while trying to cajole compaction to occur (in 2.1.x,
> >> LevelledCompaction) to goddamn actually compact the data, I've been
> >> thinking as to why there isn't a separate set of sstable infrastructure
> >> setup for row deletion tombstones.
> >>
> >> I'm imagining that row tombstones are written to separate sstables than
> >> mainline data updates/appends and range/column tombstones.
> >>
> >> By writing them to separate sstables, the compaction systems can
> >> preferentially merge / process them when compacting sstables.
> >>
> >> This would create an additional sstable for lookup in the bloom filters,
> >> granted. I had visions of short circuiting the lookups to other
> sstables if
> >> a row tombstone was present in one of the special row tombstone
> sstables.
> >>
> >>
> > All of the above sounds really interesting to me, but I suspect it's a
> LOT
> > of work to make it happen correctly.
> >
> > You'd almost end up with 2 sets of logs for the LSM - a tombstone
> > log/generation, and a data log/generation, and the tombstone logs would
> be
> > read-only inputs to data compactions.
> >
> >
> >> But that would only be possible if there was the notion of a "super row
> >> tombstone" that permanently deleted a rowkey and all future writes
> would be
> >> invalidated. Kind of like how a tombstone with a mistakenly huge
> timestamp
> >> becomes a sneaky permanent tombstone, but intended. There could be a
> >> special operation / statement to undo this permanent tombstone, and
> since
> >> the row tombstones would be in their own dedicated sstables, they could
> >> process and compact more quickly, with prioritization by the compactor.
> >>
> >>
> > This part sounds way less interesting to me (other than the fact you can
> > already do this with a timestamp in the future, but it'll gc away at
> gcgs).
> >
> >
> >> I'm thinking there must be something I am forgetting in the
> >> read/write/compaction paths that invalidate this.
> >>
> >
> > There are a lot of places where we do "smart" things to make sure we
> don't
> > accidentally resurrect data. Read path includes old sstables for
> tombstones
> > for example. Those all need to be concretely identified and handled (and
> > tested),.
>

Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

[kurt greaves]

CASSANDRA-14234  patch
in for ReadCommandTest if anyone wants to take a look.

On 14 February 2018 at 00:45, kurt greaves  wrote:

> ​ReadCommandTest is still not passing. I would be a happy maintainer if
>> someone could step up and analyze and contribute a patch; I will review.
>
>
> Having a look. Appears to be just a case of using the same CF for multiple
> tests and metrics (tombstone histograms) aren't cleared in between.
>

Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

[kurt greaves]

>
> ​ReadCommandTest is still not passing. I would be a happy maintainer if
> someone could step up and analyze and contribute a patch; I will review.


Having a look. Appears to be just a case of using the same CF for multiple
tests and metrics (tombstone histograms) aren't cleared in between.

Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

[Jason Brown]

CASSANDRA-14219 is committed, and ViewComplexTest is now green (
https://circleci.com/workflow-run/b1456e1c-c775-4fcb-82a1-ad3a00ced0d8).

ReadCommandTest is still not passing. I would be a happy maintainer if
someone could step up and analyze and contribute a patch; I will review.

On Tue, Feb 13, 2018 at 1:47 PM, Brandon Williams  wrote:

> I change my vote to -1 binding here, too.
>
> On Tue, Feb 13, 2018 at 3:45 PM, Jason Brown  wrote:
>
> > -1, binding. Unit tests are broken:
> > https://circleci.com/gh/jasobrown/cassandra/452#tests/containers/60
> > 
> >
> > Dave ninja-committed 7df36056b12a13b60097b7a9a4f8155a1d02ff62 to update
> > some logging messages, which broke ViewComplexTest. The errors like this:
> >
> > junit.framework.AssertionFailedError: Expected error message to contain
> > 'Cannot drop column a on base table with materialized views', but got
> > 'Cannot drop column a on base table table_21 with materialized views.'
> >
> > Dave has a followup commit, 40148a178bd9b74b731591aa46b4158efb16b742,
> > which
> > fixed a few of the errors, but there are four outstanding failures. I
> > created CASSANDRA-14219 last week, and assigned it to Dave, but he might
> > have missed the notification. Dinesh Joshi has a patch that I will review
> > ASAP.
> >
> > There is also another test which is failing: testCountWithNoDeletedRow -
> > org.apache.cassandra.db.ReadCommandTest
> >
> > junit.framework.AssertionFailedError: expected:<1> but was:<5>
> >
> > I have not investigated that error. It would be great if someone from the
> > community can do so.
> >
> > Michael, is there a link of where you ran the tests? If so, can you
> include
> > it in the future [VOTE] emails?
> >
> > Thanks,
> >
> > -Jason
> >
> >
> > On Tue, Feb 13, 2018 at 10:53 AM, Josh McKenzie 
> > wrote:
> >
> > > +1
> > >
> > > On Feb 13, 2018 9:36 AM, "Gary Dusbabek"  wrote:
> > >
> > > > +1
> > > >
> > > > On Mon, Feb 12, 2018 at 9:40 PM, Michael Shuler <
> > mich...@pbandjelly.org>
> > > > wrote:
> > > >
> > > > > I propose the following artifacts for release as 3.11.2.
> > > > >
> > > > > sha1: 8a5e88f635fdb984505a99a553b5799cedccd06d
> > > > > Git:
> > > > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > > > shortlog;h=refs/tags/3.11.2-tentative
> > > > > Artifacts:
> > > > > https://repository.apache.org/content/repositories/
> > > > > orgapachecassandra-1156/org/apache/cassandra/apache-
> > cassandra/3.11.2/
> > > > > Staging repository:
> > > > > https://repository.apache.org/content/repositories/
> > > > > orgapachecassandra-1156/
> > > > >
> > > > > Debian and RPM packages are available here:
> > > > > http://people.apache.org/~mshuler
> > > > >
> > > > > *** This release addresses an important fix for CASSANDRA-14092 ***
> > > > > "Max ttl of 20 years will overflow localDeletionTime"
> > > > > https://issues.apache.org/jira/browse/CASSANDRA-14092
> > > > >
> > > > > The vote will be open for 72 hours (longer if needed).
> > > > >
> > > > > [1]: (CHANGES.txt) https://goo.gl/RLZLrR
> > > > > [2]: (NEWS.txt) https://goo.gl/kpnVHp
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Release Apache Cassandra 3.0.16

[Jason Brown]

CASSANDRA-14219 is committed and tests look clean (
https://circleci.com/workflow-run/d0a2622a-e74f-4c46-b0ad-a84ca063736f).

On Tue, Feb 13, 2018 at 1:47 PM, Brandon Williams  wrote:

> I change my vote to -1 binding as well.
>
> On Tue, Feb 13, 2018 at 3:43 PM, Jason Brown  wrote:
>
> > -1, binding. Unit tests are broken:
> > https://circleci.com/gh/jasobrown/cassandra/451#tests/containers/50
> >
> > Dave ninja-committed 7df36056b12a13b60097b7a9a4f8155a1d02ff62 to update
> > some logging messages, which broke ViewComplexTest. The errors like this:
> >
> > junit.framework.AssertionFailedError: Expected error message to contain
> > 'Cannot drop column a on base table with materialized views', but got
> > 'Cannot drop column a on base table table_21 with materialized views.'
> >
> > Dave has a followup commit, 40148a178bd9b74b731591aa46b4158efb16b742,
> > which
> > fixed a few of the errors, but there are four outstanding failures. I
> > created CASSANDRA-14219 last week, and assigned it to Dave, but he might
> > have missed the notification. Dinesh Joshi has a patch that I will review
> > ASAP.
> >
> > Michael, is there a link of where you ran the tests? If so, can you
> include
> > it in the future [VOTE] emails?
> >
> > Thanks,
> >
> > -Jason
> >
> >
> >
> > On Tue, Feb 13, 2018 at 11:03 AM, Jon Haddad  wrote:
> >
> > > +1
> > >
> > > > On Feb 13, 2018, at 10:52 AM, Josh McKenzie 
> > > wrote:
> > > >
> > > > +1
> > > >
> > > > On Feb 13, 2018 9:20 AM, "Marcus Eriksson" 
> wrote:
> > > >
> > > >> +1
> > > >>
> > > >> On Tue, Feb 13, 2018 at 1:29 PM, Aleksey Yeshchenko <
> > alek...@apple.com>
> > > >> wrote:
> > > >>
> > > >>> +1
> > > >>>
> > > >>> —
> > > >>> AY
> > > >>>
> > > >>> On 12 February 2018 at 20:31:23, Michael Shuler (
> > > mich...@pbandjelly.org)
> > > >>> wrote:
> > > >>>
> > > >>> I propose the following artifacts for release as 3.0.16.
> > > >>>
> > > >>> sha1: 91e83c72de109521074b14a8eeae1309c3b1f215
> > > >>> Git:
> > > >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > >>> shortlog;h=refs/tags/3.0.16-tentative
> > > >>> Artifacts:
> > > >>> https://repository.apache.org/content/repositories/
> > > >>> orgapachecassandra-1154/org/apache/cassandra/apache-
> > cassandra/3.0.16/
> > > >>> Staging repository:
> > > >>> https://repository.apache.org/content/repositories/
> > > >>> orgapachecassandra-1154/
> > > >>>
> > > >>> Debian and RPM packages are available here:
> > > >>> http://people.apache.org/~mshuler
> > > >>>
> > > >>> *** This release addresses an important fix for CASSANDRA-14092 ***
> > > >>> "Max ttl of 20 years will overflow localDeletionTime"
> > > >>> https://issues.apache.org/jira/browse/CASSANDRA-14092
> > > >>>
> > > >>> The vote will be open for 72 hours (longer if needed).
> > > >>>
> > > >>> [1]: (CHANGES.txt) https://goo.gl/rLj59Z
> > > >>> [2]: (NEWS.txt) https://goo.gl/EkrT4G
> > > >>>
> > > >>>
> > > >>
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: row tombstones as a separate sstable citizen

[J. D. Jordan]

Have you taken a look at the new stuff introduced by 
https://issues.apache.org/jira/browse/CASSANDRA-7019 ?  I think it may go a 
ways to reducing the need for something complicated like this.
Though it is an interesting idea as special handling for bulk deletes.  If they 
were truly just sstables that only contained deletes the logic from 7109 would 
probably go a long ways. Though if you are bulk inserting deletes that is what 
you would end up with, so maybe it already works.

-Jeremiah

> On Feb 13, 2018, at 6:04 PM, Jeff Jirsa  wrote:
> 
> On Tue, Feb 13, 2018 at 2:38 PM, Carl Mueller 
> wrote:
> 
>> In process of doing my second major data purge from a cassandra system.
>> 
>> Almost all of my purging is done via row tombstones. While performing this
>> the second time while trying to cajole compaction to occur (in 2.1.x,
>> LevelledCompaction) to goddamn actually compact the data, I've been
>> thinking as to why there isn't a separate set of sstable infrastructure
>> setup for row deletion tombstones.
>> 
>> I'm imagining that row tombstones are written to separate sstables than
>> mainline data updates/appends and range/column tombstones.
>> 
>> By writing them to separate sstables, the compaction systems can
>> preferentially merge / process them when compacting sstables.
>> 
>> This would create an additional sstable for lookup in the bloom filters,
>> granted. I had visions of short circuiting the lookups to other sstables if
>> a row tombstone was present in one of the special row tombstone sstables.
>> 
>> 
> All of the above sounds really interesting to me, but I suspect it's a LOT
> of work to make it happen correctly.
> 
> You'd almost end up with 2 sets of logs for the LSM - a tombstone
> log/generation, and a data log/generation, and the tombstone logs would be
> read-only inputs to data compactions.
> 
> 
>> But that would only be possible if there was the notion of a "super row
>> tombstone" that permanently deleted a rowkey and all future writes would be
>> invalidated. Kind of like how a tombstone with a mistakenly huge timestamp
>> becomes a sneaky permanent tombstone, but intended. There could be a
>> special operation / statement to undo this permanent tombstone, and since
>> the row tombstones would be in their own dedicated sstables, they could
>> process and compact more quickly, with prioritization by the compactor.
>> 
>> 
> This part sounds way less interesting to me (other than the fact you can
> already do this with a timestamp in the future, but it'll gc away at gcgs).
> 
> 
>> I'm thinking there must be something I am forgetting in the
>> read/write/compaction paths that invalidate this.
>> 
> 
> There are a lot of places where we do "smart" things to make sure we don't
> accidentally resurrect data. Read path includes old sstables for tombstones
> for example. Those all need to be concretely identified and handled (and
> tested),.

Re: row tombstones as a separate sstable citizen

[Jeff Jirsa]

On Tue, Feb 13, 2018 at 2:38 PM, Carl Mueller 
wrote:

> In process of doing my second major data purge from a cassandra system.
>
> Almost all of my purging is done via row tombstones. While performing this
> the second time while trying to cajole compaction to occur (in 2.1.x,
> LevelledCompaction) to goddamn actually compact the data, I've been
> thinking as to why there isn't a separate set of sstable infrastructure
> setup for row deletion tombstones.
>
> I'm imagining that row tombstones are written to separate sstables than
> mainline data updates/appends and range/column tombstones.
>
> By writing them to separate sstables, the compaction systems can
> preferentially merge / process them when compacting sstables.
>
> This would create an additional sstable for lookup in the bloom filters,
> granted. I had visions of short circuiting the lookups to other sstables if
> a row tombstone was present in one of the special row tombstone sstables.
>
>
All of the above sounds really interesting to me, but I suspect it's a LOT
of work to make it happen correctly.

You'd almost end up with 2 sets of logs for the LSM - a tombstone
log/generation, and a data log/generation, and the tombstone logs would be
read-only inputs to data compactions.


> But that would only be possible if there was the notion of a "super row
> tombstone" that permanently deleted a rowkey and all future writes would be
> invalidated. Kind of like how a tombstone with a mistakenly huge timestamp
> becomes a sneaky permanent tombstone, but intended. There could be a
> special operation / statement to undo this permanent tombstone, and since
> the row tombstones would be in their own dedicated sstables, they could
> process and compact more quickly, with prioritization by the compactor.
>
>
This part sounds way less interesting to me (other than the fact you can
already do this with a timestamp in the future, but it'll gc away at gcgs).


> I'm thinking there must be something I am forgetting in the
> read/write/compaction paths that invalidate this.
>

There are a lot of places where we do "smart" things to make sure we don't
accidentally resurrect data. Read path includes old sstables for tombstones
for example. Those all need to be concretely identified and handled (and
tested),.

RE: Use of OpOrder in memtable

[Tyagi, Preetika]

Ah I see. That makes sense.
And it doesn't have to anything with the read requests going on in parallel 
with write requests, right?
I mean we read the data from memtable depending on whatever has been written 
into memtable so far and return it to the client (of course including SSTable 
read and timestamp comparison etc.)

-Original Message-
From: Benedict Elliott Smith [mailto:bened...@apache.org] 
Sent: Tuesday, February 13, 2018 2:25 PM
To: dev@cassandra.apache.org
Subject: Re: Use of OpOrder in memtable

If you look closely, there can be multiple memtables extant at once.  While all 
"new" writes are routed to the latest memtable, there may still be writes that 
have begun but not yet completed.  The memtable cannot be flushed until any 
stragglers have completed, and some stragglers *may* still need to be routed to 
their designated memtable (if they had only just begun when the flush 
triggered).  It helps avoid these race conditions on either side of the 
equation.

On 13 February 2018 at 22:09, Tyagi, Preetika 
wrote:

> Hi all,
>
> I'm trying to understand the behavior of memtable when writes/flush 
> operations are going on in parallel.
>
> In my understanding, once a memtable is full it is queued for flushing 
> and a new memtable is created for ongoing write operations.
> However, I was looking at the code and it looks like the OpOrder class 
> is used (don't understand all details) to ensure the synchronization 
> between producers (writes) and consumers (batch flushes).
> So I am a bit confused about when exactly it is needed. There will 
> always be only one latest memtable for write operations and all old 
> memtables are flushed so where this producer/consumer interaction on 
> the same memtable is needed?
>
> Thanks,
> Preetika
>
>

row tombstones as a separate sstable citizen

[Carl Mueller]

In process of doing my second major data purge from a cassandra system.

Almost all of my purging is done via row tombstones. While performing this
the second time while trying to cajole compaction to occur (in 2.1.x,
LevelledCompaction) to goddamn actually compact the data, I've been
thinking as to why there isn't a separate set of sstable infrastructure
setup for row deletion tombstones.

I'm imagining that row tombstones are written to separate sstables than
mainline data updates/appends and range/column tombstones.

By writing them to separate sstables, the compaction systems can
preferentially merge / process them when compacting sstables.

This would create an additional sstable for lookup in the bloom filters,
granted. I had visions of short circuiting the lookups to other sstables if
a row tombstone was present in one of the special row tombstone sstables.

But that would only be possible if there was the notion of a "super row
tombstone" that permanently deleted a rowkey and all future writes would be
invalidated. Kind of like how a tombstone with a mistakenly huge timestamp
becomes a sneaky permanent tombstone, but intended. There could be a
special operation / statement to undo this permanent tombstone, and since
the row tombstones would be in their own dedicated sstables, they could
process and compact more quickly, with prioritization by the compactor.

I'm thinking there must be something I am forgetting in the
read/write/compaction paths that invalidate this.

Re: Use of OpOrder in memtable

[Benedict Elliott Smith]

If you look closely, there can be multiple memtables extant at once.  While
all "new" writes are routed to the latest memtable, there may still be
writes that have begun but not yet completed.  The memtable cannot be
flushed until any stragglers have completed, and some stragglers *may* still
need to be routed to their designated memtable (if they had only just begun
when the flush triggered).  It helps avoid these race conditions on either
side of the equation.

On 13 February 2018 at 22:09, Tyagi, Preetika 
wrote:

> Hi all,
>
> I'm trying to understand the behavior of memtable when writes/flush
> operations are going on in parallel.
>
> In my understanding, once a memtable is full it is queued for flushing and
> a new memtable is created for ongoing write operations.
> However, I was looking at the code and it looks like the OpOrder class is
> used (don't understand all details) to ensure the synchronization between
> producers (writes) and consumers (batch flushes).
> So I am a bit confused about when exactly it is needed. There will always
> be only one latest memtable for write operations and all old memtables are
> flushed so where this producer/consumer interaction on the same memtable is
> needed?
>
> Thanks,
> Preetika
>
>

Use of OpOrder in memtable

[Tyagi, Preetika]

Hi all,

I'm trying to understand the behavior of memtable when writes/flush operations 
are going on in parallel.

In my understanding, once a memtable is full it is queued for flushing and a 
new memtable is created for ongoing write operations.
However, I was looking at the code and it looks like the OpOrder class is used 
(don't understand all details) to ensure the synchronization between producers 
(writes) and consumers (batch flushes).
So I am a bit confused about when exactly it is needed. There will always be 
only one latest memtable for write operations and all old memtables are flushed 
so where this producer/consumer interaction on the same memtable is needed?

Thanks,
Preetika

Re: Coordinator Write Metrics per CF

[Benedict Elliott Smith]

Sorry, I guess I'm tired.  I thought this was discussing local write
latency.

I'm surprised we have that and not coordinator write latency.

Please do ignore me, I'm not sure why I got involved!

On 13 February 2018 at 21:48, Benedict Elliott Smith 
wrote:

> For the record, I'm not certain there *is* a great deal of value in this.
>
> The read latency metrics are expected to vary a great deal, since the
> entire IO subsystem is involved.
>
> Writes, however, go straight to a memtable.  They only block on IO if we
> exceed our commit log flush bandwidth for an extended period of time.  We
> already have a metric for tracking this: CommitLog.WaitingOnCommit.
>
> I'm not saying there won't be any latency distribution, but it is unlikely
> to be terribly interesting in very many situations.  I can't off the top of
> my head think of a good reason to consult this metric, that couldn't better
> be answered elsewhere.
>
>
>
> On 13 February 2018 at 19:18, Sumanth Pasupuleti  invalid> wrote:
>
>> Thanks Kurt and Chris for your valuable inputs. Created
>> https://issues.apache.org/jira/browse/CASSANDRA-14232; I shall start
>> working on this.
>>
>> Thanks,
>> Sumanth
>>
>> On Mon, Feb 12, 2018 at 7:43 AM, Chris Lohfink 
>> wrote:
>>
>> > It would be good to have it. Its not that its not there because its
>> > difficult or anything. I think its more that the read latency metric was
>> > needed for speculative retry so it was added but the write side wasn't
>> > needed for that feature so wasn't added at same time. It would be very
>> > useful in determining the table that the coordinator writes are slow to.
>> >
>> > Chris
>> >
>> > > On Feb 11, 2018, at 10:33 PM, kurt greaves 
>> wrote:
>> > >
>> > > I've tried to search around for a reason for this in the past and
>> haven't
>> > > found one. I don't think it's a bad idea. Would be a helpful metric to
>> > > diagnose internode networking issues - although I'll note that the
>> read
>> > > metric will also achieve this assuming you have enough reads to get
>> some
>> > > useful information out of it.
>> > >
>> > > On 9 February 2018 at 17:43, Sumanth Pasupuleti <
>> > > sumanth.pasupuleti...@gmail.com> wrote:
>> > >
>> > >> There is an existing CoordinatorReadLatency table metric. I am
>> looking
>> > to
>> > >> add CoordinatorWriteLatency table metric - however, before I attempt
>> a
>> > shot
>> > >> at it, would like to know if anyone has context around why we
>> currently
>> > do
>> > >> not have such metric (while we have the read metric) - if someone has
>> > >> already attempted and realized its a bad idea for some reason.
>> > >>
>> > >> Thanks,
>> > >> Sumanth
>> > >>
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> > For additional commands, e-mail: dev-h...@cassandra.apache.org
>> >
>> >
>>
>
>

Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

[Brandon Williams]

I change my vote to -1 binding here, too.

On Tue, Feb 13, 2018 at 3:45 PM, Jason Brown  wrote:

> -1, binding. Unit tests are broken:
> https://circleci.com/gh/jasobrown/cassandra/452#tests/containers/60
> 
>
> Dave ninja-committed 7df36056b12a13b60097b7a9a4f8155a1d02ff62 to update
> some logging messages, which broke ViewComplexTest. The errors like this:
>
> junit.framework.AssertionFailedError: Expected error message to contain
> 'Cannot drop column a on base table with materialized views', but got
> 'Cannot drop column a on base table table_21 with materialized views.'
>
> Dave has a followup commit, 40148a178bd9b74b731591aa46b4158efb16b742,
> which
> fixed a few of the errors, but there are four outstanding failures. I
> created CASSANDRA-14219 last week, and assigned it to Dave, but he might
> have missed the notification. Dinesh Joshi has a patch that I will review
> ASAP.
>
> There is also another test which is failing: testCountWithNoDeletedRow -
> org.apache.cassandra.db.ReadCommandTest
>
> junit.framework.AssertionFailedError: expected:<1> but was:<5>
>
> I have not investigated that error. It would be great if someone from the
> community can do so.
>
> Michael, is there a link of where you ran the tests? If so, can you include
> it in the future [VOTE] emails?
>
> Thanks,
>
> -Jason
>
>
> On Tue, Feb 13, 2018 at 10:53 AM, Josh McKenzie 
> wrote:
>
> > +1
> >
> > On Feb 13, 2018 9:36 AM, "Gary Dusbabek"  wrote:
> >
> > > +1
> > >
> > > On Mon, Feb 12, 2018 at 9:40 PM, Michael Shuler <
> mich...@pbandjelly.org>
> > > wrote:
> > >
> > > > I propose the following artifacts for release as 3.11.2.
> > > >
> > > > sha1: 8a5e88f635fdb984505a99a553b5799cedccd06d
> > > > Git:
> > > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > > shortlog;h=refs/tags/3.11.2-tentative
> > > > Artifacts:
> > > > https://repository.apache.org/content/repositories/
> > > > orgapachecassandra-1156/org/apache/cassandra/apache-
> cassandra/3.11.2/
> > > > Staging repository:
> > > > https://repository.apache.org/content/repositories/
> > > > orgapachecassandra-1156/
> > > >
> > > > Debian and RPM packages are available here:
> > > > http://people.apache.org/~mshuler
> > > >
> > > > *** This release addresses an important fix for CASSANDRA-14092 ***
> > > > "Max ttl of 20 years will overflow localDeletionTime"
> > > > https://issues.apache.org/jira/browse/CASSANDRA-14092
> > > >
> > > > The vote will be open for 72 hours (longer if needed).
> > > >
> > > > [1]: (CHANGES.txt) https://goo.gl/RLZLrR
> > > > [2]: (NEWS.txt) https://goo.gl/kpnVHp
> > > >
> > > >
> > >
> >
>

Re: Coordinator Write Metrics per CF

[Benedict Elliott Smith]

For the record, I'm not certain there *is* a great deal of value in this.

The read latency metrics are expected to vary a great deal, since the
entire IO subsystem is involved.

Writes, however, go straight to a memtable.  They only block on IO if we
exceed our commit log flush bandwidth for an extended period of time.  We
already have a metric for tracking this: CommitLog.WaitingOnCommit.

I'm not saying there won't be any latency distribution, but it is unlikely
to be terribly interesting in very many situations.  I can't off the top of
my head think of a good reason to consult this metric, that couldn't better
be answered elsewhere.



On 13 February 2018 at 19:18, Sumanth Pasupuleti <
spasupul...@netflix.com.invalid> wrote:

> Thanks Kurt and Chris for your valuable inputs. Created
> https://issues.apache.org/jira/browse/CASSANDRA-14232; I shall start
> working on this.
>
> Thanks,
> Sumanth
>
> On Mon, Feb 12, 2018 at 7:43 AM, Chris Lohfink  wrote:
>
> > It would be good to have it. Its not that its not there because its
> > difficult or anything. I think its more that the read latency metric was
> > needed for speculative retry so it was added but the write side wasn't
> > needed for that feature so wasn't added at same time. It would be very
> > useful in determining the table that the coordinator writes are slow to.
> >
> > Chris
> >
> > > On Feb 11, 2018, at 10:33 PM, kurt greaves 
> wrote:
> > >
> > > I've tried to search around for a reason for this in the past and
> haven't
> > > found one. I don't think it's a bad idea. Would be a helpful metric to
> > > diagnose internode networking issues - although I'll note that the read
> > > metric will also achieve this assuming you have enough reads to get
> some
> > > useful information out of it.
> > >
> > > On 9 February 2018 at 17:43, Sumanth Pasupuleti <
> > > sumanth.pasupuleti...@gmail.com> wrote:
> > >
> > >> There is an existing CoordinatorReadLatency table metric. I am looking
> > to
> > >> add CoordinatorWriteLatency table metric - however, before I attempt a
> > shot
> > >> at it, would like to know if anyone has context around why we
> currently
> > do
> > >> not have such metric (while we have the read metric) - if someone has
> > >> already attempted and realized its a bad idea for some reason.
> > >>
> > >> Thanks,
> > >> Sumanth
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [VOTE] Release Apache Cassandra 3.0.16

[Brandon Williams]

I change my vote to -1 binding as well.

On Tue, Feb 13, 2018 at 3:43 PM, Jason Brown  wrote:

> -1, binding. Unit tests are broken:
> https://circleci.com/gh/jasobrown/cassandra/451#tests/containers/50
>
> Dave ninja-committed 7df36056b12a13b60097b7a9a4f8155a1d02ff62 to update
> some logging messages, which broke ViewComplexTest. The errors like this:
>
> junit.framework.AssertionFailedError: Expected error message to contain
> 'Cannot drop column a on base table with materialized views', but got
> 'Cannot drop column a on base table table_21 with materialized views.'
>
> Dave has a followup commit, 40148a178bd9b74b731591aa46b4158efb16b742,
> which
> fixed a few of the errors, but there are four outstanding failures. I
> created CASSANDRA-14219 last week, and assigned it to Dave, but he might
> have missed the notification. Dinesh Joshi has a patch that I will review
> ASAP.
>
> Michael, is there a link of where you ran the tests? If so, can you include
> it in the future [VOTE] emails?
>
> Thanks,
>
> -Jason
>
>
>
> On Tue, Feb 13, 2018 at 11:03 AM, Jon Haddad  wrote:
>
> > +1
> >
> > > On Feb 13, 2018, at 10:52 AM, Josh McKenzie 
> > wrote:
> > >
> > > +1
> > >
> > > On Feb 13, 2018 9:20 AM, "Marcus Eriksson"  wrote:
> > >
> > >> +1
> > >>
> > >> On Tue, Feb 13, 2018 at 1:29 PM, Aleksey Yeshchenko <
> alek...@apple.com>
> > >> wrote:
> > >>
> > >>> +1
> > >>>
> > >>> —
> > >>> AY
> > >>>
> > >>> On 12 February 2018 at 20:31:23, Michael Shuler (
> > mich...@pbandjelly.org)
> > >>> wrote:
> > >>>
> > >>> I propose the following artifacts for release as 3.0.16.
> > >>>
> > >>> sha1: 91e83c72de109521074b14a8eeae1309c3b1f215
> > >>> Git:
> > >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > >>> shortlog;h=refs/tags/3.0.16-tentative
> > >>> Artifacts:
> > >>> https://repository.apache.org/content/repositories/
> > >>> orgapachecassandra-1154/org/apache/cassandra/apache-
> cassandra/3.0.16/
> > >>> Staging repository:
> > >>> https://repository.apache.org/content/repositories/
> > >>> orgapachecassandra-1154/
> > >>>
> > >>> Debian and RPM packages are available here:
> > >>> http://people.apache.org/~mshuler
> > >>>
> > >>> *** This release addresses an important fix for CASSANDRA-14092 ***
> > >>> "Max ttl of 20 years will overflow localDeletionTime"
> > >>> https://issues.apache.org/jira/browse/CASSANDRA-14092
> > >>>
> > >>> The vote will be open for 72 hours (longer if needed).
> > >>>
> > >>> [1]: (CHANGES.txt) https://goo.gl/rLj59Z
> > >>> [2]: (NEWS.txt) https://goo.gl/EkrT4G
> > >>>
> > >>>
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

[Jason Brown]

-1, binding. Unit tests are broken:
https://circleci.com/gh/jasobrown/cassandra/452#tests/containers/60


Dave ninja-committed 7df36056b12a13b60097b7a9a4f8155a1d02ff62 to update
some logging messages, which broke ViewComplexTest. The errors like this:

junit.framework.AssertionFailedError: Expected error message to contain
'Cannot drop column a on base table with materialized views', but got
'Cannot drop column a on base table table_21 with materialized views.'

Dave has a followup commit, 40148a178bd9b74b731591aa46b4158efb16b742, which
fixed a few of the errors, but there are four outstanding failures. I
created CASSANDRA-14219 last week, and assigned it to Dave, but he might
have missed the notification. Dinesh Joshi has a patch that I will review
ASAP.

There is also another test which is failing: testCountWithNoDeletedRow -
org.apache.cassandra.db.ReadCommandTest

junit.framework.AssertionFailedError: expected:<1> but was:<5>

I have not investigated that error. It would be great if someone from the
community can do so.

Michael, is there a link of where you ran the tests? If so, can you include
it in the future [VOTE] emails?

Thanks,

-Jason


On Tue, Feb 13, 2018 at 10:53 AM, Josh McKenzie 
wrote:

> +1
>
> On Feb 13, 2018 9:36 AM, "Gary Dusbabek"  wrote:
>
> > +1
> >
> > On Mon, Feb 12, 2018 at 9:40 PM, Michael Shuler 
> > wrote:
> >
> > > I propose the following artifacts for release as 3.11.2.
> > >
> > > sha1: 8a5e88f635fdb984505a99a553b5799cedccd06d
> > > Git:
> > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > shortlog;h=refs/tags/3.11.2-tentative
> > > Artifacts:
> > > https://repository.apache.org/content/repositories/
> > > orgapachecassandra-1156/org/apache/cassandra/apache-cassandra/3.11.2/
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/
> > > orgapachecassandra-1156/
> > >
> > > Debian and RPM packages are available here:
> > > http://people.apache.org/~mshuler
> > >
> > > *** This release addresses an important fix for CASSANDRA-14092 ***
> > > "Max ttl of 20 years will overflow localDeletionTime"
> > > https://issues.apache.org/jira/browse/CASSANDRA-14092
> > >
> > > The vote will be open for 72 hours (longer if needed).
> > >
> > > [1]: (CHANGES.txt) https://goo.gl/RLZLrR
> > > [2]: (NEWS.txt) https://goo.gl/kpnVHp
> > >
> > >
> >
>

Re: [VOTE] Release Apache Cassandra 3.0.16

[Jason Brown]

-1, binding. Unit tests are broken:
https://circleci.com/gh/jasobrown/cassandra/451#tests/containers/50

Dave ninja-committed 7df36056b12a13b60097b7a9a4f8155a1d02ff62 to update
some logging messages, which broke ViewComplexTest. The errors like this:

junit.framework.AssertionFailedError: Expected error message to contain
'Cannot drop column a on base table with materialized views', but got
'Cannot drop column a on base table table_21 with materialized views.'

Dave has a followup commit, 40148a178bd9b74b731591aa46b4158efb16b742, which
fixed a few of the errors, but there are four outstanding failures. I
created CASSANDRA-14219 last week, and assigned it to Dave, but he might
have missed the notification. Dinesh Joshi has a patch that I will review
ASAP.

Michael, is there a link of where you ran the tests? If so, can you include
it in the future [VOTE] emails?

Thanks,

-Jason



On Tue, Feb 13, 2018 at 11:03 AM, Jon Haddad  wrote:

> +1
>
> > On Feb 13, 2018, at 10:52 AM, Josh McKenzie 
> wrote:
> >
> > +1
> >
> > On Feb 13, 2018 9:20 AM, "Marcus Eriksson"  wrote:
> >
> >> +1
> >>
> >> On Tue, Feb 13, 2018 at 1:29 PM, Aleksey Yeshchenko 
> >> wrote:
> >>
> >>> +1
> >>>
> >>> —
> >>> AY
> >>>
> >>> On 12 February 2018 at 20:31:23, Michael Shuler (
> mich...@pbandjelly.org)
> >>> wrote:
> >>>
> >>> I propose the following artifacts for release as 3.0.16.
> >>>
> >>> sha1: 91e83c72de109521074b14a8eeae1309c3b1f215
> >>> Git:
> >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> >>> shortlog;h=refs/tags/3.0.16-tentative
> >>> Artifacts:
> >>> https://repository.apache.org/content/repositories/
> >>> orgapachecassandra-1154/org/apache/cassandra/apache-cassandra/3.0.16/
> >>> Staging repository:
> >>> https://repository.apache.org/content/repositories/
> >>> orgapachecassandra-1154/
> >>>
> >>> Debian and RPM packages are available here:
> >>> http://people.apache.org/~mshuler
> >>>
> >>> *** This release addresses an important fix for CASSANDRA-14092 ***
> >>> "Max ttl of 20 years will overflow localDeletionTime"
> >>> https://issues.apache.org/jira/browse/CASSANDRA-14092
> >>>
> >>> The vote will be open for 72 hours (longer if needed).
> >>>
> >>> [1]: (CHANGES.txt) https://goo.gl/rLj59Z
> >>> [2]: (NEWS.txt) https://goo.gl/EkrT4G
> >>>
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Coordinator Write Metrics per CF

[Sumanth Pasupuleti]

Thanks Kurt and Chris for your valuable inputs. Created
https://issues.apache.org/jira/browse/CASSANDRA-14232; I shall start
working on this.

Thanks,
Sumanth

On Mon, Feb 12, 2018 at 7:43 AM, Chris Lohfink  wrote:

> It would be good to have it. Its not that its not there because its
> difficult or anything. I think its more that the read latency metric was
> needed for speculative retry so it was added but the write side wasn't
> needed for that feature so wasn't added at same time. It would be very
> useful in determining the table that the coordinator writes are slow to.
>
> Chris
>
> > On Feb 11, 2018, at 10:33 PM, kurt greaves  wrote:
> >
> > I've tried to search around for a reason for this in the past and haven't
> > found one. I don't think it's a bad idea. Would be a helpful metric to
> > diagnose internode networking issues - although I'll note that the read
> > metric will also achieve this assuming you have enough reads to get some
> > useful information out of it.
> >
> > On 9 February 2018 at 17:43, Sumanth Pasupuleti <
> > sumanth.pasupuleti...@gmail.com> wrote:
> >
> >> There is an existing CoordinatorReadLatency table metric. I am looking
> to
> >> add CoordinatorWriteLatency table metric - however, before I attempt a
> shot
> >> at it, would like to know if anyone has context around why we currently
> do
> >> not have such metric (while we have the read metric) - if someone has
> >> already attempted and realized its a bad idea for some reason.
> >>
> >> Thanks,
> >> Sumanth
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 3.0.16

[Jon Haddad]

+1

> On Feb 13, 2018, at 10:52 AM, Josh McKenzie  wrote:
> 
> +1
> 
> On Feb 13, 2018 9:20 AM, "Marcus Eriksson"  wrote:
> 
>> +1
>> 
>> On Tue, Feb 13, 2018 at 1:29 PM, Aleksey Yeshchenko 
>> wrote:
>> 
>>> +1
>>> 
>>> —
>>> AY
>>> 
>>> On 12 February 2018 at 20:31:23, Michael Shuler (mich...@pbandjelly.org)
>>> wrote:
>>> 
>>> I propose the following artifacts for release as 3.0.16.
>>> 
>>> sha1: 91e83c72de109521074b14a8eeae1309c3b1f215
>>> Git:
>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>>> shortlog;h=refs/tags/3.0.16-tentative
>>> Artifacts:
>>> https://repository.apache.org/content/repositories/
>>> orgapachecassandra-1154/org/apache/cassandra/apache-cassandra/3.0.16/
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/
>>> orgapachecassandra-1154/
>>> 
>>> Debian and RPM packages are available here:
>>> http://people.apache.org/~mshuler
>>> 
>>> *** This release addresses an important fix for CASSANDRA-14092 ***
>>> "Max ttl of 20 years will overflow localDeletionTime"
>>> https://issues.apache.org/jira/browse/CASSANDRA-14092
>>> 
>>> The vote will be open for 72 hours (longer if needed).
>>> 
>>> [1]: (CHANGES.txt) https://goo.gl/rLj59Z
>>> [2]: (NEWS.txt) https://goo.gl/EkrT4G
>>> 
>>> 
>> 


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

Re: [VOTE] Release Apache Cassandra 2.1.20

[Josh McKenzie]

+1

On Feb 13, 2018 12:19 PM, "Jason Brown"  wrote:

> +1
>
> On Tue, Feb 13, 2018 at 7:20 AM, Marcus Eriksson 
> wrote:
>
> > +1
> >
> > On Tue, Feb 13, 2018 at 1:30 PM, Aleksey Yeshchenko 
> > wrote:
> >
> > > +1
> > >
> > > —
> > > AY
> > >
> > > On 12 February 2018 at 20:30:58, Michael Shuler (
> mich...@pbandjelly.org)
> > > wrote:
> > >
> > > I propose the following artifacts for release as 2.1.20.
> > >
> > > sha1: b2949439ec62077128103540e42570238520f4ee
> > > Git:
> > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > shortlog;h=refs/tags/2.1.20-tentative
> > > Artifacts:
> > > https://repository.apache.org/content/repositories/
> > > orgapachecassandra-1152/org/apache/cassandra/apache-cassandra/2.1.20/
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/
> > > orgapachecassandra-1152/
> > >
> > > Debian and RPM packages are available here:
> > > http://people.apache.org/~mshuler
> > >
> > > *** This release addresses an important fix for CASSANDRA-14092 ***
> > > "Max ttl of 20 years will overflow localDeletionTime"
> > > https://issues.apache.org/jira/browse/CASSANDRA-14092
> > >
> > > The vote will be open for 72 hours (longer if needed).
> > >
> > > [1]: (CHANGES.txt) https://goo.gl/5i2nw9
> > > [2]: (NEWS.txt) https://goo.gl/i9Fg2u
> > >
> > >
> >
>

Re: [VOTE] Release Apache Cassandra 2.2.12

[Josh McKenzie]

+1

On Feb 13, 2018 12:19 PM, "Jason Brown"  wrote:

> +1
>
> On Tue, Feb 13, 2018 at 7:55 AM, Jon Haddad  wrote:
>
> > +1
> >
> >
> > > On Feb 13, 2018, at 7:21 AM, Marcus Eriksson 
> wrote:
> > >
> > > +1
> > >
> > > On Tue, Feb 13, 2018 at 4:18 PM, Gary Dusbabek 
> > wrote:
> > >
> > >> +1
> > >>
> > >> On Mon, Feb 12, 2018 at 2:30 PM, Michael Shuler <
> mich...@pbandjelly.org
> > >
> > >> wrote:
> > >>
> > >>> I propose the following artifacts for release as 2.2.12.
> > >>>
> > >>> sha1: 1602e606348959aead18531cb8027afb15f276e7
> > >>> Git:
> > >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > >>> shortlog;h=refs/tags/2.2.12-tentative
> > >>> Artifacts:
> > >>> https://repository.apache.org/content/repositories/
> > >>> orgapachecassandra-1153/org/apache/cassandra/apache-
> cassandra/2.2.12/
> > >>> Staging repository:
> > >>> https://repository.apache.org/content/repositories/
> > >>> orgapachecassandra-1153/
> > >>>
> > >>> Debian and RPM packages are available here:
> > >>> http://people.apache.org/~mshuler
> > >>>
> > >>> *** This release addresses an important fix for CASSANDRA-14092 ***
> > >>>"Max ttl of 20 years will overflow localDeletionTime"
> > >>>https://issues.apache.org/jira/browse/CASSANDRA-14092
> > >>>
> > >>> The vote will be open for 72 hours (longer if needed).
> > >>>
> > >>> [1]: (CHANGES.txt) https://goo.gl/QkJeXH
> > >>> [2]: (NEWS.txt) https://goo.gl/A4iKFb
> > >>>
> > >>>
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

[Josh McKenzie]

+1

On Feb 13, 2018 9:36 AM, "Gary Dusbabek"  wrote:

> +1
>
> On Mon, Feb 12, 2018 at 9:40 PM, Michael Shuler 
> wrote:
>
> > I propose the following artifacts for release as 3.11.2.
> >
> > sha1: 8a5e88f635fdb984505a99a553b5799cedccd06d
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > shortlog;h=refs/tags/3.11.2-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1156/org/apache/cassandra/apache-cassandra/3.11.2/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1156/
> >
> > Debian and RPM packages are available here:
> > http://people.apache.org/~mshuler
> >
> > *** This release addresses an important fix for CASSANDRA-14092 ***
> > "Max ttl of 20 years will overflow localDeletionTime"
> > https://issues.apache.org/jira/browse/CASSANDRA-14092
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) https://goo.gl/RLZLrR
> > [2]: (NEWS.txt) https://goo.gl/kpnVHp
> >
> >
>

Re: [VOTE] Release Apache Cassandra 3.0.16

[Josh McKenzie]

+1

On Feb 13, 2018 9:20 AM, "Marcus Eriksson"  wrote:

> +1
>
> On Tue, Feb 13, 2018 at 1:29 PM, Aleksey Yeshchenko 
> wrote:
>
> > +1
> >
> > —
> > AY
> >
> > On 12 February 2018 at 20:31:23, Michael Shuler (mich...@pbandjelly.org)
> > wrote:
> >
> > I propose the following artifacts for release as 3.0.16.
> >
> > sha1: 91e83c72de109521074b14a8eeae1309c3b1f215
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > shortlog;h=refs/tags/3.0.16-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1154/org/apache/cassandra/apache-cassandra/3.0.16/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1154/
> >
> > Debian and RPM packages are available here:
> > http://people.apache.org/~mshuler
> >
> > *** This release addresses an important fix for CASSANDRA-14092 ***
> > "Max ttl of 20 years will overflow localDeletionTime"
> > https://issues.apache.org/jira/browse/CASSANDRA-14092
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) https://goo.gl/rLj59Z
> > [2]: (NEWS.txt) https://goo.gl/EkrT4G
> >
> >
>

Re: [VOTE] Release Apache Cassandra 2.2.12

[Jason Brown]

+1

On Tue, Feb 13, 2018 at 7:55 AM, Jon Haddad  wrote:

> +1
>
>
> > On Feb 13, 2018, at 7:21 AM, Marcus Eriksson  wrote:
> >
> > +1
> >
> > On Tue, Feb 13, 2018 at 4:18 PM, Gary Dusbabek 
> wrote:
> >
> >> +1
> >>
> >> On Mon, Feb 12, 2018 at 2:30 PM, Michael Shuler  >
> >> wrote:
> >>
> >>> I propose the following artifacts for release as 2.2.12.
> >>>
> >>> sha1: 1602e606348959aead18531cb8027afb15f276e7
> >>> Git:
> >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> >>> shortlog;h=refs/tags/2.2.12-tentative
> >>> Artifacts:
> >>> https://repository.apache.org/content/repositories/
> >>> orgapachecassandra-1153/org/apache/cassandra/apache-cassandra/2.2.12/
> >>> Staging repository:
> >>> https://repository.apache.org/content/repositories/
> >>> orgapachecassandra-1153/
> >>>
> >>> Debian and RPM packages are available here:
> >>> http://people.apache.org/~mshuler
> >>>
> >>> *** This release addresses an important fix for CASSANDRA-14092 ***
> >>>"Max ttl of 20 years will overflow localDeletionTime"
> >>>https://issues.apache.org/jira/browse/CASSANDRA-14092
> >>>
> >>> The vote will be open for 72 hours (longer if needed).
> >>>
> >>> [1]: (CHANGES.txt) https://goo.gl/QkJeXH
> >>> [2]: (NEWS.txt) https://goo.gl/A4iKFb
> >>>
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 2.1.20

[Jason Brown]

+1

On Tue, Feb 13, 2018 at 7:20 AM, Marcus Eriksson  wrote:

> +1
>
> On Tue, Feb 13, 2018 at 1:30 PM, Aleksey Yeshchenko 
> wrote:
>
> > +1
> >
> > —
> > AY
> >
> > On 12 February 2018 at 20:30:58, Michael Shuler (mich...@pbandjelly.org)
> > wrote:
> >
> > I propose the following artifacts for release as 2.1.20.
> >
> > sha1: b2949439ec62077128103540e42570238520f4ee
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > shortlog;h=refs/tags/2.1.20-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1152/org/apache/cassandra/apache-cassandra/2.1.20/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1152/
> >
> > Debian and RPM packages are available here:
> > http://people.apache.org/~mshuler
> >
> > *** This release addresses an important fix for CASSANDRA-14092 ***
> > "Max ttl of 20 years will overflow localDeletionTime"
> > https://issues.apache.org/jira/browse/CASSANDRA-14092
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) https://goo.gl/5i2nw9
> > [2]: (NEWS.txt) https://goo.gl/i9Fg2u
> >
> >
>

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

[Jeff Jirsa]

Using the internals in ThreadAwareSecurityManager has caused countless
problems, and needs to be fixed once and for all -

There are 2 different patches up for review in
https://issues.apache.org/jira/browse/CASSANDRA-13396 - would be nice if
one could be selected, and hopefully whichever is chosen can be a final
workaround for upgrading safely as well.




On Tue, Feb 13, 2018 at 9:41 AM, Jacques-Henri Berthemet <
jacques-henri.berthe...@genesys.com> wrote:

> Hi,
>
> I suppose upgrading Logback breaks Cassandra because some classes are used
> directly like in StorageService, ThreadAwareSecurityManager and
> StorageServiceMBean.
> This was a problem in my case as we're embedding Cassandra for our
> functional tests, I had to stub it as it was conflicting with log4j2
> configuration.
>
> Ideally Cassandra should only use pure SLF4J so that logging can be easily
> upgraded or changed.
> --
> Jacques-Henri Berthemet
>
> -Original Message-
> From: Ariel Weisberg [mailto:ar...@weisberg.ws]
> Sent: Tuesday, February 13, 2018 6:28 PM
> To: dev@cassandra.apache.org
> Subject: Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE
>
> Hi,
>
> So our options are:
>
> 1. Ignore it.
> Most people aren't using this functionality.
> Most people aren't and shouldn't be exposing the logging port to untrusted
> networks But everyone loses at defense in depth (or is it breadth) if they
> use this functionality and someone might expose the port
>
> 2. Remove the offending classes from the 1.1.10 jar My crazy idea, break
> it, but only for the people using the vulnerable functionality. Possibly no
> one, but probably someone. Maybe they can upgrade it manually for their
> usage?
> This also has an issue when working with maven.
>
> 3. Upgrade it
> Definitely going to break some apps according to Michael Shuler. Happened
> when he tried it.
>
> Certainly we can upgrade in trunk? While we are at it come up to the
> latest version.
>
> Ariel
>
> On Tue, Feb 13, 2018, at 12:03 PM, Ariel Weisberg wrote:
> > Hi,
> >
> > I don't think the fix is in 1.1.11 looking at the diff between 1.1.11
> > and 1.2.0
> > https://github.com/qos-ch/logback/compare/v_1.1.11...v_1.2.0
> > .com
> >
> > I looked at 1.1.11 and 1.1.10 and didn't see it there either.
> >
> > When you say stuff broke do you mean stuff not in the dtests or utests?
> >
> > Ariel
> >
> > On Tue, Feb 13, 2018, at 11:57 AM, Michael Shuler wrote:
> > > I tried a logback 1.2.x jar update a number of months ago to fix the
> > > broken log rotation (try setting rotation to a large number - you'll
> > > find you only get I think it was 10 files, regardless of setting).
> > >
> > > Like we've found updating other jars in the past, this seemingly
> > > "simple" update broke a number of application components, so we
> > > rolled it back and worked out another log rotation method.
> > >
> > > Looking at the logback changelog, I cannot tell if version 1.1.11 is
> > > fixed for this, or if that might be less breakage? There are a
> > > pretty significant number of API-looking changes from 1.1.3 to
> > > 1.2.3, so I do not wish to break other user's applications, as I have
> experienced.
> > >
> > > I do not think this should block the current releases, unless
> > > someone wants to do some significant testing and user outreach for
> > > tentatively breaking their applications.
> > >
> > > --
> > > Michael
> > >
> > > On 02/13/2018 10:48 AM, Jason Brown wrote:
> > > > Ariel,
> > > >
> > > > If this is a legit CVE, then we would want to patch all the
> > > > current versions we support - which is 2.1 and higher.
> > > >
> > > > Also, is this worth stopping the current open vote for this patch?
> > > > (Not in a place to look at the patch and affects to impacted
> branches right now).
> > > >
> > > > Jason
> > > >
> > > > On Tue, Feb 13, 2018 at 08:43 Ariel Weisberg 
> wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Seems like users could conceivably be using the vulnerable
> > > >> component. Also seems like like we need potentially need to do this
> as far back as 2.1?
> > > >>
> > > >> Anyone else have an opinion before I commit this? What version to
> > > >> start from?
> > > >>
> > > >> Ariel
> > > >>
> > > >> On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote:
> > > >>> Hi dev team,
> > > >>>
> > > >>> Sorry to keep bothering you.
> > > >>>
> > > >>> This is just a friendly reminder that I would like to contribute
> > > >>> to this project starting with a fix for CASSANDRA-14183
> > > >>> .
> > > >>>
> > > >>> []s,
> > > >>> Thiago.
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Tue, Jan 30, 2018 at 8:05 AM, Thiago Veronezi
> > > >>> 
> > > >>> wrote:
> > > >>>
> > >  Hi dev team,
> > > 
> > >  Can one of you guys take a look on this jira ticket?
> > >  https://issues.apache.org/jira/browse/CASSANDRA-14183
> > >  =issues.apache.org
> > > 
> > >  It has an a patch available for a known s

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

[Jason Brown]

Ariel,

>> Option 4, upgrade trunk, update NEWS.TXT in prior versions warning about
the vulnerability

+1 to this. I'll check the ticket, as well.

On Tue, Feb 13, 2018 at 9:45 AM, Ariel Weisberg  wrote:

> Hi,
>
> Option 4, upgrade trunk, update NEWS.TXT in prior versions warning about
> the vulnerability.
>
> Ariel
>
> On Tue, Feb 13, 2018, at 12:28 PM, Ariel Weisberg wrote:
> > Hi,
> >
> > So our options are:
> >
> > 1. Ignore it.
> > Most people aren't using this functionality.
> > Most people aren't and shouldn't be exposing the logging port to
> > untrusted networks
> > But everyone loses at defense in depth (or is it breadth) if they use
> > this functionality and someone might expose the port
> >
> > 2. Remove the offending classes from the 1.1.10 jar
> > My crazy idea, break it, but only for the people using the vulnerable
> > functionality. Possibly no one, but probably someone. Maybe they can
> > upgrade it manually for their usage?
> > This also has an issue when working with maven.
> >
> > 3. Upgrade it
> > Definitely going to break some apps according to Michael Shuler.
> > Happened when he tried it.
> >
> > Certainly we can upgrade in trunk? While we are at it come up to the
> > latest version.
> >
> > Ariel
> >
> > On Tue, Feb 13, 2018, at 12:03 PM, Ariel Weisberg wrote:
> > > Hi,
> > >
> > > I don't think the fix is in 1.1.11 looking at the diff between 1.1.11
> > > and 1.2.0 https://github.com/qos-ch/logback/compare/v_1.1.11...v_1.2.0
> > >
> > > I looked at 1.1.11 and 1.1.10 and didn't see it there either.
> > >
> > > When you say stuff broke do you mean stuff not in the dtests or utests?
> > >
> > > Ariel
> > >
> > > On Tue, Feb 13, 2018, at 11:57 AM, Michael Shuler wrote:
> > > > I tried a logback 1.2.x jar update a number of months ago to fix the
> > > > broken log rotation (try setting rotation to a large number - you'll
> > > > find you only get I think it was 10 files, regardless of setting).
> > > >
> > > > Like we've found updating other jars in the past, this seemingly
> > > > "simple" update broke a number of application components, so we
> rolled
> > > > it back and worked out another log rotation method.
> > > >
> > > > Looking at the logback changelog, I cannot tell if version 1.1.11 is
> > > > fixed for this, or if that might be less breakage? There are a pretty
> > > > significant number of API-looking changes from 1.1.3 to 1.2.3, so I
> do
> > > > not wish to break other user's applications, as I have experienced.
> > > >
> > > > I do not think this should block the current releases, unless someone
> > > > wants to do some significant testing and user outreach for
> tentatively
> > > > breaking their applications.
> > > >
> > > > --
> > > > Michael
> > > >
> > > > On 02/13/2018 10:48 AM, Jason Brown wrote:
> > > > > Ariel,
> > > > >
> > > > > If this is a legit CVE, then we would want to patch all the current
> > > > > versions we support - which is 2.1 and higher.
> > > > >
> > > > > Also, is this worth stopping the current open vote for this patch?
> (Not in
> > > > > a place to look at the patch and affects to impacted branches
> right now).
> > > > >
> > > > > Jason
> > > > >
> > > > > On Tue, Feb 13, 2018 at 08:43 Ariel Weisberg 
> wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> Seems like users could conceivably be using the vulnerable
> component. Also
> > > > >> seems like like we need potentially need to do this as far back
> as 2.1?
> > > > >>
> > > > >> Anyone else have an opinion before I commit this? What version to
> start
> > > > >> from?
> > > > >>
> > > > >> Ariel
> > > > >>
> > > > >> On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote:
> > > > >>> Hi dev team,
> > > > >>>
> > > > >>> Sorry to keep bothering you.
> > > > >>>
> > > > >>> This is just a friendly reminder that I would like to contribute
> to this
> > > > >>> project starting with a fix for CASSANDRA-14183
> > > > >>> .
> > > > >>>
> > > > >>> []s,
> > > > >>> Thiago.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On Tue, Jan 30, 2018 at 8:05 AM, Thiago Veronezi <
> thi...@veronezi.org>
> > > > >>> wrote:
> > > > >>>
> > > >  Hi dev team,
> > > > 
> > > >  Can one of you guys take a look on this jira ticket?
> > > >  https://issues.apache.org/jira/browse/CASSANDRA-14183
> > > > 
> > > >  It has an a patch available for a known security issue with one
> of the
> > > >  dependencies. It has only with trivial code changes. It should
> be
> > > >  straightforward to review it. Any feedback is very welcome.
> > > > 
> > > >  Thanks,
> > > >  Thiago
> > > > 
> > > > >>
> > > > >> 
> -
> > > > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > > > 

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

[Ariel Weisberg]

Hi,

Option 4, upgrade trunk, update NEWS.TXT in prior versions warning about the 
vulnerability.

Ariel

On Tue, Feb 13, 2018, at 12:28 PM, Ariel Weisberg wrote:
> Hi,
> 
> So our options are:
> 
> 1. Ignore it.
> Most people aren't using this functionality.
> Most people aren't and shouldn't be exposing the logging port to 
> untrusted networks
> But everyone loses at defense in depth (or is it breadth) if they use 
> this functionality and someone might expose the port
> 
> 2. Remove the offending classes from the 1.1.10 jar
> My crazy idea, break it, but only for the people using the vulnerable 
> functionality. Possibly no one, but probably someone. Maybe they can 
> upgrade it manually for their usage?
> This also has an issue when working with maven.
> 
> 3. Upgrade it
> Definitely going to break some apps according to Michael Shuler. 
> Happened when he tried it.
> 
> Certainly we can upgrade in trunk? While we are at it come up to the 
> latest version.
> 
> Ariel
> 
> On Tue, Feb 13, 2018, at 12:03 PM, Ariel Weisberg wrote:
> > Hi,
> > 
> > I don't think the fix is in 1.1.11 looking at the diff between 1.1.11 
> > and 1.2.0 https://github.com/qos-ch/logback/compare/v_1.1.11...v_1.2.0
> > 
> > I looked at 1.1.11 and 1.1.10 and didn't see it there either.
> > 
> > When you say stuff broke do you mean stuff not in the dtests or utests?
> > 
> > Ariel
> > 
> > On Tue, Feb 13, 2018, at 11:57 AM, Michael Shuler wrote:
> > > I tried a logback 1.2.x jar update a number of months ago to fix the
> > > broken log rotation (try setting rotation to a large number - you'll
> > > find you only get I think it was 10 files, regardless of setting).
> > > 
> > > Like we've found updating other jars in the past, this seemingly
> > > "simple" update broke a number of application components, so we rolled
> > > it back and worked out another log rotation method.
> > > 
> > > Looking at the logback changelog, I cannot tell if version 1.1.11 is
> > > fixed for this, or if that might be less breakage? There are a pretty
> > > significant number of API-looking changes from 1.1.3 to 1.2.3, so I do
> > > not wish to break other user's applications, as I have experienced.
> > > 
> > > I do not think this should block the current releases, unless someone
> > > wants to do some significant testing and user outreach for tentatively
> > > breaking their applications.
> > > 
> > > -- 
> > > Michael
> > > 
> > > On 02/13/2018 10:48 AM, Jason Brown wrote:
> > > > Ariel,
> > > > 
> > > > If this is a legit CVE, then we would want to patch all the current
> > > > versions we support - which is 2.1 and higher.
> > > > 
> > > > Also, is this worth stopping the current open vote for this patch? (Not 
> > > > in
> > > > a place to look at the patch and affects to impacted branches right 
> > > > now).
> > > > 
> > > > Jason
> > > > 
> > > > On Tue, Feb 13, 2018 at 08:43 Ariel Weisberg  wrote:
> > > > 
> > > >> Hi,
> > > >>
> > > >> Seems like users could conceivably be using the vulnerable component. 
> > > >> Also
> > > >> seems like like we need potentially need to do this as far back as 2.1?
> > > >>
> > > >> Anyone else have an opinion before I commit this? What version to start
> > > >> from?
> > > >>
> > > >> Ariel
> > > >>
> > > >> On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote:
> > > >>> Hi dev team,
> > > >>>
> > > >>> Sorry to keep bothering you.
> > > >>>
> > > >>> This is just a friendly reminder that I would like to contribute to 
> > > >>> this
> > > >>> project starting with a fix for CASSANDRA-14183
> > > >>> .
> > > >>>
> > > >>> []s,
> > > >>> Thiago.
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Tue, Jan 30, 2018 at 8:05 AM, Thiago Veronezi 
> > > >>> wrote:
> > > >>>
> > >  Hi dev team,
> > > 
> > >  Can one of you guys take a look on this jira ticket?
> > >  https://issues.apache.org/jira/browse/CASSANDRA-14183
> > > 
> > >  It has an a patch available for a known security issue with one of 
> > >  the
> > >  dependencies. It has only with trivial code changes. It should be
> > >  straightforward to review it. Any feedback is very welcome.
> > > 
> > >  Thanks,
> > >  Thiago
> > > 
> > > >>
> > > >> -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >>
> > > >>
> > > > 
> > > 
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > 
> 
> 

RE: CASSANDRA-14183 review request -> logback upgrade to fix CVE

[Jacques-Henri Berthemet]

Hi,

I suppose upgrading Logback breaks Cassandra because some classes are used 
directly like in StorageService, ThreadAwareSecurityManager and 
StorageServiceMBean.
This was a problem in my case as we're embedding Cassandra for our functional 
tests, I had to stub it as it was conflicting with log4j2 configuration.

Ideally Cassandra should only use pure SLF4J so that logging can be easily 
upgraded or changed. 
--
Jacques-Henri Berthemet

-Original Message-
From: Ariel Weisberg [mailto:ar...@weisberg.ws] 
Sent: Tuesday, February 13, 2018 6:28 PM
To: dev@cassandra.apache.org
Subject: Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

Hi,

So our options are:

1. Ignore it.
Most people aren't using this functionality.
Most people aren't and shouldn't be exposing the logging port to untrusted 
networks But everyone loses at defense in depth (or is it breadth) if they use 
this functionality and someone might expose the port

2. Remove the offending classes from the 1.1.10 jar My crazy idea, break it, 
but only for the people using the vulnerable functionality. Possibly no one, 
but probably someone. Maybe they can upgrade it manually for their usage?
This also has an issue when working with maven.

3. Upgrade it
Definitely going to break some apps according to Michael Shuler. Happened when 
he tried it.

Certainly we can upgrade in trunk? While we are at it come up to the latest 
version.

Ariel

On Tue, Feb 13, 2018, at 12:03 PM, Ariel Weisberg wrote:
> Hi,
> 
> I don't think the fix is in 1.1.11 looking at the diff between 1.1.11 
> and 1.2.0 
> https://github.com/qos-ch/logback/compare/v_1.1.11...v_1.2.0
> .com
> 
> I looked at 1.1.11 and 1.1.10 and didn't see it there either.
> 
> When you say stuff broke do you mean stuff not in the dtests or utests?
> 
> Ariel
> 
> On Tue, Feb 13, 2018, at 11:57 AM, Michael Shuler wrote:
> > I tried a logback 1.2.x jar update a number of months ago to fix the 
> > broken log rotation (try setting rotation to a large number - you'll 
> > find you only get I think it was 10 files, regardless of setting).
> > 
> > Like we've found updating other jars in the past, this seemingly 
> > "simple" update broke a number of application components, so we 
> > rolled it back and worked out another log rotation method.
> > 
> > Looking at the logback changelog, I cannot tell if version 1.1.11 is 
> > fixed for this, or if that might be less breakage? There are a 
> > pretty significant number of API-looking changes from 1.1.3 to 
> > 1.2.3, so I do not wish to break other user's applications, as I have 
> > experienced.
> > 
> > I do not think this should block the current releases, unless 
> > someone wants to do some significant testing and user outreach for 
> > tentatively breaking their applications.
> > 
> > --
> > Michael
> > 
> > On 02/13/2018 10:48 AM, Jason Brown wrote:
> > > Ariel,
> > > 
> > > If this is a legit CVE, then we would want to patch all the 
> > > current versions we support - which is 2.1 and higher.
> > > 
> > > Also, is this worth stopping the current open vote for this patch? 
> > > (Not in a place to look at the patch and affects to impacted branches 
> > > right now).
> > > 
> > > Jason
> > > 
> > > On Tue, Feb 13, 2018 at 08:43 Ariel Weisberg  wrote:
> > > 
> > >> Hi,
> > >>
> > >> Seems like users could conceivably be using the vulnerable 
> > >> component. Also seems like like we need potentially need to do this as 
> > >> far back as 2.1?
> > >>
> > >> Anyone else have an opinion before I commit this? What version to 
> > >> start from?
> > >>
> > >> Ariel
> > >>
> > >> On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote:
> > >>> Hi dev team,
> > >>>
> > >>> Sorry to keep bothering you.
> > >>>
> > >>> This is just a friendly reminder that I would like to contribute 
> > >>> to this project starting with a fix for CASSANDRA-14183 
> > >>> .
> > >>>
> > >>> []s,
> > >>> Thiago.
> > >>>
> > >>>
> > >>>
> > >>> On Tue, Jan 30, 2018 at 8:05 AM, Thiago Veronezi 
> > >>> 
> > >>> wrote:
> > >>>
> >  Hi dev team,
> > 
> >  Can one of you guys take a look on this jira ticket?
> >  https://issues.apache.org/jira/browse/CASSANDRA-14183
> >  =issues.apache.org
> > 
> >  It has an a patch available for a known security issue with one 
> >  of the dependencies. It has only with trivial code changes. It 
> >  should be straightforward to review it. Any feedback is very welcome.
> > 
> >  Thanks,
> >  Thiago
> > 
> > >>
> > >> -
> > >>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>
> > >>
> > > 
> > 
> > 
> > 
> > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

[Ariel Weisberg]

Hi,

So our options are:

1. Ignore it.
Most people aren't using this functionality.
Most people aren't and shouldn't be exposing the logging port to untrusted 
networks
But everyone loses at defense in depth (or is it breadth) if they use this 
functionality and someone might expose the port

2. Remove the offending classes from the 1.1.10 jar
My crazy idea, break it, but only for the people using the vulnerable 
functionality. Possibly no one, but probably someone. Maybe they can upgrade it 
manually for their usage?
This also has an issue when working with maven.

3. Upgrade it
Definitely going to break some apps according to Michael Shuler. Happened when 
he tried it.

Certainly we can upgrade in trunk? While we are at it come up to the latest 
version.

Ariel

On Tue, Feb 13, 2018, at 12:03 PM, Ariel Weisberg wrote:
> Hi,
> 
> I don't think the fix is in 1.1.11 looking at the diff between 1.1.11 
> and 1.2.0 https://github.com/qos-ch/logback/compare/v_1.1.11...v_1.2.0
> 
> I looked at 1.1.11 and 1.1.10 and didn't see it there either.
> 
> When you say stuff broke do you mean stuff not in the dtests or utests?
> 
> Ariel
> 
> On Tue, Feb 13, 2018, at 11:57 AM, Michael Shuler wrote:
> > I tried a logback 1.2.x jar update a number of months ago to fix the
> > broken log rotation (try setting rotation to a large number - you'll
> > find you only get I think it was 10 files, regardless of setting).
> > 
> > Like we've found updating other jars in the past, this seemingly
> > "simple" update broke a number of application components, so we rolled
> > it back and worked out another log rotation method.
> > 
> > Looking at the logback changelog, I cannot tell if version 1.1.11 is
> > fixed for this, or if that might be less breakage? There are a pretty
> > significant number of API-looking changes from 1.1.3 to 1.2.3, so I do
> > not wish to break other user's applications, as I have experienced.
> > 
> > I do not think this should block the current releases, unless someone
> > wants to do some significant testing and user outreach for tentatively
> > breaking their applications.
> > 
> > -- 
> > Michael
> > 
> > On 02/13/2018 10:48 AM, Jason Brown wrote:
> > > Ariel,
> > > 
> > > If this is a legit CVE, then we would want to patch all the current
> > > versions we support - which is 2.1 and higher.
> > > 
> > > Also, is this worth stopping the current open vote for this patch? (Not in
> > > a place to look at the patch and affects to impacted branches right now).
> > > 
> > > Jason
> > > 
> > > On Tue, Feb 13, 2018 at 08:43 Ariel Weisberg  wrote:
> > > 
> > >> Hi,
> > >>
> > >> Seems like users could conceivably be using the vulnerable component. 
> > >> Also
> > >> seems like like we need potentially need to do this as far back as 2.1?
> > >>
> > >> Anyone else have an opinion before I commit this? What version to start
> > >> from?
> > >>
> > >> Ariel
> > >>
> > >> On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote:
> > >>> Hi dev team,
> > >>>
> > >>> Sorry to keep bothering you.
> > >>>
> > >>> This is just a friendly reminder that I would like to contribute to this
> > >>> project starting with a fix for CASSANDRA-14183
> > >>> .
> > >>>
> > >>> []s,
> > >>> Thiago.
> > >>>
> > >>>
> > >>>
> > >>> On Tue, Jan 30, 2018 at 8:05 AM, Thiago Veronezi 
> > >>> wrote:
> > >>>
> >  Hi dev team,
> > 
> >  Can one of you guys take a look on this jira ticket?
> >  https://issues.apache.org/jira/browse/CASSANDRA-14183
> > 
> >  It has an a patch available for a known security issue with one of the
> >  dependencies. It has only with trivial code changes. It should be
> >  straightforward to review it. Any feedback is very welcome.
> > 
> >  Thanks,
> >  Thiago
> > 
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>
> > >>
> > > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

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

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

[Ariel Weisberg]

Hi,

I don't think the fix is in 1.1.11 looking at the diff between 1.1.11 and 1.2.0 
https://github.com/qos-ch/logback/compare/v_1.1.11...v_1.2.0

I looked at 1.1.11 and 1.1.10 and didn't see it there either.

When you say stuff broke do you mean stuff not in the dtests or utests?

Ariel

On Tue, Feb 13, 2018, at 11:57 AM, Michael Shuler wrote:
> I tried a logback 1.2.x jar update a number of months ago to fix the
> broken log rotation (try setting rotation to a large number - you'll
> find you only get I think it was 10 files, regardless of setting).
> 
> Like we've found updating other jars in the past, this seemingly
> "simple" update broke a number of application components, so we rolled
> it back and worked out another log rotation method.
> 
> Looking at the logback changelog, I cannot tell if version 1.1.11 is
> fixed for this, or if that might be less breakage? There are a pretty
> significant number of API-looking changes from 1.1.3 to 1.2.3, so I do
> not wish to break other user's applications, as I have experienced.
> 
> I do not think this should block the current releases, unless someone
> wants to do some significant testing and user outreach for tentatively
> breaking their applications.
> 
> -- 
> Michael
> 
> On 02/13/2018 10:48 AM, Jason Brown wrote:
> > Ariel,
> > 
> > If this is a legit CVE, then we would want to patch all the current
> > versions we support - which is 2.1 and higher.
> > 
> > Also, is this worth stopping the current open vote for this patch? (Not in
> > a place to look at the patch and affects to impacted branches right now).
> > 
> > Jason
> > 
> > On Tue, Feb 13, 2018 at 08:43 Ariel Weisberg  wrote:
> > 
> >> Hi,
> >>
> >> Seems like users could conceivably be using the vulnerable component. Also
> >> seems like like we need potentially need to do this as far back as 2.1?
> >>
> >> Anyone else have an opinion before I commit this? What version to start
> >> from?
> >>
> >> Ariel
> >>
> >> On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote:
> >>> Hi dev team,
> >>>
> >>> Sorry to keep bothering you.
> >>>
> >>> This is just a friendly reminder that I would like to contribute to this
> >>> project starting with a fix for CASSANDRA-14183
> >>> .
> >>>
> >>> []s,
> >>> Thiago.
> >>>
> >>>
> >>>
> >>> On Tue, Jan 30, 2018 at 8:05 AM, Thiago Veronezi 
> >>> wrote:
> >>>
>  Hi dev team,
> 
>  Can one of you guys take a look on this jira ticket?
>  https://issues.apache.org/jira/browse/CASSANDRA-14183
> 
>  It has an a patch available for a known security issue with one of the
>  dependencies. It has only with trivial code changes. It should be
>  straightforward to review it. Any feedback is very welcome.
> 
>  Thanks,
>  Thiago
> 
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
> > 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

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

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

[Jason Brown]

Thanks, Michael and Jeremiah. That’s good input.

Ok, let’s not hold up the vote.

On Tue, Feb 13, 2018 at 08:58 Jeremiah D Jordan 
wrote:

> s/does affect/does not affect/
>
> > On Feb 13, 2018, at 11:57 AM, Jeremiah D Jordan <
> jeremiah.jor...@gmail.com> wrote:
> >
> > I don’t think we need to stop the vote.  This CVE has been around for a
> while (3/13/2017), and does affect any install I have ever seen.  It
> affects users who manually enable some specific logback features using the
> SocketServer or ServerSocketReceiver component which are not used in our
> default settings (or by any install I have ever seen).
> >
> > -Jeremiah
> >
> >> On Feb 13, 2018, at 11:48 AM, Jason Brown  wrote:
> >>
> >> Ariel,
> >>
> >> If this is a legit CVE, then we would want to patch all the current
> >> versions we support - which is 2.1 and higher.
> >>
> >> Also, is this worth stopping the current open vote for this patch? (Not
> in
> >> a place to look at the patch and affects to impacted branches right
> now).
> >>
> >> Jason
> >>
> >> On Tue, Feb 13, 2018 at 08:43 Ariel Weisberg  wrote:
> >>
> >>> Hi,
> >>>
> >>> Seems like users could conceivably be using the vulnerable component.
> Also
> >>> seems like like we need potentially need to do this as far back as 2.1?
> >>>
> >>> Anyone else have an opinion before I commit this? What version to start
> >>> from?
> >>>
> >>> Ariel
> >>>
> >>> On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote:
>  Hi dev team,
> 
>  Sorry to keep bothering you.
> 
>  This is just a friendly reminder that I would like to contribute to
> this
>  project starting with a fix for CASSANDRA-14183
>  .
> 
>  []s,
>  Thiago.
> 
> 
> 
>  On Tue, Jan 30, 2018 at 8:05 AM, Thiago Veronezi  >
>  wrote:
> 
> > Hi dev team,
> >
> > Can one of you guys take a look on this jira ticket?
> > https://issues.apache.org/jira/browse/CASSANDRA-14183
> >
> > It has an a patch available for a known security issue with one of
> the
> > dependencies. It has only with trivial code changes. It should be
> > straightforward to review it. Any feedback is very welcome.
> >
> > Thanks,
> > Thiago
> >
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>
> >>>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

[Jeremiah D Jordan]

s/does affect/does not affect/

> On Feb 13, 2018, at 11:57 AM, Jeremiah D Jordan  
> wrote:
> 
> I don’t think we need to stop the vote.  This CVE has been around for a while 
> (3/13/2017), and does affect any install I have ever seen.  It affects users 
> who manually enable some specific logback features using the SocketServer or 
> ServerSocketReceiver component which are not used in our default settings (or 
> by any install I have ever seen).
> 
> -Jeremiah
> 
>> On Feb 13, 2018, at 11:48 AM, Jason Brown  wrote:
>> 
>> Ariel,
>> 
>> If this is a legit CVE, then we would want to patch all the current
>> versions we support - which is 2.1 and higher.
>> 
>> Also, is this worth stopping the current open vote for this patch? (Not in
>> a place to look at the patch and affects to impacted branches right now).
>> 
>> Jason
>> 
>> On Tue, Feb 13, 2018 at 08:43 Ariel Weisberg  wrote:
>> 
>>> Hi,
>>> 
>>> Seems like users could conceivably be using the vulnerable component. Also
>>> seems like like we need potentially need to do this as far back as 2.1?
>>> 
>>> Anyone else have an opinion before I commit this? What version to start
>>> from?
>>> 
>>> Ariel
>>> 
>>> On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote:
 Hi dev team,
 
 Sorry to keep bothering you.
 
 This is just a friendly reminder that I would like to contribute to this
 project starting with a fix for CASSANDRA-14183
 .
 
 []s,
 Thiago.
 
 
 
 On Tue, Jan 30, 2018 at 8:05 AM, Thiago Veronezi 
 wrote:
 
> Hi dev team,
> 
> Can one of you guys take a look on this jira ticket?
> https://issues.apache.org/jira/browse/CASSANDRA-14183
> 
> It has an a patch available for a known security issue with one of the
> dependencies. It has only with trivial code changes. It should be
> straightforward to review it. Any feedback is very welcome.
> 
> Thanks,
> Thiago
> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 


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

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

[Jeremiah D Jordan]

I don’t think we need to stop the vote.  This CVE has been around for a while 
(3/13/2017), and does affect any install I have ever seen.  It affects users 
who manually enable some specific logback features using the SocketServer or 
ServerSocketReceiver component which are not used in our default settings (or 
by any install I have ever seen).

-Jeremiah

> On Feb 13, 2018, at 11:48 AM, Jason Brown  wrote:
> 
> Ariel,
> 
> If this is a legit CVE, then we would want to patch all the current
> versions we support - which is 2.1 and higher.
> 
> Also, is this worth stopping the current open vote for this patch? (Not in
> a place to look at the patch and affects to impacted branches right now).
> 
> Jason
> 
> On Tue, Feb 13, 2018 at 08:43 Ariel Weisberg  wrote:
> 
>> Hi,
>> 
>> Seems like users could conceivably be using the vulnerable component. Also
>> seems like like we need potentially need to do this as far back as 2.1?
>> 
>> Anyone else have an opinion before I commit this? What version to start
>> from?
>> 
>> Ariel
>> 
>> On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote:
>>> Hi dev team,
>>> 
>>> Sorry to keep bothering you.
>>> 
>>> This is just a friendly reminder that I would like to contribute to this
>>> project starting with a fix for CASSANDRA-14183
>>> .
>>> 
>>> []s,
>>> Thiago.
>>> 
>>> 
>>> 
>>> On Tue, Jan 30, 2018 at 8:05 AM, Thiago Veronezi 
>>> wrote:
>>> 
 Hi dev team,
 
 Can one of you guys take a look on this jira ticket?
 https://issues.apache.org/jira/browse/CASSANDRA-14183
 
 It has an a patch available for a known security issue with one of the
 dependencies. It has only with trivial code changes. It should be
 straightforward to review it. Any feedback is very welcome.
 
 Thanks,
 Thiago
 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 


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

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

[Michael Shuler]

I tried a logback 1.2.x jar update a number of months ago to fix the
broken log rotation (try setting rotation to a large number - you'll
find you only get I think it was 10 files, regardless of setting).

Like we've found updating other jars in the past, this seemingly
"simple" update broke a number of application components, so we rolled
it back and worked out another log rotation method.

Looking at the logback changelog, I cannot tell if version 1.1.11 is
fixed for this, or if that might be less breakage? There are a pretty
significant number of API-looking changes from 1.1.3 to 1.2.3, so I do
not wish to break other user's applications, as I have experienced.

I do not think this should block the current releases, unless someone
wants to do some significant testing and user outreach for tentatively
breaking their applications.

-- 
Michael

On 02/13/2018 10:48 AM, Jason Brown wrote:
> Ariel,
> 
> If this is a legit CVE, then we would want to patch all the current
> versions we support - which is 2.1 and higher.
> 
> Also, is this worth stopping the current open vote for this patch? (Not in
> a place to look at the patch and affects to impacted branches right now).
> 
> Jason
> 
> On Tue, Feb 13, 2018 at 08:43 Ariel Weisberg  wrote:
> 
>> Hi,
>>
>> Seems like users could conceivably be using the vulnerable component. Also
>> seems like like we need potentially need to do this as far back as 2.1?
>>
>> Anyone else have an opinion before I commit this? What version to start
>> from?
>>
>> Ariel
>>
>> On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote:
>>> Hi dev team,
>>>
>>> Sorry to keep bothering you.
>>>
>>> This is just a friendly reminder that I would like to contribute to this
>>> project starting with a fix for CASSANDRA-14183
>>> .
>>>
>>> []s,
>>> Thiago.
>>>
>>>
>>>
>>> On Tue, Jan 30, 2018 at 8:05 AM, Thiago Veronezi 
>>> wrote:
>>>
 Hi dev team,

 Can one of you guys take a look on this jira ticket?
 https://issues.apache.org/jira/browse/CASSANDRA-14183

 It has an a patch available for a known security issue with one of the
 dependencies. It has only with trivial code changes. It should be
 straightforward to review it. Any feedback is very welcome.

 Thanks,
 Thiago

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


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

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

[Jason Brown]

Ariel,

If this is a legit CVE, then we would want to patch all the current
versions we support - which is 2.1 and higher.

Also, is this worth stopping the current open vote for this patch? (Not in
a place to look at the patch and affects to impacted branches right now).

Jason

On Tue, Feb 13, 2018 at 08:43 Ariel Weisberg  wrote:

> Hi,
>
> Seems like users could conceivably be using the vulnerable component. Also
> seems like like we need potentially need to do this as far back as 2.1?
>
> Anyone else have an opinion before I commit this? What version to start
> from?
>
> Ariel
>
> On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote:
> > Hi dev team,
> >
> > Sorry to keep bothering you.
> >
> > This is just a friendly reminder that I would like to contribute to this
> > project starting with a fix for CASSANDRA-14183
> > .
> >
> > []s,
> > Thiago.
> >
> >
> >
> > On Tue, Jan 30, 2018 at 8:05 AM, Thiago Veronezi 
> > wrote:
> >
> > > Hi dev team,
> > >
> > > Can one of you guys take a look on this jira ticket?
> > > https://issues.apache.org/jira/browse/CASSANDRA-14183
> > >
> > > It has an a patch available for a known security issue with one of the
> > > dependencies. It has only with trivial code changes. It should be
> > > straightforward to review it. Any feedback is very welcome.
> > >
> > > Thanks,
> > > Thiago
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

[Ariel Weisberg]

Hi,

Seems like users could conceivably be using the vulnerable component. Also 
seems like like we need potentially need to do this as far back as 2.1?

Anyone else have an opinion before I commit this? What version to start from?

Ariel

On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote:
> Hi dev team,
> 
> Sorry to keep bothering you.
> 
> This is just a friendly reminder that I would like to contribute to this
> project starting with a fix for CASSANDRA-14183
> .
> 
> []s,
> Thiago.
> 
> 
> 
> On Tue, Jan 30, 2018 at 8:05 AM, Thiago Veronezi 
> wrote:
> 
> > Hi dev team,
> >
> > Can one of you guys take a look on this jira ticket?
> > https://issues.apache.org/jira/browse/CASSANDRA-14183
> >
> > It has an a patch available for a known security issue with one of the
> > dependencies. It has only with trivial code changes. It should be
> > straightforward to review it. Any feedback is very welcome.
> >
> > Thanks,
> > Thiago
> >

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

Re: [VOTE] Release Apache Cassandra 2.2.12

[Jon Haddad]

+1


> On Feb 13, 2018, at 7:21 AM, Marcus Eriksson  wrote:
> 
> +1
> 
> On Tue, Feb 13, 2018 at 4:18 PM, Gary Dusbabek  wrote:
> 
>> +1
>> 
>> On Mon, Feb 12, 2018 at 2:30 PM, Michael Shuler 
>> wrote:
>> 
>>> I propose the following artifacts for release as 2.2.12.
>>> 
>>> sha1: 1602e606348959aead18531cb8027afb15f276e7
>>> Git:
>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>>> shortlog;h=refs/tags/2.2.12-tentative
>>> Artifacts:
>>> https://repository.apache.org/content/repositories/
>>> orgapachecassandra-1153/org/apache/cassandra/apache-cassandra/2.2.12/
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/
>>> orgapachecassandra-1153/
>>> 
>>> Debian and RPM packages are available here:
>>> http://people.apache.org/~mshuler
>>> 
>>> *** This release addresses an important fix for CASSANDRA-14092 ***
>>>"Max ttl of 20 years will overflow localDeletionTime"
>>>https://issues.apache.org/jira/browse/CASSANDRA-14092
>>> 
>>> The vote will be open for 72 hours (longer if needed).
>>> 
>>> [1]: (CHANGES.txt) https://goo.gl/QkJeXH
>>> [2]: (NEWS.txt) https://goo.gl/A4iKFb
>>> 
>>> 
>> 


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

Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

[Gary Dusbabek]

+1

On Mon, Feb 12, 2018 at 9:40 PM, Michael Shuler 
wrote:

> I propose the following artifacts for release as 3.11.2.
>
> sha1: 8a5e88f635fdb984505a99a553b5799cedccd06d
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.11.2-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1156/org/apache/cassandra/apache-cassandra/3.11.2/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1156/
>
> Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> *** This release addresses an important fix for CASSANDRA-14092 ***
> "Max ttl of 20 years will overflow localDeletionTime"
> https://issues.apache.org/jira/browse/CASSANDRA-14092
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/RLZLrR
> [2]: (NEWS.txt) https://goo.gl/kpnVHp
>
>

Re: [VOTE] Release Apache Cassandra 2.2.12

[Marcus Eriksson]

+1

On Tue, Feb 13, 2018 at 4:18 PM, Gary Dusbabek  wrote:

> +1
>
> On Mon, Feb 12, 2018 at 2:30 PM, Michael Shuler 
> wrote:
>
> > I propose the following artifacts for release as 2.2.12.
> >
> > sha1: 1602e606348959aead18531cb8027afb15f276e7
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > shortlog;h=refs/tags/2.2.12-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1153/org/apache/cassandra/apache-cassandra/2.2.12/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1153/
> >
> > Debian and RPM packages are available here:
> > http://people.apache.org/~mshuler
> >
> > *** This release addresses an important fix for CASSANDRA-14092 ***
> > "Max ttl of 20 years will overflow localDeletionTime"
> > https://issues.apache.org/jira/browse/CASSANDRA-14092
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) https://goo.gl/QkJeXH
> > [2]: (NEWS.txt) https://goo.gl/A4iKFb
> >
> >
>

Re: [VOTE] Release Apache Cassandra 2.1.20

[Marcus Eriksson]

+1

On Tue, Feb 13, 2018 at 1:30 PM, Aleksey Yeshchenko 
wrote:

> +1
>
> —
> AY
>
> On 12 February 2018 at 20:30:58, Michael Shuler (mich...@pbandjelly.org)
> wrote:
>
> I propose the following artifacts for release as 2.1.20.
>
> sha1: b2949439ec62077128103540e42570238520f4ee
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/2.1.20-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1152/org/apache/cassandra/apache-cassandra/2.1.20/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1152/
>
> Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> *** This release addresses an important fix for CASSANDRA-14092 ***
> "Max ttl of 20 years will overflow localDeletionTime"
> https://issues.apache.org/jira/browse/CASSANDRA-14092
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/5i2nw9
> [2]: (NEWS.txt) https://goo.gl/i9Fg2u
>
>

Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

[Marcus Eriksson]

+1

On Tue, Feb 13, 2018 at 1:32 PM, Aleksey Yeshchenko 
wrote:

> +1
>
> —
> AY
>
> On 13 February 2018 at 03:41:09, Michael Shuler (mich...@pbandjelly.org)
> wrote:
>
> I propose the following artifacts for release as 3.11.2.
>
> sha1: 8a5e88f635fdb984505a99a553b5799cedccd06d
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.11.2-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1156/org/apache/cassandra/apache-cassandra/3.11.2/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1156/
>
> Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> *** This release addresses an important fix for CASSANDRA-14092 ***
> "Max ttl of 20 years will overflow localDeletionTime"
> https://issues.apache.org/jira/browse/CASSANDRA-14092
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/RLZLrR
> [2]: (NEWS.txt) https://goo.gl/kpnVHp
>
>

Re: [VOTE] Release Apache Cassandra 3.0.16

[Marcus Eriksson]

+1

On Tue, Feb 13, 2018 at 1:29 PM, Aleksey Yeshchenko 
wrote:

> +1
>
> —
> AY
>
> On 12 February 2018 at 20:31:23, Michael Shuler (mich...@pbandjelly.org)
> wrote:
>
> I propose the following artifacts for release as 3.0.16.
>
> sha1: 91e83c72de109521074b14a8eeae1309c3b1f215
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.0.16-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1154/org/apache/cassandra/apache-cassandra/3.0.16/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1154/
>
> Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> *** This release addresses an important fix for CASSANDRA-14092 ***
> "Max ttl of 20 years will overflow localDeletionTime"
> https://issues.apache.org/jira/browse/CASSANDRA-14092
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/rLj59Z
> [2]: (NEWS.txt) https://goo.gl/EkrT4G
>
>

Re: [VOTE] Release Apache Cassandra 2.2.12

[Gary Dusbabek]

+1

On Mon, Feb 12, 2018 at 2:30 PM, Michael Shuler 
wrote:

> I propose the following artifacts for release as 2.2.12.
>
> sha1: 1602e606348959aead18531cb8027afb15f276e7
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/2.2.12-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1153/org/apache/cassandra/apache-cassandra/2.2.12/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1153/
>
> Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> *** This release addresses an important fix for CASSANDRA-14092 ***
> "Max ttl of 20 years will overflow localDeletionTime"
> https://issues.apache.org/jira/browse/CASSANDRA-14092
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/QkJeXH
> [2]: (NEWS.txt) https://goo.gl/A4iKFb
>
>

Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

[Aleksey Yeshchenko]

+1

—
AY

On 13 February 2018 at 03:41:09, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 3.11.2.  

sha1: 8a5e88f635fdb984505a99a553b5799cedccd06d  
Git:  
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.2-tentative
  
Artifacts:  
https://repository.apache.org/content/repositories/orgapachecassandra-1156/org/apache/cassandra/apache-cassandra/3.11.2/
  
Staging repository:  
https://repository.apache.org/content/repositories/orgapachecassandra-1156/  

Debian and RPM packages are available here:  
http://people.apache.org/~mshuler  

*** This release addresses an important fix for CASSANDRA-14092 ***  
"Max ttl of 20 years will overflow localDeletionTime"  
https://issues.apache.org/jira/browse/CASSANDRA-14092  

The vote will be open for 72 hours (longer if needed).  

[1]: (CHANGES.txt) https://goo.gl/RLZLrR  
[2]: (NEWS.txt) https://goo.gl/kpnVHp  

Re: [VOTE] Release Apache Cassandra 2.1.20

[Aleksey Yeshchenko]

+1

—
AY

On 12 February 2018 at 20:30:58, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 2.1.20.  

sha1: b2949439ec62077128103540e42570238520f4ee  
Git:  
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.20-tentative
  
Artifacts:  
https://repository.apache.org/content/repositories/orgapachecassandra-1152/org/apache/cassandra/apache-cassandra/2.1.20/
  
Staging repository:  
https://repository.apache.org/content/repositories/orgapachecassandra-1152/  

Debian and RPM packages are available here:  
http://people.apache.org/~mshuler  

*** This release addresses an important fix for CASSANDRA-14092 ***  
"Max ttl of 20 years will overflow localDeletionTime"  
https://issues.apache.org/jira/browse/CASSANDRA-14092  

The vote will be open for 72 hours (longer if needed).  

[1]: (CHANGES.txt) https://goo.gl/5i2nw9  
[2]: (NEWS.txt) https://goo.gl/i9Fg2u  

Re: [VOTE] Release Apache Cassandra 3.0.16

[Aleksey Yeshchenko]

+1

—
AY

On 12 February 2018 at 20:31:23, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 3.0.16.  

sha1: 91e83c72de109521074b14a8eeae1309c3b1f215  
Git:  
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.16-tentative
  
Artifacts:  
https://repository.apache.org/content/repositories/orgapachecassandra-1154/org/apache/cassandra/apache-cassandra/3.0.16/
  
Staging repository:  
https://repository.apache.org/content/repositories/orgapachecassandra-1154/  

Debian and RPM packages are available here:  
http://people.apache.org/~mshuler  

*** This release addresses an important fix for CASSANDRA-14092 ***  
"Max ttl of 20 years will overflow localDeletionTime"  
https://issues.apache.org/jira/browse/CASSANDRA-14092  

The vote will be open for 72 hours (longer if needed).  

[1]: (CHANGES.txt) https://goo.gl/rLj59Z  
[2]: (NEWS.txt) https://goo.gl/EkrT4G  

Re: [VOTE] Release Apache Cassandra 2.2.12

[Aleksey Yeshchenko]

+1

—
AY

On 12 February 2018 at 20:31:06, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 2.2.12.  

sha1: 1602e606348959aead18531cb8027afb15f276e7  
Git:  
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.12-tentative
  
Artifacts:  
https://repository.apache.org/content/repositories/orgapachecassandra-1153/org/apache/cassandra/apache-cassandra/2.2.12/
  
Staging repository:  
https://repository.apache.org/content/repositories/orgapachecassandra-1153/  

Debian and RPM packages are available here:  
http://people.apache.org/~mshuler  

*** This release addresses an important fix for CASSANDRA-14092 ***  
"Max ttl of 20 years will overflow localDeletionTime"  
https://issues.apache.org/jira/browse/CASSANDRA-14092  

The vote will be open for 72 hours (longer if needed).  

[1]: (CHANGES.txt) https://goo.gl/QkJeXH  
[2]: (NEWS.txt) https://goo.gl/A4iKFb  

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

[Thiago Veronezi]

Hi dev team,

Sorry to keep bothering you.

This is just a friendly reminder that I would like to contribute to this
project starting with a fix for CASSANDRA-14183
.

[]s,
Thiago.



On Tue, Jan 30, 2018 at 8:05 AM, Thiago Veronezi 
wrote:

> Hi dev team,
>
> Can one of you guys take a look on this jira ticket?
> https://issues.apache.org/jira/browse/CASSANDRA-14183
>
> It has an a patch available for a known security issue with one of the
> dependencies. It has only with trivial code changes. It should be
> straightforward to review it. Any feedback is very welcome.
>
> Thanks,
> Thiago
>