thumbot
commented
7 years ago | feature_jrd_bulk-capabilities 3bdd089 | :arrow_right: | riak_ts-develop c382db0 | :white_check_mark: completed |
Looks good! :+1:
:white_check_mark: MERGE
> Started at: 2016-12-01 13:28 > Duration: 1 seconds. > Result: OK > Message: Merge Success: feature_jrd_bulk-capabilities 3bdd089b223cc9062718d0c130877bd6188b5986 onto target branch: riak_ts-develop c382db0e203cc26cee1ecf86927279b7ab720105 > Exit Code: OK > :page_facing_up:
``` Auto-merging src/riak_core_capability.erl Merge made by the 'recursive' strategy. src/riak_core_capability.erl | 35 +++++++++++++++++++++++++++++------ 1 file changed, 29 insertions(+), 6 deletions(-) ``` --------------------------------------------------
Recently Andy Till identified a problem when downgrading a node after upgrading to a version of Riak with an entirely new capability. The new capability was retained in the ring structure, and since the old version of Riak didn't know about the capability to change the value, other nodes assumed the downgraded node retained the feature.
The fix to this problem was to filter out unknown capabilities.
However, since capabilities are registered one at a time and filtering occurs after each registration and during scheduled ticks, correct capabilities could be lost.
The only readily-apparent way to reconcile these problems is to register all capabilities simultaneously. The capability server will be blocked while the registrations occur, so the tick cannot cause a race condition, and the filtering that occurs during
update_supported/2will be applied after the batch has been recognized.One feature not supported by this change is the legacy support that was intended to allow capabilities-savvy nodes to negotiate with older Riak nodes that pre-dated capabilities entirely, relying on environment variables instead. This feature should be dropped entirely as it is no longer relevant to modern versions of Riak.
Awaiting tests and updates to
riak_coreapplications to use this.