-
Notifications
You must be signed in to change notification settings - Fork 9.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert 14548 #15541
Closed
Closed
Revert 14548 #15541
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
…f-#12271-upstream-release-3.4 Automated cherry pick of etcd-io#12271 on release 3.4
To fix a panic that happens when trying to get ids of etcd members in force new cluster mode, the issue happen if the cluster previously had etcd learner nodes added to the cluster Fixes etcd-io#12285
[Backport 3.4] etcdserver: add ConfChangeAddLearnerNode to the list of config changes
…#12264-upstream-release-3.4 Automated cherry pick of etcd-io#12264
To prevent arbitrary command invocations. Signed-off-by: Gyuho Lee <[email protected]>
Signed-off-by: Gyuho Lee <[email protected]>
Signed-off-by: Gyuho Lee <[email protected]>
Use golang.org/x/sys/unix for F_OFD_* constants. This fixes the issue that F_OFD_GETLK was defined incorrectly, resulting in bugs such as moby/moby#31182 Signed-off-by: Kir Kolyshkin <[email protected]>
[3.4 backport] pkg/fileutil: fix F_OFD_ constants
Signed-off-by: Sam Batschelet <[email protected]>
vendor: bump gorilla/websocket
This fixes etcd being unable to send any message longer than 64 KB as a notification over the websocket. This was because the older version of grpc-websocket-proxy was used and WithMaxRespBodyBufferSize option wasn't set.
etcdserver: Fix 64 KB websocket notification message limit
…de health check in debug level ref. etcd-io#12677 ref. etcd-io@0b9cfa8
[Backport-3.4] etcdserver/api/etcdhttp: log successful etcd server side health check in debug level
Signed-off-by: Gyuho Lee <[email protected]>
Signed-off-by: Sam Batschelet <[email protected]>
Manual cherry pick of etcd-io#12448 on release 3.4
There are situations where we don't wish to fsync but we do want to write the data. Typically this occurs in clusters where fsync latency (often the result of firmware) transiently spikes. For Kubernetes clusters this causes (many) elections which have knock-on effects such that the API server will transiently fail causing other components fail in turn. By writing the data (buffered and asynchronously flushed, so in most situations the write is fast) and avoiding the fsync we no longer trigger this situation and opportunistically write out the data. Anecdotally: Because the fsync is missing there is the argument that certain types of failure events will cause data corruption or loss, in testing this wasn't seen. If this was to occur the expectation is the member can be readded to a cluster or worst-case restored from a robust persisted snapshot. The etcd members are deployed across isolated racks with different power feeds. An instantaneous failure of all of them simultaneously is unlikely. Testing was usually of the form: * create (Kubernetes) etcd write-churn by creating replicasets of some 1000s of pods * break/fail the leader Failure testing included: * hard node power-off events * disk removal * orderly reboots/shutdown In all cases when the node recovered it was able to rejoin the cluster and synchronize.
When using --unsafe-no-fsync still write out the data
The integration jobs fail with timeouts slightly over 3s, increase this marginally so false failures are less prevalent.
integration: relax leader timeout from 3s to 4s
…tion etcdserver: Fix PeerURL validation
Manual cherry-pick of 9571325 for release-3.4.
etcdserver: fix incorrect metrics generated when clients cancel watches
As go 1.12.2 is what is tested in CI as well as recommended to be built with 1.12.2 we should also pin to this in the go directive version.
It is kind of backport from etcd-io#14124. Signed-off-by: Wei Fu <[email protected]>
[3.4] mvcc: push down RangeOptions.limit argv into index tree to reduce memory overhead
Signed-off-by: Iavael <[email protected]>
This formats ipv6 addresses to ensure they can be compared safely Signed-off-by: kidsan <[email protected]>
(cherry picked from commit 9c82e8c) Signed-off-by: Wei Fu <[email protected]>
Signed-off-by: Benjamin Wang <[email protected]>
Signed-off-by: Benjamin Wang <[email protected]>
…30209 [3.4] etctserver: add failpoints walBeforeSync and walAfterSync
Historic capnslog timestamps are in microsecond resolution. We need to match that when we migrate to the zap logger. Signed-off-by: James Blair <[email protected]>
Signed-off-by: Benjamin Wang <[email protected]>
Signed-off-by: Benjamin Wang <[email protected]>
Signed-off-by: Benjamin Wang <[email protected]>
Signed-off-by: James Blair <[email protected]>
Signed-off-by: James Blair <[email protected]>
Signed-off-by: James Blair <[email protected]>
[3.4] Backport bump to go 1.19.6 and golang.org/x/net to v0.7.0
Mitigates CVE-2023-24532. Signed-off-by: James Blair <[email protected]>
[3.4] Backport update to latest go 1.19.7 release
Signed-off-by: Marek Siarkowicz <[email protected]>
… when sharing the same connection Signed-off-by: Marek Siarkowicz <[email protected]>
…h starvation Signed-off-by: Marek Siarkowicz <[email protected]>
…r-3.4 Watch random scheduler 3.4
Signed-off-by: Benjamin Wang <[email protected]>
[3.4] cleanup the go.mod & go.sum files
Problem: during restore in watchableStore.Restore, synced watchers are moved to unsynced. minRev will be behind since it's not updated when watcher stays synced. Solution: update minRev fixes: etcd-io#15271 Signed-off-by: Bogdan Kanivets <[email protected]> Signed-off-by: Marek Siarkowicz <[email protected]>
Signed-off-by: Marek Siarkowicz <[email protected]>
[v3.4] Fix issue15271
This reverts commit 0c6e466.
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.
Please read https://github.com/etcd-io/etcd/blob/main/CONTRIBUTING.md#contribution-flow.
#14322 was backported to release-3.4 in #14548, but it should be reverted too.
cc @ahrtr @serathius