Merge develop to s3-develop to pick up riak client changes #1282
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Conflicts: # tests/ts_cluster_group_by_SUITE.erl
Tweak devrel scripts to work with different versions of git
new module ts_simple_percentile
Fix test failures caused by riak client not allowing list keys
REL-69: Move 2.2 YZ tests to yokozuna repo
…ts-1.6-to-develop
REL-69: Merge 2.2 with Develop
Merge latest TS 1.6.x back to develop
make code version-agnostic, only require newly introduced keys and caps to be registered when stepping to next release up/downgrade cycle.
…any_recent_versions updowngrade: better prepare riak.conf & caps, make it work for 1.4-1.5 and 1.5-1.6 cycles
This test was part of the original kv679 suite, but at the time of 2.1 it was put in it's own branch. Riak Test is made up of passing tests, and this test (kv679_dataloss_fb.erl) still fails. Adding this back to a branch off develop in preparation for a fix of this issue.
This removes the race condition where some nodes are upgrading and others arent in the middle of an active fullsync. We are not testing AAE upgrades with this test so we should disable them.
Set force_hashtree_upgrade to true
… expiry interval, in an attempt to get AAE to converge more regularly.
Increased concurrency and lowered sweep interval [JIRA: RIAK-3389]
This test shows a dataloss edge case in riak, even in 2.1 with per-key-actor-epochs enabled. The test is a litte convoluted, and is based on a quickcheck counter example, included in the riak_kv/test directory. In short, both this test, and the other kv679_dataloss_fb test, show that even with multiple replicas acking/storing, a single disk error on a single replica is enough to cause acked writes to be silently and permanently lost. For a replicated database, that is bad.
The partition repair test deletes all the data at a partition, and then repairs it from neighbouring partitions. The subset of repaired data that was originally coordinated by the deleted partition's vnode showed up as `notfound` since the latest kv679 changes here basho/riak_kv#1643. The reason is that the fix in the KV repo adds a new actor to the repaired key's vclock. Prior to this change `verify` in partition_repair.erl did a simple equality check on the binary encoded riak_object values. This change takes into account that a new actor may be in the vclock at the repaired vnode, and uses a semantic equality check based on riak_object merge and riak object equal.
Re-add old kv679 test and add new test for further dataloss edge case
|
I read this as from |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.