Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Tags: Inskape/serf

Tags

v0.11.1

Toggle v0.11.1's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
Bump actions/checkout from 3.3.0 to 4.1.1 (hashicorp#706) [skip ci]

Bumps [actions/checkout](https://github.com/actions/checkout) from 3.3.0 to 4.1.1.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@ac59398...b4ffde6)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

v0.11.0

Toggle v0.11.0's commit message
convert to slog

v0.9.5

Toggle v0.9.5's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
Merge pull request hashicorp#614 from hashicorp/feature/per-node-reco…

…nnect-timeout

v0.9.3

Toggle v0.9.3's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
Avoid issue where two unique leave events for the same node could lea…

…d to infinite rebroadcast storms (hashicorp#606)

Fixes this scenario:

When two leave events for the same node (with different ltimes) are
received by two or more additional nodes without any intermediate state
transitions it will lead to them setting up an infinite gossip echo
chamber rebroadcasting the original node's leave.

When in this situation the only way to recover would be to either:

- Bring the node back so it can send out a fresh "alive" message.

- Use force-leave prune to purge the node's existence from the cluster.

There are two known ways to arrive in this situation:

1. Have a node leave the cluster and then from a different node initiate
   a force-leave. This is the easiest way to reproduce.

2. Have a node leave, rejoin, and leave again in quick succession. This
   requires winning a lot of races in just the right way to have gossip
   from the first leave still rebroadcasting naturally WHILE the second
   round of leaves is rebroadcasting AND to have those rounds of gossip
   arrive at the target nodes before they see the rebroadcast of the
   intervening REJOIN.

The fix is pretty simple. When we witness a node leave event, before we
rebroadcast we need to update the lamport time associated with that node
so that the ltime check will cause the same event to be processed again
and again.

Fixes hashicorp/consul#7960
Fixes hashicorp/consul#8179

v0.8.6

Toggle v0.8.6's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
[backport on v0.8.5] Avoid issue where two unique leave events for th…

…e same node could lead to infinite rebroadcast storms (hashicorp#607)

Backport of hashicorp#606 to follow serf v0.8.5

v0.9.0

Toggle v0.9.0's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
plumbing changes necessary to allow for gossip through an intermediar…

…y network hop (hashicorp#590)

v0.8.5

Toggle v0.8.5's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
Update ForceLeave Prune (hashicorp#580)

* Prune flag on ForceLeave added. Refactor of `reap` function to call to `eraseNode`.