Re: March 2015 QA retrospective

[Jonathan Ellis]

Could you sort the ticket list by assignee so people just have to look for
their name once?

On Thu, Apr 9, 2015 at 12:43 PM, Ariel Weisberg  wrote:

> Hi,
>
> Thanks Philip.
>
> For items in went poorly, is there anything we could change or should have
> done differently to get contributor branches running in CI? I don’t recall
> us setting a fixed goal for when that had to be done.
>
> There are two angles to evaluate this from and decide if there is a
> problem. We had a schedule goal and we didn’t make it. Or we didn’t have a
> schedule goal, but we committed resources and didn’t make progress.
>
> If it's just not done and we are OK with that it wouldn't go under went
> poorly (it's just how it went).
>
> *Retrospecting the retrospective*
>
> The retrospective didn’t play out the way I hoped and I think it may be
> because I didn’t communicate how we are supposed to use it in enough
> detail. For everyone to have nothing to add in the went poorly column means
> that in the period of time covered by the retrospective we shipped no bug
> fixes for bugs that we think we should have been caught before release.
>
> We know that isn’t true because in JIRA for 2.1.3 there were 114 resolved
> bugs. Some of those are going to be things that were addressed before being
> released, but a good chunk have to be fixes for issues in previous
> releases. The reason we need to do this through a retrospective is that
> it’s a lot of work for me and I lack perspective on what is going on with
> each individual issue. Having a PHB chase everyone down and find out what
> they are doing is inefficient and doesn’t work because it’s lacks
> repeatability/scalability and it builds experienced for me, but not for the
> team.
>
> *Evaluating 2.13 issues:*
> Right now we have what you might call a target rich environment. Many
> features aren’t exercised in a realistic way or evaluated by success
> criteria (performance, space utilization) that users care about. The first
> few retrospectives should be the noisiest as we work through that backlog.
>
> We may be creating regression tests as part of the bug fixes we shipped (I
> sure hope we did), but regression tests are != to the kind of tests we
> could have written to avoid shipping the bug in the first place. Tests
> which have the potential to catch more than just the individual bug in
> question.
>
> I’m going to drag into the went poorly category fixes from 2.1.3 and I
> would like to have the involved parties (fundamentally this is the
> responsibility of the assignee) chime in on why the bug was released in the
> first place and what we could kind of test we could have done before
> release to catch it. I removed a number of issues that were enhancements,
> bugs fixed before release due to successful process, or wontfixed/not
> reproducable.
>
> Reasons for revisiting are typically a missing regression test, missing
> test that we could run now to detect this class of problem in the future,
> and most importantly (and also hardest to nail down), what could we do in
> the future when doing that kind of work to build effective tests before
> release.
>
> One of things I pick on for some of these is inadequate testing of boundary
> conditions, inadequate testing with interrelated components (always hard to
> identify and can change over time). Not testing under sufficient load or
> with a representative data model or data set is also an issue for some of
> these.
>
> *Homework:*
> If you are listed as an assignee you need to triage the ticket. Based on
> the experience with that bug are we doing sufficient testing now, and what
> kind of testing could have been done before release to find the issue
> without the benefit of hindsight.
>
> Every issue needs a response even if the response is "no work to be done."
> If there is work to be done it has to find its way into our testing
> strategy (submit a JIRA, or bring it up here).
>
> *Went poorly:*
>*Key* *Assignee* *Summary* *Revisit reason*  CASSANDRA-7538
>  Sam Tunnicliffe
> Truncate
> of a CF should also delete Paxos CF Truncate not tested with PAXOS, what
> else?  CASSANDRA-7704 <
> https://issues.apache.org/jira/browse/CASSANDRA-7704>
> Benedict FileNotFoundException during STREAM-OUT triggers 100% CPU
> usage Streaming
> testing didn't reproduce this before release  CASSANDRA-7801
>  Sylvain Lebresne A
> successful INSERT with CAS does not always store data in the DB after a
> DELETE Multiple access paths for data not tested together  CASSANDRA-7910
>  Tyler Hobbs
> wildcard
> prepared statements are incorrect after a column is added to the table
> Alter
> table not tested concurrently with ?  CASSANDRA-8018
>  Benjamin Lerer
> Cassandra
> seems to insert twice in custom PerColumnSecondaryIndex Custom 

Re: March 2015 QA retrospective

[Jeremiah D Jordan]

CASSANDRA-8687
>  Jeremiah Jordan 
> Keyspace
> should also check Config.isClientMode Is there a way to test for missing
> Config.isClientMode checks?

We should probably redo the client mode type stuff.  Code should assume we are 
in a tool until isServerMode or something similar is set.  In general, we have 
a lot of offline tools now, and we probably need to improve the testing of said 
tools.

Re: March 2015 QA retrospective

[Jake Luciani]

Here is my response.

 T Jake Luciani Null
pointer after droping keyspace Add/drop keyspace not tested under load,
with server logs checked for errors

To detect this we would need a test to write to a table,  wait for
compaction to start then drop the table before the compaction finished
and check the log for an exception
(there was no impact to the system other than the error)




On Thu, Apr 9, 2015 at 4:05 PM, Tyler Hobbs  wrote:
> Here are my responses for my tickets:
>
> CASSANDRA-7910 - wildcard prepared statements are incorrect after a column
> is added to the table
>
> As part of the ticket, I added general dtests for prepared statement
> invalidation after ALTER TABLE statements:
> https://github.com/riptano/cassandra-dtest/blob/18cd4adaba65a9f424b5b9f52f4bf510b6c7e47f/cql_tests.py#L5170-L5204.
> In general, though, the dtests don't have great coverage on prepared
> statements.  We could add an abstraction layer over query execution to use
> prepared vs unprepared statements with an environment variable.
>
> CASSANDRA-8264 - Problems with multicolumn relations and COMPACT STORAGE
>
> I'm not sure of the best way to catch missing coverage for table settings
> like COMPACT STORAGE is.  Theoretically a careful inspection of code/branch
> coverage would probably reveal this.  Of course, we could also ensure all
> (applicable) tests cover both COMPACT and non-COMPACT, but other table
> settings like the compaction strategy and caching could also affect some
> tests.  I suppose COMPACT STORAGE is the most likely to make a difference,
> so perhaps we should focus on covering that first and postpone coverage for
> the other attributes until we have a more general solution?
>
> CASSANDRA-8286 - Regression in ORDER BY
>
> The dtests did catch this.  We did not ship the bug in 2.0, but
> unfortunately, it did make it into the 2.1.2 release despite the failing
> test. (The test failed shortly before the release, which had its vote over
> the weekend and thus missed test-engineering input.) After the 2.1.2
> release, we decided to make changes to the release process to prevent that:
> ensure a full test run completes before voting, and require sign-off from a
> test engineer before releasing.
>
> CASSANDRA-8288 - cqlsh describe needs to show 'sstable_compression'
>
> We do have round-trip tests for DESCRIBE in the python driver (
> https://github.com/datastax/python-driver/blob/c381fa0f04dbeb9ac389fa017bac8d9cc2ded0be/tests/integration/standard/test_metadata.py#L41),
> but they don't cover every config option permutation.  Although we now have
> coverage for this particular case, adding a suite of tests for this should
> be pretty straightforward, so I'll open a ticket for that.
>
> CASSANDRA-8302 - Filtering for CONTAINS (KEY) on frozen collection
> clustering columns within a partition does not work
>
> This bug didn't ship, but wasn't caught by a failing test.  I'm not sure
> how we could spot the lack of coverage on this -- even branch coverage
> analysis wouldn't show this.  Perhaps taking the time to manually create a
> test-coverage matrix (and post it in jira) when developing the feature is
> the best approach?  The matrix is too large to simply cover mentally, it
> seems.
>
> CASSANDRA-8408 - limit appears to replace page size under certain conditions
>
> This was discovered while more thorough tests for paging were being written
> (by the reporter).  Obviously, these should have existed when the feature
> was written, but part of the problem was that it required driver changes to
> test and we weren't using the native protocol python driver for dtests
> yet.  We still have a bit of a problem with testing new protocol features,
> but we typically add python driver support for the features while
> developing them so that we can at least run relevant dtests locally.  Once
> https://github.com/riptano/cassandra-dtest/issues/188 is complete, it
> should be easier to write dtests against native protocol changes/features.
>
> CASSANDRA-8410 - Select with many IN values on clustering columns can
> result in a StackOverflowError
>
> Agreed, we need boundary tests for large values of IN clauses, large
> inserts/update/deletes/batches (number of query params, number of partition
> keys, and number of clustering keys)
>
> CASSANDRA-8451 - NPE when writetime() or ttl() are nested inside function
> call
>
> I did add a regression dtest for this.  We do have tests for composition of
> functions, but writetime() and ttl() are special functions and didn't have
> the specific test coverage they deserved.  (I did add dtest coverage as
> part of the ticket.)
>
> CASSANDRA-8490 - DISTINCT queries with LIMITs or paging are incorrect when
> partitions are delete
>
> We did have test coverage for this query in general, but the tests didn't
> cover deletes.  I think that in general, our paging tests should all
> exercise deletes (of partitions, rows, and individual cells

Re: March 2015 QA retrospective

[Josh McKenzie]

CASSANDRA-8292 From
Pig: org.apache.cassandra.exceptions.ConfigurationException: Expecting URI
in variable: [cassandra.config]. Please prefix the file with file:/// for
local files or file:/// for remote files. PIG not tested

As advertised. I didn't run the pig tests before commit so that's 100% on
me; I didn't realize we had a separate target for those at that point..
Should be caught by a) me not repeating that mistake and b) our jenkins job.


On Thu, Apr 9, 2015 at 3:39 PM, Jake Luciani  wrote:

> Here is my response.
>
>  T Jake Luciani Null
> pointer after droping keyspace Add/drop keyspace not tested under load,
> with server logs checked for errors
>
> To detect this we would need a test to write to a table,  wait for
> compaction to start then drop the table before the compaction finished
> and check the log for an exception
> (there was no impact to the system other than the error)
>
>
>
>
> On Thu, Apr 9, 2015 at 4:05 PM, Tyler Hobbs  wrote:
> > Here are my responses for my tickets:
> >
> > CASSANDRA-7910 - wildcard prepared statements are incorrect after a
> column
> > is added to the table
> >
> > As part of the ticket, I added general dtests for prepared statement
> > invalidation after ALTER TABLE statements:
> >
> https://github.com/riptano/cassandra-dtest/blob/18cd4adaba65a9f424b5b9f52f4bf510b6c7e47f/cql_tests.py#L5170-L5204
> .
> > In general, though, the dtests don't have great coverage on prepared
> > statements.  We could add an abstraction layer over query execution to
> use
> > prepared vs unprepared statements with an environment variable.
> >
> > CASSANDRA-8264 - Problems with multicolumn relations and COMPACT STORAGE
> >
> > I'm not sure of the best way to catch missing coverage for table settings
> > like COMPACT STORAGE is.  Theoretically a careful inspection of
> code/branch
> > coverage would probably reveal this.  Of course, we could also ensure all
> > (applicable) tests cover both COMPACT and non-COMPACT, but other table
> > settings like the compaction strategy and caching could also affect some
> > tests.  I suppose COMPACT STORAGE is the most likely to make a
> difference,
> > so perhaps we should focus on covering that first and postpone coverage
> for
> > the other attributes until we have a more general solution?
> >
> > CASSANDRA-8286 - Regression in ORDER BY
> >
> > The dtests did catch this.  We did not ship the bug in 2.0, but
> > unfortunately, it did make it into the 2.1.2 release despite the failing
> > test. (The test failed shortly before the release, which had its vote
> over
> > the weekend and thus missed test-engineering input.) After the 2.1.2
> > release, we decided to make changes to the release process to prevent
> that:
> > ensure a full test run completes before voting, and require sign-off
> from a
> > test engineer before releasing.
> >
> > CASSANDRA-8288 - cqlsh describe needs to show 'sstable_compression'
> >
> > We do have round-trip tests for DESCRIBE in the python driver (
> >
> https://github.com/datastax/python-driver/blob/c381fa0f04dbeb9ac389fa017bac8d9cc2ded0be/tests/integration/standard/test_metadata.py#L41
> ),
> > but they don't cover every config option permutation.  Although we now
> have
> > coverage for this particular case, adding a suite of tests for this
> should
> > be pretty straightforward, so I'll open a ticket for that.
> >
> > CASSANDRA-8302 - Filtering for CONTAINS (KEY) on frozen collection
> > clustering columns within a partition does not work
> >
> > This bug didn't ship, but wasn't caught by a failing test.  I'm not sure
> > how we could spot the lack of coverage on this -- even branch coverage
> > analysis wouldn't show this.  Perhaps taking the time to manually create
> a
> > test-coverage matrix (and post it in jira) when developing the feature is
> > the best approach?  The matrix is too large to simply cover mentally, it
> > seems.
> >
> > CASSANDRA-8408 - limit appears to replace page size under certain
> conditions
> >
> > This was discovered while more thorough tests for paging were being
> written
> > (by the reporter).  Obviously, these should have existed when the feature
> > was written, but part of the problem was that it required driver changes
> to
> > test and we weren't using the native protocol python driver for dtests
> > yet.  We still have a bit of a problem with testing new protocol
> features,
> > but we typically add python driver support for the features while
> > developing them so that we can at least run relevant dtests locally.
> Once
> > https://github.com/riptano/cassandra-dtest/issues/188 is complete, it
> > should be easier to write dtests against native protocol
> changes/features.
> >
> > CASSANDRA-8410 - Select with many IN values on clustering columns can
> > result in a StackOverflowError
> >
> > Agreed, we need boundary tests for large values of IN clauses, large
> > inserts/update/deletes/batches (number of query params, nu

Re: March 2015 QA retrospective

[Ariel Weisberg]

Hi,

Thanks Philip.

For items in went poorly, is there anything we could change or should have
done differently to get contributor branches running in CI? I don’t recall
us setting a fixed goal for when that had to be done.

There are two angles to evaluate this from and decide if there is a
problem. We had a schedule goal and we didn’t make it. Or we didn’t have a
schedule goal, but we committed resources and didn’t make progress.

If it's just not done and we are OK with that it wouldn't go under went
poorly (it's just how it went).

*Retrospecting the retrospective*

The retrospective didn’t play out the way I hoped and I think it may be
because I didn’t communicate how we are supposed to use it in enough
detail. For everyone to have nothing to add in the went poorly column means
that in the period of time covered by the retrospective we shipped no bug
fixes for bugs that we think we should have been caught before release.

We know that isn’t true because in JIRA for 2.1.3 there were 114 resolved
bugs. Some of those are going to be things that were addressed before being
released, but a good chunk have to be fixes for issues in previous
releases. The reason we need to do this through a retrospective is that
it’s a lot of work for me and I lack perspective on what is going on with
each individual issue. Having a PHB chase everyone down and find out what
they are doing is inefficient and doesn’t work because it’s lacks
repeatability/scalability and it builds experienced for me, but not for the
team.

*Evaluating 2.13 issues:*
Right now we have what you might call a target rich environment. Many
features aren’t exercised in a realistic way or evaluated by success
criteria (performance, space utilization) that users care about. The first
few retrospectives should be the noisiest as we work through that backlog.

We may be creating regression tests as part of the bug fixes we shipped (I
sure hope we did), but regression tests are != to the kind of tests we
could have written to avoid shipping the bug in the first place. Tests
which have the potential to catch more than just the individual bug in
question.

I’m going to drag into the went poorly category fixes from 2.1.3 and I
would like to have the involved parties (fundamentally this is the
responsibility of the assignee) chime in on why the bug was released in the
first place and what we could kind of test we could have done before
release to catch it. I removed a number of issues that were enhancements,
bugs fixed before release due to successful process, or wontfixed/not
reproducable.

Reasons for revisiting are typically a missing regression test, missing
test that we could run now to detect this class of problem in the future,
and most importantly (and also hardest to nail down), what could we do in
the future when doing that kind of work to build effective tests before
release.

One of things I pick on for some of these is inadequate testing of boundary
conditions, inadequate testing with interrelated components (always hard to
identify and can change over time). Not testing under sufficient load or
with a representative data model or data set is also an issue for some of
these.

*Homework:*
If you are listed as an assignee you need to triage the ticket. Based on
the experience with that bug are we doing sufficient testing now, and what
kind of testing could have been done before release to find the issue
without the benefit of hindsight.

Every issue needs a response even if the response is "no work to be done."
If there is work to be done it has to find its way into our testing
strategy (submit a JIRA, or bring it up here).

*Went poorly:*
   *Key* *Assignee* *Summary* *Revisit reason*  CASSANDRA-7538
 Sam Tunnicliffe Truncate
of a CF should also delete Paxos CF Truncate not tested with PAXOS, what
else?  CASSANDRA-7704 
Benedict FileNotFoundException during STREAM-OUT triggers 100% CPU
usage Streaming
testing didn't reproduce this before release  CASSANDRA-7801
 Sylvain Lebresne A
successful INSERT with CAS does not always store data in the DB after a
DELETE Multiple access paths for data not tested together  CASSANDRA-7910
 Tyler Hobbs wildcard
prepared statements are incorrect after a column is added to the table Alter
table not tested concurrently with ?  CASSANDRA-8018
 Benjamin Lerer Cassandra
seems to insert twice in custom PerColumnSecondaryIndex Custom secondary
indexes not tested before release?  CASSANDRA-8028
 Carl Yeksigian Unable
to compute when histogram overflowed Histogram output not tested with
representative data sets, no regression test  CASSANDRA-8122
 Carl

Re: March 2015 QA retrospective

[Tyler Hobbs]

Here are my responses for my tickets:

CASSANDRA-7910 - wildcard prepared statements are incorrect after a column
is added to the table

As part of the ticket, I added general dtests for prepared statement
invalidation after ALTER TABLE statements:
https://github.com/riptano/cassandra-dtest/blob/18cd4adaba65a9f424b5b9f52f4bf510b6c7e47f/cql_tests.py#L5170-L5204.
In general, though, the dtests don't have great coverage on prepared
statements.  We could add an abstraction layer over query execution to use
prepared vs unprepared statements with an environment variable.

CASSANDRA-8264 - Problems with multicolumn relations and COMPACT STORAGE

I'm not sure of the best way to catch missing coverage for table settings
like COMPACT STORAGE is.  Theoretically a careful inspection of code/branch
coverage would probably reveal this.  Of course, we could also ensure all
(applicable) tests cover both COMPACT and non-COMPACT, but other table
settings like the compaction strategy and caching could also affect some
tests.  I suppose COMPACT STORAGE is the most likely to make a difference,
so perhaps we should focus on covering that first and postpone coverage for
the other attributes until we have a more general solution?

CASSANDRA-8286 - Regression in ORDER BY

The dtests did catch this.  We did not ship the bug in 2.0, but
unfortunately, it did make it into the 2.1.2 release despite the failing
test. (The test failed shortly before the release, which had its vote over
the weekend and thus missed test-engineering input.) After the 2.1.2
release, we decided to make changes to the release process to prevent that:
ensure a full test run completes before voting, and require sign-off from a
test engineer before releasing.

CASSANDRA-8288 - cqlsh describe needs to show 'sstable_compression'

We do have round-trip tests for DESCRIBE in the python driver (
https://github.com/datastax/python-driver/blob/c381fa0f04dbeb9ac389fa017bac8d9cc2ded0be/tests/integration/standard/test_metadata.py#L41),
but they don't cover every config option permutation.  Although we now have
coverage for this particular case, adding a suite of tests for this should
be pretty straightforward, so I'll open a ticket for that.

CASSANDRA-8302 - Filtering for CONTAINS (KEY) on frozen collection
clustering columns within a partition does not work

This bug didn't ship, but wasn't caught by a failing test.  I'm not sure
how we could spot the lack of coverage on this -- even branch coverage
analysis wouldn't show this.  Perhaps taking the time to manually create a
test-coverage matrix (and post it in jira) when developing the feature is
the best approach?  The matrix is too large to simply cover mentally, it
seems.

CASSANDRA-8408 - limit appears to replace page size under certain conditions

This was discovered while more thorough tests for paging were being written
(by the reporter).  Obviously, these should have existed when the feature
was written, but part of the problem was that it required driver changes to
test and we weren't using the native protocol python driver for dtests
yet.  We still have a bit of a problem with testing new protocol features,
but we typically add python driver support for the features while
developing them so that we can at least run relevant dtests locally.  Once
https://github.com/riptano/cassandra-dtest/issues/188 is complete, it
should be easier to write dtests against native protocol changes/features.

CASSANDRA-8410 - Select with many IN values on clustering columns can
result in a StackOverflowError

Agreed, we need boundary tests for large values of IN clauses, large
inserts/update/deletes/batches (number of query params, number of partition
keys, and number of clustering keys)

CASSANDRA-8451 - NPE when writetime() or ttl() are nested inside function
call

I did add a regression dtest for this.  We do have tests for composition of
functions, but writetime() and ttl() are special functions and didn't have
the specific test coverage they deserved.  (I did add dtest coverage as
part of the ticket.)

CASSANDRA-8490 - DISTINCT queries with LIMITs or paging are incorrect when
partitions are delete

We did have test coverage for this query in general, but the tests didn't
cover deletes.  I think that in general, our paging tests should all
exercise deletes (of partitions, rows, and individual cells).  I propose
opening a jira ticket for this.

CASSANDRA-8512 - cqlsh unusable after encountering schema mismatch

I'm not sure what to do here.  Test cqlsh with various clusters in degraded
states?  In general, cqlsh is way undertested -- we need some better
infrastructure for making it testable.

CASSANDRA-8550 - Internal pagination in CQL3 index queries creating
substantial overhead

I'm not generally involved in performance work, so I'm not familiar with
what tools we have here.  Have we made progress towards a standard set of
benchmarks for various queries and configurations?

CASSANDRA-8563 - cqlsh broken for some thrift created

Re: March 2015 QA retrospective

[Ariel Weisberg]

Repeated with sort
   *Key* *Assignee* *Summary* *Revisit reason*  CASSANDRA-8285
 Aleksey Yeschenko Move
all hints related tasks to hints private executor Pierre's reproducer
represents something we weren't doing, but that users are. Is that now
being tested?  CASSANDRA-8462
 Aleksey
Yeschenko Upgrading
a 2.0 to 2.1 breaks CFMetaData on 2.0 nodes Have additional dtest coverage,
need to do this in kitchen sink tests  CASSANDRA-8640
 Anthony Cozzie Paxos
requires all nodes for CAS If PAXOS is not supposed to require all nodes
for CAS we should be able to fail nodes or a certain number of nodes and
still continue to CAS (test availability of CAS under failure conditions).
No regression test.  CASSANDRA-8677
 Ariel Weisberg
rpc_interface
and listen_interface generate NPE on startup when specified interface
doesn't exist Missing unit tests checking error messages for
DatabaseDescriptor  CASSANDRA-8577
 Artem Aliev Values
of set types not loading correctly into Pig Full set of interactions with
PIG not validated  CASSANDRA-7704
 Benedict
FileNotFoundException
during STREAM-OUT triggers 100% CPU usage Streaming testing didn't
reproduce this before release  CASSANDRA-8383
 Benedict Memtable
flush may expire records from the commit log that are in a later memtable No
regression test, no follow up ticket. Could/should this have been
reproducable as an actual bug?  CASSANDRA-8429
 Benedict Some keys
unreadable during compaction Running stress in CI would have caught this,
and we're going to do that  CASSANDRA-8459
 Benedict
"autocompaction"
on reads can prevent memtable space reclaimation What would have reproduced
this before release?  CASSANDRA-8499
 Benedict Ensure
SSTableWriter cleans up properly after failure Testing error paths? Any way
to test things in a loop to detect leaks?  CASSANDRA-8513
 Benedict SSTableScanner
may not acquire reference, but will still release it when closed This had a
user visible component, what test could have caught it befor erelease?
CASSANDRA-8619 
Benedict using CQLSSTableWriter gives ConcurrentModificationException What
kind of test would have caught this before release?  CASSANDRA-8632
 Benedict
cassandra-stress
only generating a single unique row We rely on stress for performance
testing, that might mean it needs real testing that demonstrates it
generates load that looks like the load it is supposed to be generating.
CASSANDRA-8668 
Benedict We don't enforce offheap memory constraints; regression introduced
by 7882 Memory constraints was a supported feature/UI, but not completely
tested before release. Could this have been found most effectively by a
unit test or a blackbox test?  CASSANDRA-8719
 Benedict Using
thrift HSHA with offheap_objects appears to corrupt data Untested
configuration before release, this would be straightforward if we ran with
it?  CASSANDRA-8726 
Benedict throw OOM in Memory if we fail to allocate OOM test Cassandra? Try
and validate that it fails cleanly and can be restarted on OOM? Same for
disk full.  CASSANDRA-8018
 Benjamin Lerer Cassandra
seems to insert twice in custom PerColumnSecondaryIndex Custom secondary
indexes not tested before release?  CASSANDRA-8231
 Benjamin Lerer Wrong
size of cached prepared statements Expected cache capacity not validated
with actual cache capcaity, no regression test  CASSANDRA-8365
 Benjamin Lerer CamelCase
name is used as index name instead of lowercase How can we establish UI
consistency?  CASSANDRA-8421
 Benjamin Lerer Cassandra
2.1.1 & Cassandra 2.1.2 UDT not returning value for LIST type as UDT Is
there a test that could have found this condition before release?
CASSANDRA-8514  Benjamin
Lerer ArrayIndexOutOfBoundsException in nodetool cfhistograms Not released,
but not caught by automated tests either  CASSANDRA-8243
 Björn Hegerfors DTCS
can