- 🛠 Fix: ineffectual assignments #193
- 🛠 Fix: Make lookups consistent on hash collisions #196
- 🔋 Feature: Self-eviction #177
- 🔋 Feature: Identity Carry Over #188 #189 #190 #191 #192 #194 #195
- 🚚 Travis: Remove Go 1.5 support #187
🚀 Release notes
Identity Carry Over
🔧 Identity carry over provides a way to manually configure the identity of a member on the hashring. 🚀 By changing the identity to be something else than its address, it becomes possible to guarantee ring equality before and after deploys in a dynamic environment (e.g. mesos).
ringpop.SelfEvicton shutdown, a member will declare itself as
faultyand gossips this to the other members. 🚚 This removes the time window where it would be marked as
suspect; in this way removing the time where other members considered it to be part of the ring while it was not responding anymore.
💥 Breaking change to the
Prior to ringpop v0.8.0 the address was used as the identity of a member. Starting with version v0.8.0, it's possible to 🔧 configure a separate identity. As a result, the behaviour of the
IdentityResolverFunchas been changed. 🔧 The
Identityoption now configures the identity of a member and will return an error when it matches an ip:port; services that were using
IdentityResolverFuncshould now use the
AddressResolverFuncoptions. ♻️ You could use the following
gofmtsnippets to easily refactor:
gofmt -r 'ringpop.Identity(a) -> ringpop.Address(a)' -w . gofmt -r 'ringpop.IdentityResolverFunc(a) -> ringpop.AddressResolverFunc(a)' -w .
- 🛠 Fix: Header leaking on the forwarding path caused calls to own endpoints to not be sharded when the same context was used while making the call #197
🚀 Release notes
When applications use their incoming context blindly in an outgoing call it uses the same tchannel headers for the outgoing call as the incoming call had, causing incoming headers to be leaked in the outgoing call. Since most applications don't use headers there is nothing to worry about. However the forwarding path of ringpop uses a header to indicate a call has been forwarded. This header prevents indefinite forwarding loops to occur when applications fail to converge on ownership.
With this fix the header indicating a forwarded call will not be leaked to the application. This makes it possible for applications to use the incoming context on a call to a sharded endpoint on their own or another ringpop servers service an correctly route the request.
- 🔋 Feature: Added label support to ringpop for nodes to annotate themselves with more information #167 #171 #172
- ♻️ Maintainability: Refactored internal representation of member state for more flexible reincarnation and state change of a member #159 #161
- 🛠 Fix: Make sure ringpop is listening for requests before bootstrapping #176 #146
- 🛠 Fix: Added support for imports in
.thriftfiles in generated code for thrift forwarding #162
- 🛠 Fix: Mark generated code as being generated for suppression in diffs #169
- 🛠 Fix: Be more specific in the functionality required from TChannel #166
- ✅ Tests: Run all tests on go 1.7 #179
- ✅ Tests: More stable unit tests, integration tests and race detector tests. Races are now mandatory tests on ci #164 #178 #181 #182
- ✅ Tests: All examples are tested on every pull request #157 #170
🚀 Release notes
🔄 Change to ringpop interface
The ringpop interface changed two existing functions
CountReachableMembersthat now take a variadic argument of type
swim.MemberPredicateinstead of no arguments. This does not change the usage of these functions, but does change the type of the function. This might cause custom declared interfaces to not match ringpop anymore. The solution is to 🔄 change these functions in the interface used to match the current signature.
Previously the signature was:
GetReachableMembers() (string, error) CountReachableMembers() (int, error)
The current signature is:
GetReachableMembers(predicates ...swim.MemberPredicate) (string, error) CountReachableMembers(predicates ...swim.MemberPredicate) (int, error)
🗄 Deprecated RegisterListener
♻️ Due to a refactor in how event emitting is done the
RegisterListenermethod is 🗄 deprecated. Even though it still works and behaves as previously it will start ⚠ logging warnings. Since this code is not on the hot path only little log volume is expected. Instead of this function it is now advised to use
AddListener. This function also returns if the listener has been added or not.
- 🛠 Fix: add 1-buffer for error channels, prevents leaking goroutines. #140
- 🔋 Feature: support forwarding headers. #141
- 🔋 Feature: testpop takes an additional -stats-udp or -stats-file flag that can be used to emit statsd messages to a file or over the network. #144
- 🛠 Fix: race condition when loading hostlist in discover provider. #145
- ✅ Testing: add suspect, faulty and tombstope period command-line flags to testpop. #148
- 🛠 Fix: use oneself as a source when creating a change for reincarnation. #150
- 🚚 Maintainability: move from godep to Glide. #151
- Maintainability: emit lookup and lookupn stats and add a lookupn-event. #152.
- 🛠 Fix: do not reincarnate twice unnecessarily. #153
- 🔋 Feature: Automatic healing of fully partitioned rings that could be cause by temporary network failure. #135 #128 #129
- 🛠 Fix: Fullsyncs are now executed in both directions to prevent persistent asymmetrical partitions. #134
- 🛠 Fix: Overcome protocol incompatibilities in the dissemination of tombstones for the reaping of faulty nodes. #133 #132
- 🛠 Fix: Leaking goroutines on an error response after a timeout. #140
- ♻️ Maintainability: Refactor of internal use of the Discovery Provider. #130
- ✅ Testing: Pin mockery to a specific version for testing stability. #136
- ✅ Testing: Add Go race detector on CI. #137
🚀 Release notes
🚀 Deploying from older versions
🚀 It is advised to complete the deployment of this version within 24 hours after ⬆️ the first node is upgraded. Since the reaping of faulty nodes is added to this 🚀 release a node that upgraded to this version will mark all the faulty members of the ringpop cluster as tombstones (the new state introduced for the reaping of 🚀 faulty nodes) 24 hours after the deploy. If older versions of ringpop run in a cluster that starts declaring these
tombstonesthe cluster will jump in endless fullsyncs mode. Ringpop operates normally under these conditions but extra load on both network and CPU are in effect during this time. The fullsyncs will ⬆️ automatically resolve as soon as all members are upgraded to this version. Same ⏪ might happen during a partial rollback that operates for a longer period of time.