This commit will bump go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc from 1.34.0 to 1.35.0
Also, it bumps indirect dependency: go.opentelemetry.io/otel/exporters/otlp/otlptrace from 1.34.0 to 1.35.0
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
This commit will bump github.com/alexfalkowski/gocovmerge from 1.4.0 to 1.6.0
As an indirect dependency it also bumps,
- golang.org/x/crypto from 0.35.0 to 0.36.0
- golang.org/x/net from 0.36.0 to 0.37.0
- golang.org/x/sync from 0.11.0 to 0.12.0
- golang.org/x/text from 0.22.0 to 0.23.0
- golang.org/x/mod from 0.23.0 to 0.24.0
- golang.org/x/term from 0.29.0 to 0.30.0
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
This commit will bump go.opentelemetry.io/otel from 1.34.0 to 1.35.0
Also bumps,
- go.opentelemetry.io/otel/trace from 1.34.0 to 1.35.0
- go.opentelemetry.io/otel/metric from 1.34.0 to 1.35.0
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
According to the available image tag list [2],
the images for go 1.24 are all prefixed with
`dev-`. Thus, we are using the `dev-` prefixed
image version for now.
Reference:
[1] etcd-io#19524
[2] https://mcr.microsoft.com/v2/devcontainers/go/tags/list
Signed-off-by: Chun-Hung Tseng <henrytseng@google.com>
Use the test package's provided Chdir function. Therefore, it's not
required to evaluate an error (it doesn't return one) or change
directories at the end.
Signed-off-by: Ivan Valdes <ivan@vald.es>
ExperimentalMaxLearners was introduced in v3.6, so there's no need to
worry about deprecating, it can be migrated straight into a FeatureGate.
Signed-off-by: Ivan Valdes <ivan@vald.es>
Replace `go list -m` with `go mod edit -json`, as the latter can return
the same information. This will be helpful when the project migrates to
using a Go workspace, as it will return the current module defined in
go.mod rather than all the modules from the current directory (using a
workspace, the top-level go.mod will return all the child modules from
the repository).
Signed-off-by: Ivan Valdes <ivan@vald.es>
The linter fails with several warnings from new Go 1.24 functions. Due
to the amount of changed lines, it will be better to address them in
several follow-up pull requests.
> 146 files changed, 1157 insertions(+), 1212 deletions(-)
Signed-off-by: Ivan Valdes <ivan@vald.es>
The embedded structure is now also part of the log message. The failure
from the tests is the following:
--- FAIL: TestLogRotation (0.00s)
--- FAIL: TestLogRotation/invalid_logger_config (0.00s)
config_test.go:868: test "invalid logger config", expected
error: invalid log rotation config: json: cannot unmarshal
bool into Go struct field logRotationConfig.maxsize
of type int,
got: invalid log rotation config: json: cannot unmarshal
bool into Go struct field logRotationConfig.Logger.maxsize
of type int
FAIL
Signed-off-by: Ivan Valdes <ivan@vald.es>
This commit will bump inderect dependency(of github.com/golangci/golangci-lint) github.com/rogpeppe/go-internal from v1.13.1 to v1.14.1
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
This commit will bump dependency github.com/klauspost/compress from 1.17.9 to 1.18.0
which is an indirect dependency of the direct dependency: github.com/prometheus/client_golang
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
Thanks to @jmhbnz and @ivanvc 's long time leadership in the release team, adding them as official leads.
Also adding @siyuanfoundation and @fuweid as additional team members.
Thanks everyone for your contribution!
Replace `go list -m` with `go mod edit -json`, as the latter can return
the same information. This will be helpful when the project migrates to
using a Go workspace, as it will return the current module defined in
go.mod rather than all the modules from the current directory (using a
workspace, the top-level go.mod will return all the child modules from
the repository).
Signed-off-by: Ivan Valdes <ivan@vald.es>
1. Update DowngradeUpgradeMembersByID
If it's downgrading process, the desire version of cluster should be
target one.
If it's upgrading process, the desire version of cluster should be
determined by mininum binary version of members.
2. Remove AssertProcessLogs from DowngradeEnable
The log message "The server is ready to downgrade" appears only when the storage
version monitor detects a mismatch between the cluster and storage versions.
If traffic is insufficient to trigger a commit or if an auto-commit occurs right
after reading the storage version, the monitor may fail to update it, leading
to errors like:
```bash
"msg":"failed to update storage version","cluster-version":"3.6.0",
"error":"cannot detect storage schema version: missing confstate information"
```
Given this, we should remove the AssertProcessLogs statement.
Similar to #19313
Signed-off-by: Wei Fu <fuweid89@gmail.com>
The GitHub release templates had the wrong version minor when there's a
prerelease part in the version (i.e., v3.6.0-rc.0). It cut until the
last dot, leaving a wrong minor version (i.e., v3.6.0-rc).
Signed-off-by: Ivan Valdes <ivan@vald.es>
Align running the code coverage upload with other workflows by
executing it from a Makefile target.
Update the current GitHub workflow to call this new target.
Signed-off-by: Ivan Valdes <ivan@vald.es>
The new implementation:
- Uses map to track unique keys for accurate counting
- Excludes internal built-in keys from total count
- Improves code maintainability
Although this approach uses additional memory for the map, the trade-off
is acceptable since:
- Status() is not in hot path
- Correctness takes priority over performance optimization
- Simpler code is easier to maintain
Fixes#19253
Signed-off-by: Xiang Ji <johnsmith.jix@gmail.com>
commit 1897d8af05b3627ac4374f1d2fb285fb7af5199e
Author: Gang Li <gangligit@gmail.com>
Date: Mon Feb 3 16:35:20 2025 -0800
use uname -s to get os name
Signed-off-by: Gang Li <gangligit@gmail.com>
commit 889dd974d5873b8c5e7ccd55732279146db1bcc3
Author: Gang Li <gangligit@gmail.com>
Date: Mon Feb 3 11:34:13 2025 -0800
download correct binary for mac os
Signed-off-by: Gang Li <gangligit@gmail.com>
Signed-off-by: Gang Li <gangligit@gmail.com>
Since #19137, kubernetes traffic profile is unable to send List request
with page size, because limit in option is not accessable. To fix it,
this fix is to introduce Limit() interface.
Fixes: #19292
Signed-off-by: Wei Fu <fuweid89@gmail.com>
Root Cause
The backend commits pending changes into boltdb per 100 ms by default.
When brand-new member starts, that member will save member into
backend by `MustSaveMemberToBackend`. However, it doesn't force change
into boltdb. It depends on backend's auto-commit per 100ms.
If auto-commit happens after `UpdateStorageVersion`, the `UpdateStorageVersion`
will fail on `missing confstate information`. The confstate information
is handled by commit-prehook. Once `UpdateStorageVersion` fails,
`TestSnapshotStatus` won't have another chance to do that because that
server has been closed. So without storage version information, hash of boltdb
data is not expected.
How to reproduce it?
```diff
diff --git a/etcdutl/snapshot/v3_snapshot_test.go b/etcdutl/snapshot/v3_snapshot_test.go
index c2b3d5202..cd88ff995 100644
--- a/etcdutl/snapshot/v3_snapshot_test.go
+++ b/etcdutl/snapshot/v3_snapshot_test.go
@@ -141,6 +141,7 @@ func createDB(t *testing.T, generateContent func(*etcdserver.EtcdServer)) string
t.Helper()
cfg := embed.NewConfig()
+ cfg.BackendBatchInterval = 5 * time.Second
cfg.LogLevel = "fatal"
cfg.Dir = t.TempDir()
```
```bash
➜ snapshot git:(deflaky-TestSnapshotStatus) ✗ go test -v -run "^TestSnapshotStatus$" -count 1 ./
=== RUN TestSnapshotStatus
v3_snapshot_test.go:47:
Error Trace: /home/weifu/workspace/etcd/etcdutl/snapshot/v3_snapshot_test.go:47
Error: Not equal:
expected: 0x62132b4d
actual : 0x6bf96324
Test: TestSnapshotStatus
--- FAIL: TestSnapshotStatus (0.14s)
FAIL
FAIL go.etcd.io/etcd/etcdutl/v3/snapshot 0.154s
FAIL
```
How to fix?
Change `BackendBatchLimit` to `1` so that we can force-commit during
`MustSaveMemberToBackend`.
Signed-off-by: Wei Fu <fuweid89@gmail.com>
For some reason, the goword check has been passing while the file
`tests/integration/embed/embed_proxy_test.go` has an error in the godoc.
Update it so it doesn't show the error anymore.
Signed-off-by: Ivan Valdes <ivan@vald.es>
* Wrap script in functions, add a main function, and call them from it.
* Make environment variables local inside the function scope to avoid
unexpected behaviors by the running environment-supplied variables.
* Fix the typo in the "REPOSITORY" environment variable.
* Rename the input "IMAGE" to "TEST_IMAGE" to avoid clashing with the
environment variable from the Prow infrastructure.
Signed-off-by: Ivan Valdes <ivan@vald.es>
Downgraded severity of 'etcdMembersDown' from 'critical' to 'warning' as a single etcd member being not available should not be a problem for etcd's quorum. If the quorum would not be fulfilled, 'etcdInsufficientMembers' should fire. In addition the 'for' interval was extended from '10m' to '20m' as e.g. a node reboot with a big physical node takes usually longer than 10 minutes.
Signed-off-by: Sebastian Gaiser <sebastiangaiser@users.noreply.github.com>
It wrongly asked the API user to use the last key of previous response
when they should append "\x00" to exclude the last key from the contents
of the next requested page.
Signed-off-by: Aleksander Mistewicz <amistewicz@google.com>
Executed both scripts below again,
- ./scripts/genproto.sh
- ./scripts/update_proto_annotations.sh
Signed-off-by: Benjamin Wang <benjamin.ahrtr@gmail.com>
To handle the case of learner not being ready when being promoted, add
retry with some delay to improve the stability of e2e tests.
Signed-off-by: Jiayin Mao <jiayin.mao@datadoghq.com>
Also bumped:
- go.opentelemetry.io/otel from v1.33.0 to v1.34.0
- go.opentelemetry.io/otel/exporters/otlp/otlptrace from v1.33.0 to v1.34.0
- go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc from v1.33.0 to v1.34.0
- go.opentelemetry.io/otel/metric from v1.33.0 to v1.34.0
- go.opentelemetry.io/otel/sdk from v1.33.0 to v1.34.0
- go.opentelemetry.io/otel/trace from v1.33.0 to v1.34.0
- google.golang.org/genproto/googleapis/api from v0.0.0-20250102185135-69823020774d to v0.0.0-20250115164207-1a7da9e5054f
- google.golang.org/genproto/googleapis/rpc from v0.0.0-20250102185135-69823020774d to v0.0.0-20250115164207-1a7da9e5054f
Reference:
- https://github.com/etcd-io/etcd/pull/19234
- https://github.com/etcd-io/etcd/pull/19236
- https://github.com/etcd-io/etcd/pull/19237
Signed-off-by: Chun-Hung Tseng <henrytseng@google.com>
The tombstone could be the only one available revision in database.
It happens when all historical revisions have been deleted in previous
compactions. Since tombstone revision is still in database, we should
restore it as valid key index. Otherwise, we lost that event.
Signed-off-by: Wei Fu <fuweid89@gmail.com>
Update compaction period logic in periodic compactor to consistently
use 24-hour intervals instead of 1-hour. This fixes incorrect time
calculations where:
- Compaction period now correctly uses 24-hour instead of 1-hour
- Revision recording interval updated to 144-minute (1/10 of 24-hour)
instead of 6-minute
- Retry interval on compaction failure adjusted to 144-minute to
match the new period
This ensures consistent time-based compaction behavior for 24-hour
windows as originally intended.
Fixes #[issue-19017]
Signed-off-by: wodeyoulai <106662970@qq.com>
1) Use SleepBeforeSendWatchResponse failpoint to simulate slow watch
2) Decrease compact period from 200ms to 100ms to increase the probability of compacting on Delete
3) Introduce a new traffic pattern of 50/50 Put and Delete
With these three changes the `make test-robustness-issue18089` command can reproduce issue 18089.
Signed-off-by: Jiayin Mao <jiayin.mao@datadoghq.com>
"addr" is the result of net.JoinHostPort which supports IPv6 address.
Rather than ranging "tp.Endpoints" again, it's better to reuse
"addr" in the first loop to collect "eps".
See #7942 and #7943 for context.
Signed-off-by: Jes Cok <xigua67damn@gmail.com>
Use minimal config struct for YAML marshaling.
Replace custom mapToSortedSlice with standard library functions.
Fix flag verification for deprecated experimental options.
Fixes etcd-io#19066
Signed-off-by: mansoora <syed.mansoor_a@nokia.com>
Use the highest MaximalQPS of all traffic profiles as burst otherwise actual traffic may be accidentally limited.
For example, if burst is set to 200 it is unlikely traffic can achieve higher than 200.
Signed-off-by: Jiayin Mao <jiayin.mao@datadoghq.com>
This patch modernizes the for-range-loop code to copy a map with
"maps.Clone" and "maps.Copy", also eliminates "copyFloats" with
"slices.Clone".
Also simplify "aggSort" and "sortMap" with slices and maps functions.
Signed-off-by: Jes Cok <xigua67damn@gmail.com>
This commit will bump dependency go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc from 0.57.0 to 0.58.0
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
* Fix a couple of broken links related to code styling and linting
* Add `jq` and `xz` to the list of build tools (needed when running
`make verify`)
* Add links to the website of all the listed build tools
Signed-off-by: Jay Vercellone <juanjov@gmail.com>
This commit will bump dependency go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc from 1.32.0 to 1.33.0
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
This check is duplicated as the project uses revive's receiver-naming,
which is more robust, as the current check may have false positives.
Signed-off-by: Ivan Valdes <ivan@vald.es>
Currently if users explicitly set --start-index=0, it will
be ignored. It isn't expected, we should respect it as long
as users explicitly set it.
Signed-off-by: Benjamin Wang <benjamin.ahrtr@gmail.com>
The BOM fix is called from the fix-bom target, which is also a
prerequisite for the fix target. Therefore, running `make fix` runs the
BOM fix twice.
Signed-off-by: Ivan Valdes <ivan@vald.es>
To remove the ugly nil checks by instantiating the logger with a no-op logger if it is nil.
Signed-off-by: Srujan Bharadwaj <srujanbharadwaj44@gmail.com>
Originally this was intended to be a clean up. But after further
investigation the original code didn't work. It didn't detect tabs in
shell scripts.
Signed-off-by: Ivan Valdes <ivan@vald.es>
This commit will bump dependency
- golang.org/x/crypto from 0.29.0 to 0.31.0
- golang.org/x/sys from 0.27.0 to 0.28.0
- golang.org/x/text from 0.20.0 to 0.21.0
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
The original go mod tidy pass implementation was done before the `--diff`
go mod option existed. This simplifies the implementation, as temporary
files are no longer needed.
Signed-off-by: Ivan Valdes <ivan@vald.es>
* Update changelog for both 3.4 and 3.5 to cover the go version bumping
Signed-off-by: Anurag De <anuragde2004@gmail.com>
---------
Signed-off-by: Anurag De <anuragde2004@gmail.com>
The script currently fails if the version provided has the "v" prefix
(i.e., v3.6.0). Allow receiving the prefix and continue with the
process.
Signed-off-by: Ivan Valdes <ivan@vald.es>
* Please add etcd_version annotation in *.proto file with next etcd version
* Run ./scripts/genproto.sh
push_pin
* Run ./scripts/update_proto_annotations.sh
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
* Please add etcd_version annotation in *.proto file with next etcd version
* Run ./scripts/genproto.sh
push_pin
* Run ./scripts/update_proto_annotations.sh
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
This commit will bump dependency go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc from 0.56.0 to 0.57.0
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
This commit will bump dependency go.opentelemetry.io/otel/exporters/otlp/otlptrace from 1.31.0 to 1.32.0
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
As noted in 2024-11-12 releases:
1. Add instructions on how to verify that GitHub authentication works.
2. Detail the steps on how to release the GitHub release.
Signed-off-by: Ivan Valdes <ivan@vald.es>
This adds the min and max TLS version support from #13506 and #15156 to the grpc proxy.
Fixes#13506
Signed-off-by: Thomas Jungblut <tjungblu@redhat.com>
Currently, the script won't change directories into the previously
cloned repository if the temporary location exists. This may be an issue
when testing first with a dry run and later with the actual release.
Signed-off-by: Ivan Valdes <ivan@vald.es>
There was a concurrency bug when accessing the IsLearner
property of a member, which will panic with a nil pointer access error
if the member is removed between the IsMemberExist() and Member() calls.
Signed-off-by: Jan Schär <jan@monogon.tech>
As `tools/mod` also contains the `go.mod` file. We should add it to the
`module_dirs` variable, so that when executing `./scripts/fix.sh`, the
proper checks and fixes can be applied.
To address the issue of broken unit tests and code coverage due to the
directory's lack of Go code, we've introduced a new doc.go file. This
file acts as a placeholder, enabling tools like golangci-lint and
go test to function correctly.
---
Discovered when working on https://github.com/etcd-io/etcd/pull/18575
The directories are checked against the following:
- Command: `find . -type f -name go.mod -exec dirname {} \;`
- Output:
```
./etcdutl
.
./tools/testgrid-analysis
./tools/rw-heatmaps
./tools/mod
./etcdctl
./tests
./server
./api
./client/internal/v2
./client/v3
./client/pkg
./pkg
```
Signed-off-by: Chun-Hung Tseng <henrybear327@gmail.com>
This commit will improve the release documentation guide by incorporating the following points:
1. Step 5 can be simplified to do a single-branch checkout
2. Step 6 should clarify that the release directory is in /tmp/etcd-release-${VERSION}/etcd/release/
3. Step 8 mention to add the "Release" label to the announcement message
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
Due to bumping go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc from 1.27.0 to 1.29.0
Signed-off-by: Chun-Hung Tseng <henrybear327@gmail.com>
Due to bumping go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc from 1.27.0 to 1.29.0
Signed-off-by: Chun-Hung Tseng <henrybear327@gmail.com>
Log:
integration/metrics_test.go:139:4: SA1006: printf-style function with dynamic format string and no further arguments should use print-style function instead (staticcheck)
t.Fatalf(err.Error())
^
integration/clientv3/lease/lease_test.go:410:4: SA1006: printf-style function with dynamic format string and no further arguments should use print-style function instead (staticcheck)
t.Fatalf(errMsg)
Signed-off-by: Chun-Hung Tseng <henrybear327@gmail.com>
* etcdserver: rename `minimumBatchInterval` to `defaultCompactionSleepInterval` and `defaultCompactBatchLimit` to `defaultCompactionBatchLimit`
Signed-off-by: Jalin Wang <JalinWang@outlook.com>
These jobs have been long-running on the prow infrastructure, thanks to
the work from the pull request kubernetes/test-infra#31257. Since they
are required (kubernetes/test-infra#33330), it should be safe to remove
the GitHub actions.
Signed-off-by: Ivan Valdes <ivan@vald.es>
Not hitting minimal QPS is expected to be caused by introduction of
compation. Let's avoid it for high throughput test cases.
Reducing number of clients to avoid linearization timeouts.
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
This commit will add the troubleshooting step in case of `genproto`
errors while performing manual dependency bumps of `grpc-*`
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
Co-authored-by: Benjamin Wang <benjamin.wang@broadcom.com>
Co-authored-by: James Blair <mail@jamesblair.net>
Before this patch, the tombstone can be deleted if its revision is equal
compacted revision. It causes that the watch subscriber won't get this
DELETE event. Based on Compact API[1], we should keep tombstone revision
if it's not less than the compaction revision.
> CompactionRequest compacts the key-value store up to a given revision.
> All superseded keys with a revision less than the compaction revision
> will be removed.
[1]: https://etcd.io/docs/latest/dev-guide/api_reference_v3/
Signed-off-by: Wei Fu <fuweid89@gmail.com>
etcdctl util, create normalizer of examples in util, add some more
examples, change indent of etcdctl from "\t" to " "
Signed-off-by: ah8ad3 <ah8ad3@gmail.com>
This commit will bump dependency bump github.com/grpc-ecosystem/grpc-gateway/v2 from 2.20.0 to 2.21.0 raised by dependabot.
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
The tests/Dockerfile was outdated (using an obsolete Ubuntu
distribution), and it's not being used by any workflow or prow job. This
Dockerfile was the only one using `scripts/install-marker.sh`, which
used a vendorized binary generated by the etcd project. This is not
needed anymore, as marker releases now provide the binaries.
Signed-off-by: Ivan Valdes <ivan@vald.es>
This commit will bump dependency go.opentelemetry.io/otel/sdk from 1.27.0 to 1.28.0 raised by dependabot.
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
This commit will bump dependency github.com/alexfalkowski/gocovmerge from 1.3.8 to 1.3.9 raised by dependabot.
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
In this commit, we update the changelog for gRPC
metadata printing in release 3.5 which is mainly
a backport from PR #18312.
Signed-off-by: Mohamed Awnallah <mohamedmohey2352@gmail.com>
In this commit, we update the changelog for gRPC
metadata printing in release 3.4 which is mainly
a backport from PR #18311.
Signed-off-by: Mohamed Awnallah <mohamedmohey2352@gmail.com>
In commit [[1]], the newTestKeyIndex function creates one key with two
Revision{Main: 14} revisions. However, starting from version [[2]], etcd server
does not allow duplicate keys in a single transaction. This update to
newTestKeyIndex is to avoid confusion and ensure consistency with the
latest etcd server behavior.
REF:
[1]: be80d11948
[2]: https://github.com/etcd-io/etcd/pull/4376
Signed-off-by: Wei Fu <fuweid89@gmail.com>
The markdown linter, marker, now publishes a released version with the
tool. Given that this project is written in Rust, running this check can
now be done by using the statically compiled binary without having the
Rust local environment.
Signed-off-by: Ivan Valdes <ivan@vald.es>
The pull-etcd-unit-test-amd64, pull-etcd-unit-test-386,
pull-etcd-integration-1-cpu-amd64, pull-etcd-integration-2-cpu-amd64
and pull-etcd-integration-8-cpu-amd64 jobs are already running on the
prow infrastructure. It is safe to remove these duplicated workloads
from GitHub actions.
Signed-off-by: Ivan Valdes <ivan@vald.es>
This commit will bump dependency go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc from 0.52.0 to 0.53.0 raised by dependabot.
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
The Go runtime uses runtime Finalizer to delete cert [[1]]. The
interestingGoroutines is able to collect stack like,
```plain
leak.go:103: Found leaked goroutined BEFORE test appears to have leaked :
sync.(*Map).LoadAndDelete(0xc00031e180, {0xe07320, 0xc00009fde0})
/usr/local/go/src/sync/map.go:272 +0x192
sync.(*Map).Delete(...)
/usr/local/go/src/sync/map.go:297
crypto/tls.(*certCache).evict(...)
/usr/local/go/src/crypto/tls/cache.go:73
crypto/tls.(*certCache).active.func1(0x0?)
/usr/local/go/src/crypto/tls/cache.go:65 +0x67
```
It's caused by GC instead of leaky goroutine. interestingGoroutines
should skip it.
[1]: 8e1fdea831/src/crypto/tls/cache.go (L63)
Signed-off-by: Wei Fu <fuweid89@gmail.com>
As tools/mod is not part of the test library's modules, the check to verify
consistent dependency versions ignored it. Explicitly get the dependencies from
this module when running verify-dep.
Signed-off-by: Ivan Valdes <ivan@vald.es>
This commit will bump dependency github.com/bgentry/speakeasy from 0.1.0 to 0.2.0
raised by dependabot.
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
The bucket is already fully public so new releases don't need to run this command.
This will prevent significant terminal spam during the release process as there are thousands of objects in the bucket.
Signed-off-by: James Blair <mail@jamesblair.net>
Right now the basic auth tokens that are deleted after `--auth-token-ttl`
cause info-level logs to be emitted. Change this to debug. This helps with
the issue at #18244 where calling `/readyz` frequently pollutes the etcd server
logs with this log message.
Fixes#18244.
Signed-off-by: Ahmet Alp Balkan <ahmet@linkedin.com>
The goal is to reproduce a DELETE event being dropped in a watch after a compaction
occurs on the revision where the deletion took place. In order to reproduce this, we
perform the following sequence (steps for reproduction thanks to @ahrtr):
- PUT k v2 (assume returned revision = r2)
- PUT k v3 (assume returned revision = r3)
- PUT k v4 (assume returned revision = r4)
- DELETE k (assume returned revision = r5)
- PUT k v6 (assume returned revision = r6)
- COMPACT r5
- WATCH rev=r5
We should get the DELETE event (r5) followed by the PUT event (r6). However, currently we only
get the PUT event with returned revision of r6 (key=k, val=v6).
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
golangci-lint reports the following issue:
storage/mvcc/kvstore.go:312:27: (*store).restore - result 0 (error) is always nil (unparam)
It's due to the fact that both Attach() and compactLockfree() within the
function restore() are able to return an error, but we only log them in
the current implementation. Thus, the return value restore() is always
nil, hence the linter warning.
We have agreed to suppress the linter warning for now [1].
Reference:
[1] https://github.com/etcd-io/etcd/pull/18228#issuecomment-2187309957
Signed-off-by: Chun-Hung Tseng <henrybear327@gmail.com>
Makefile's target `verify-dep` current behavior is to use `go list` to
check consistent dependency versions from direct dependencies. Ignoring
indirect dependencies in a multi-module project could lead to version
mismatches. If module A imports module B, module B's dependency will be
an indirect dependency in module A. Which can potentially have a version
mismatch. Therefore, use `go mod edit` with indirect dependencies, too.
So it can work with all dependencies defined in go.mod.
Fix displaying dependencies with mismatches, as the old code was
searching with grep just for the prefix, which would show other
dependencies that shared the same prefix.
Signed-off-by: Ivan Valdes <ivan@vald.es>
The removed packages are:
* k8s.io/apimachinery/pkg/util/naming
* k8s.io/klog/v2
Do note that removing naming package necessitates adding feature gate
name argument to featuregate.New().
Signed-off-by: Baek <seungtackbaek@google.com>
We'll likely use most of the feature_gate package from component-base.
Also this commit moves the pkg from server/internal/pkg to pkg/.
Signed-off-by: Baek <seungtackbaek@google.com>
The interface can be used throughout the etcd server binary to check if
the feature is enabled or not.
Note that this commit also copies necessary FeatureGate interface from
k8s component-base.
Signed-off-by: Baek <seungtackbaek@google.com>
We should return token to that bucket if `nonUniqueWriteLimiter.Take()`
return true. After unlock Delete/LeaseRevoke ops, the model should be
updated for replay function. There are two updates for `toWatchEvents`.
1. When leaveRevokes op has deleted few keys, we should generate
`delete-operation` events based on alphabetical order of deleted
keys.
2. When putWithLease op hits non-exist lease, we should ignore that
update event.
Signed-off-by: Wei Fu <fuweid89@gmail.com>
Bumping go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc from 1.26.0 to 1.27.0
caused some google.golang.org/genproto/googleapis/api to be updated, causing
CI job pull-etcd-verify to fail. Thus, bumping all google.golang.org/genproto/googleapis/api
to align at the same version
Signed-off-by: Chun-Hung Tseng <henrybear327@gmail.com>
This commit will group similar targets as per
architecture into subtargets to build. It also adds
`build-all` target to build all OS-Arch cominations.
Allows subtargets without scripting
by parameterizing and optimizing OS-ARCH builds
Signed-off-by: ArkaSaha30 <arkasaha30@gmail.com>
Which sets the LocalAddr to an IP address from --initial-advertise-peer-urls.
Also adds e2e test that requires this flag to succeed.
Co-authored-by: HighPon <s.shiraki.business@gmail.com>
Signed-off-by: Edwin Xie <edwin.xie@broadcom.com>
This is required for compaction based failpoint, to allow the traffic
send compaction request causing etcd to crash before failpoint executes
the trigger.
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
This assumption is not true during durability issues like #14370.
In reality we want to avoid situations where WAL is was truncated, for
that it's enough that we ensure that first and last operations are
present.
Found it when running `make test-robustness-issue14370` and instead of
getting `Model is not linearizable` I got that assumptions were broken.
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
Allow setting AllowedCN and AllowedHostname tls fields through config file for peer transport security.
Signed-off-by: Seena Fallah <seenafallah@gmail.com>
This commit adds a script to sync the version present in .go-version
across all go.mod files as the toolchain directive. As part of that,
this commit also modifies go.mod files that did not have synced toolchain
directives.
Additionally, this also adds a script to verify all toolchain and go
directives against the version present in .go-version as follows:
(1) The go directive <= version in .go-version
(2) The toolchain directive == version in .go-version
This script runs as part of the `make verify` target, making it run
as a presbumit by default.
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Additionally, provide ability to opt-out of the .go-version and use a
custom one via env vars: FORCE_HOST_GO and GO_VERSION.
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
The golangci-lint-action step runs only on the repository's top-level
directory. Then, make verify reruns it on the same directory, which is
redundant.
However, to keep make verify target working, golangci-lint needs to be
installed locally.
Signed-off-by: Ivan Valdes <ivan@vald.es>
Define a Python virtual environment to install yamllint, if not
installed locally, in a temporary directory and delete it after the run
of the verify-yamllint command. This avoids the issue of building the
build of materials that doesn't follow symlinks in the virtual
environment directory.
Signed-off-by: Ivan Valdes <ivan@vald.es>
Installation of gsutil asks about picking a cloud proejct from a
list of projects that one has access to along with an option to
create a new project. Clarifying the name here would be helpeful.
Signed-off-by: Sahdev Zala <spzala@us.ibm.com>
Robustness tests require a larger instance size, which user forks cannot
access. It also tries to trigger an ARM64 build that runs on actuated
infrastructure. By not running them on user forks, contributors won't be
notified that their builds are failing due to timeouts trying to run the
job, while the tests will still run on etcd-io/etcd pull requests and
commits.
Signed-off-by: Ivan Valdes <ivan@vald.es>
Upon HTTP request error from fetchFailpointsBody, PUT and DELETE,
all of them will return an error message, which would be nice for
debugging if displayed.
Simplify `Enabled()` logic (linter suggestion)
Signed-off-by: Chun-Hung Tseng <henrybear327@gmail.com>
This is unnecessary, as the documentation for 'go doc fmt' says:
%s the uninterpreted bytes of the string or slice
Signed-off-by: Jes Cok <xigua67damn@gmail.com>
This adds the configured backend quota bytes to the endpoint status response.
related discussion in #17821
Signed-off-by: Thomas Jungblut <tjungblu@redhat.com>
Set GOTOOLCHAIN directive in order to successfully run tests
from root. Else, go will try and download a family of releases
(of the form 1.x), which are not published binaries.
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Discovered turning off LazyFS before creating the report might result in
empty server directory. This PR moves cluster shutdown to defer executed
after we generate report and copies the data from lazyfs directory.
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
formatAddr is just like net.JoinHostPort, I think we can use net.JoinHostPort
directly, it's simpler and clearer.
Signed-off-by: Jes Cok <xigua67damn@gmail.com>
Simplifying bookmarkable to just validate revision order between events
and progress notifies.
Use reliable to validate if events are missing, but still report
broken resumable if first event after revision is missing. It's easier
to have one place that validates event slices.
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
Addresses issues in ListenPeerUrls, ListenClientUrls,
ListenClientHttpUrls, AdvertisePeerUrls, AdvertiseClientUrls.
Signed-off-by: Ivan Valdes <ivan@vald.es>
As the doc is saying:
Deprecated: NameToCertificate only allows associating a single certificate
with a given name. Leave that field nil to let the library select the first
compatible chain from Certificates.
Signed-off-by: Jes Cok <xigua67damn@gmail.com>
Limit can cause multiple request due to pagination.
For reads after a failed write we would like to return to normal write
request as soon as possible.
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
Currently, the running parameters in the `rw-benchmark.sh` script are
hardcoded. Running this script end to end takes around 48 hours with
7 CPU cores. To split the load into smaller jobs, allow these
variables to be provided at run time.
Signed-off-by: Ivan Valdes <ivan@vald.es>
Changes:
- Bump release-3.6 toolchain version to 1.22.2 due to CVE-2023-45288
- Bump golang.org/x/net to v0.23.0
- Update CHANGELOG-3.4, CHANGELOG-3.5, and CHANGELOG-3.6
- Bump go version in rw-heatmaps (which was still at 1.21 where
everything else is at 1.22)
Reference:
- PR #17703
Signed-off-by: Chun-Hung Tseng <henrybear327@gmail.com>
Address the warning "The configuration option `run.skip-files` is
deprecated, please use `issues.exclude-files`."
Signed-off-by: Chun-Hung Tseng <henrybear327@gmail.com>
interestingGoroutines uses so many strings.Contains checks to determine
whether to continue, I think it can be avoided.
This patch introduces shouldSkip func to do the checks in a loop
to make the logic clearer.
Signed-off-by: Jes Cok <xigua67damn@gmail.com>
From 2021-08-13, GitHub is no longer accepting account passwords when authenticating Git operations. You need to add a PAT (Personal Access Token) instead for HTTPS. We should intead keep things simple and just use ssh to push to GitHub.
Signed-off-by: James Blair <mail@jamesblair.net>
AssertTrue and AssertFalse use copyToInterface to copy msg. This is
unnecessary, cause we know the msgAndArgs param of assert.Equal is
variadic:
func Equal(t TestingT, expected, actual interface{}, msgAndArgs ...interface{}) bool
This patch removes copyToInterface function, and use msg directly.
Signed-off-by: Jes Cok <xigua67damn@gmail.com>
`yq` was a tool initially used to get the project's Go version when it
was running on Travis CI. This was removed at the commit
577c898fee, and the project currently uses
`.go-version` to specify the Go version. Therefore, we can safely delete
this dependency.
Signed-off-by: Ivan Valdes <ivan@vald.es>
Currenly Member exports GrpcURL already as a struct variable. However,
when addressing the var-naming linting issues, renaming it from GrpcURL
to GRPCURL, clashes with the GRPCURL() function.
Given that it's already an exported variable, there's no need to define
a getter function. The use of this variable is also mixed, with calls to
both the exported variable (GrpcURL) and the function [GRPCURL()].
Signed-off-by: Ivan Valdes <ivan@vald.es>
The old leader demotes lessor and all the leases' expire time will be
updated. Instead of returning incorrect remaining TTL, we should return
errors to force client retry.
Signed-off-by: Wei Fu <fuweid89@gmail.com>
As the doc of regexp.Regex is saying:
"A Regexp is safe for concurrent use by multiple goroutines, except for configuration
methods, such as Regexp.Longest."
Signed-off-by: Jes Cok <xigua67damn@gmail.com>
As the doc of http.Response.Body says:
// The http Client and Transport guarantee that Body is always
// non-nil, even on responses without a body or responses with
// a zero-length body. It is the caller's responsibility to
// close Body.
Signed-off-by: Jes Cok <xigua67damn@gmail.com>
* Support prevKV
* Support multiple watchers per stream
* Allow continious puts without waiting for event
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
When implementing the fix for progress notifications
(https://github.com/etcd-io/etcd/pull/15237) we made a incorrect
assumption that that unsynched watches will always get at least one event.
Unsynched watches include not only slow watchers, but also newly created
watches that requested current or older revision. In case that non of the events
match watch filter, those newly created watches might become synched
without any event going through.
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
Go v1.22 has an error generating the coverage output. Disable it
temporarily so GitHub workflows can run in the meantime.
Signed-off-by: Ivan Valdes <ivan@vald.es>
Kubernetes uses WithRequireLeader to modify the context passed
to the Watch() and RequestProgress() calls in order to ensure
that a leader is present in the cluster before serving the request.
This commit mimics that behaviour in the Kubernetes traffic.
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
We can check for the condition that Kubernetes checks for, i.e.
prevKV can be nil iff the event is not a create a event, only if
we know whether compaction has occured or not. If compaction has
occured, prevKV can be nil and that is completely valid.
This commit checks if compaction took place during the test run
by querying the /metrics endpoint. Based on if compaction occured,
we now check the Kubernetes condition in the prevKV robustness test.
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Split off valdiating create events from the prevKV test.
The added test tests the following two:
- A create event should not exist in our past history
- A non-create event should exist in our past history
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Event histories after merging serve as an authorotative list of
events that can be seen as ones persisted by etcd, we don't need
PrevValue as part of it.
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
When running the snapshot command, allow receiving an initial memory map
allocation for the database, avoiding future memory allocation issues.
Co-authored-by: Benjamin Wang <benjamin.wang@broadcom.com>
Co-authored-by: Fatih USTA <fatihusta86@gmail.com>
Signed-off-by: Ivan Valdes <ivan@vald.es>
Accept a third argument for NewDefaultBackend for overrides to the
BackendConfig.
Add a new function, WithMmapSize, which modifies the backend config to
provide a custom InitiamMmapSize.
Signed-off-by: Ivan Valdes <ivan@vald.es>
Kubernetes relies on the PrevKV() option in the watches it opens
against etcd. This commit adds a robustness test to validate the
same.
A watch response returned with PrevKV() is valid if:
The value in current event's prevKV matches the previous
event's value of the same key if this is not a create event.
There are cases where there can be a prevKV for a create event
as well, for example if a watch is opened after the key is creatd.
Since we don't simulate for that, we don't check for that.
Further, this adjusts revision numbers such that we can successfully create
a new replay. Needed now since we will have unit tests with
and without PrevKV co-existing and we requite creation of a
new replay everytime we validate PrevKV.
We also regenerate test data with so that prevKV exists in it
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Lazyfs adds additional overhead causing arm64 machines in CI to not reach robustness test qps requirements due to lack of compute power.
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
Creation of event history requires each client to return consistent
events. If clients observed inconsistent view of some revision, merging
will fail and return diff between two clients. This however doesn't
provide hint on what kind of issue happend.
This PR helps cases where there is an error with single watch
stream (like event duplication) by running normal watch validation even
without full event history.
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
scheduleCompaction function
To improve traceability of backend database usage, Added below parameter
related to backend database usage metrics inside scheduledCompaction
function.
current-db-size-bytes
current-db-size
current-db-size-in-use-bytes
current-db-size-in-use
Signed-off-by: Rahul More <rahulbapumore@gmail.com>
Unlike SnapshotWithVersion, the client.Snapshot doesn't wait for first
response. The server could open db after we close connection or shutdown
the server. We can read few bytes to ensure server opens boltdb.
Signed-off-by: Wei Fu <fuweid89@gmail.com>
Added keepalive_listener_unix.go and keepalive_listener_openbsd.go to
handle SetKeepAlivePeriod() specially on OpenBSD.
Signed-off-by: Ruize Tang <1466040111@qq.com>
2023-05-03 14:51:34 +08:00
837 changed files with 34486 additions and 19997 deletions
description:Please confirm this bug report meets the following criteria.
options:
- label:This bug report is not security related, security issues should be disclosed privately via security@etcd.io.
- label:This bug report is not security related, security issues should be disclosed privately via [etcd maintainers](mailto:etcd-maintainers@googlegroups.com).
- label:This is not a support request or question, support requests or questions should be raised in the etcd [discussion forums](https://github.com/etcd-io/etcd/discussions).
- label:You have read the etcd [bug reporting guidelines](https://github.com/etcd-io/etcd/blob/main/Documentation/contributor-guide/reporting_bugs.md).
- label:Existing open issues along with etcd [frequently asked questions](https://etcd.io/docs/latest/faq) have been checked and this is not a duplicate.
- label:I have reviewed the [community membership guidelines](https://github.com/etcd-io/etcd/blob/main/Documentation/contributor-guide/community-membership.md)
required:true
- label:The members are actively contributing to 1 or more etcd subprojects
required:true
- label:The members are being sponsored by two current reviewers or a current maintainer.
required:true
- type:textarea
id:rationale
attributes:
label:How do the new members meet the regular active contribution requirements?
@ -212,7 +212,7 @@ At [Branch][branch], we use kubernetes heavily as our core microservice platform
## Baidu Waimai
- *Application*: SkyDNS, Kubernetes, UDC, CMDB and other distributed systems
- *Launched*: April. 2016
- *Launched*: April 2016
- *Cluster Size*: 3 clusters of 5 members
- *Order of Data Size*: several gigabytes
- *Operator*: Baidu Waimai Operations Department
@ -248,3 +248,13 @@ At [Branch][branch], we use kubernetes heavily as our core microservice platform
- *Operator*: Trasnwarp Operating System
- *Environment*: Bare Metal, Container
- *Backups*: backup scripts
## Cyberfusion
- *Application*: cluster configuration management
- *Launched*: February 2023
- *Cluster Size*: single cluster, 3 nodes
- *Order of Data Size*: kilobytes
- *Operator*: Cyberfusion
- *Environment*: Debian on VMs
- *Backups*: periodic `etcdctl snapshot save` + rotation in cron. More about our setup: https://cyberfusion.io/articles/building-hosting-infrastructure-in-2024-configuration-management-part-1
Previous change logs can be found at [CHANGELOG-3.3](https://github.com/etcd-io/etcd/blob/main/CHANGELOG/CHANGELOG-3.3.md).
## v3.4.29 (tbd)
<hr>
## v3.4.37 (TBC)
### Dependencies
- Bump [golang.org/x/net to v0.36.0 to address CVE-2025-22870](https://github.com/etcd-io/etcd/pull/19529).
- Compile binaries using [go 1.23.7](https://github.com/etcd-io/etcd/pull/19533)
<hr>
## v3.4.36 (2025-02-25)
### etcd server
- [Avoid deadlock in etcd.Close when stopping during bootstrapping](https://github.com/etcd-io/etcd/pull/19166)
- Fix [missing delete event on watch opened on same revision as compaction request](https://github.com/etcd-io/etcd/pull/19251)
### Package `clientv3`
- Fix [runtime panic that occurs when KeepAlive is called with a Context implemented by an uncomparable type](https://github.com/etcd-io/etcd/pull/18936)
### Dependencies
- Compile binaries using [go 1.23.6](https://github.com/etcd-io/etcd/pull/19429)
- Bump golang.org/x/crypto to v0.35.0 to address [CVE-2024-45337](https://github.com/etcd-io/etcd/pull/19197) and [CVE-2025-22869](https://github.com/etcd-io/etcd/pull/19477).
- Bump golang.org/x/net to v0.34.0 to address [CVE-2024-45338](https://github.com/etcd-io/etcd/pull/19197).
<hr>
## v3.4.35 (2024-11-12)
### etcd server
- Fix [watchserver related goroutine leakage](https://github.com/etcd-io/etcd/pull/18785)
- Fix [panicking occurred due to improper error handling during defragmentation](https://github.com/etcd-io/etcd/pull/18843)
- Fix [close temp file(s) in case an error happens during defragmentation](https://github.com/etcd-io/etcd/pull/18855)
### Dependencies
- Compile binaries using [go 1.22.9](https://github.com/etcd-io/etcd/pull/18850).
<hr>
## v3.4.34 (2024-09-11)
### etcd server
- Fix [performance regression issue caused by the `ensureLeadership` in lease renew](https://github.com/etcd-io/etcd/pull/18440).
- [Keep the tombstone during compaction if it happens to be the compaction revision](https://github.com/etcd-io/etcd/pull/18475)
### Package clientv3
- [Print gRPC metadata in guaranteed order using the official go fmt pkg](https://github.com/etcd-io/etcd/pull/18311).
### Dependencies
- Compile binaries using [go 1.22.7](https://github.com/etcd-io/etcd/pull/18549).
- Upgrade [bbolt to 1.3.11](https://github.com/etcd-io/etcd/pull/18488).
<hr>
## v3.4.33 (2024-06-13)
### etcd grpc-proxy
- Fix [Memberlist results not updated when proxy node down](https://github.com/etcd-io/etcd/pull/17896).
### Dependencies
- Compile binaries using go [1.21.11](https://github.com/etcd-io/etcd/pull/18130).
- Upgrade [bbolt to 1.3.10](https://github.com/etcd-io/etcd/pull/17945).
<hr>
## v3.4.32 (2024-04-25)
### etcd server
- Fix [LeaseTimeToLive returns error if leader changed](https://github.com/etcd-io/etcd/pull/17705).
- Fix [ignore raft messages if member id mismatch](https://github.com/etcd-io/etcd/pull/17814).
- Update [the compaction log when bootstrap](https://github.com/etcd-io/etcd/pull/17831).
- [Allow new server to join 3.5 cluster if `next-cluster-version-compatible=true`](https://github.com/etcd-io/etcd/pull/17665)
- [Allow updating the cluster version when downgrading from 3.5](https://github.com/etcd-io/etcd/pull/17821).
- Fix [Revision decreasing after panic during compaction](https://github.com/etcd-io/etcd/pull/17864)
### Package `clientv3`
- Add [requests retry when receiving ErrGPRCNotSupportedForLearner and endpoints > 1](https://github.com/etcd-io/etcd/pull/17692).
- Fix [initialization for epMu in client context](https://github.com/etcd-io/etcd/pull/17714).
### Dependencies
- Compile binaries using [go 1.21.9](https://github.com/etcd-io/etcd/pull/17709).
<hr>
## v3.4.31 (2024-03-21)
### etcd server
- Add [mvcc: print backend database size and size in use in compaction logs](https://github.com/etcd-io/etcd/pull/17436).
- Fix leases wrongly revoked by the leader by [ignoring old leader's leases revoking request](https://github.com/etcd-io/etcd/pull/17465).
- Fix [no progress notification being sent for watch that doesn't get any events](https://github.com/etcd-io/etcd/pull/17567).
- Fix [watch event loss after compaction](https://github.com/etcd-io/etcd/pull/17610).
- Add `next-cluster-version-compatible` flag to [allow downgrade from 3.5](https://github.com/etcd-io/etcd/pull/17330).
### Package `clientv3`
- Add [client backoff and retry config options](https://github.com/etcd-io/etcd/pull/17369).
### Dependencies
- Upgrade [bbolt to 1.3.9](https://github.com/etcd-io/etcd/pull/17484).
- Compile binaries using [go 1.21.8](https://github.com/etcd-io/etcd/pull/17538).
- Upgrade [google.golang.org/protobuf to v1.33.0 to address CVE-2024-24786](https://github.com/etcd-io/etcd/pull/17554).
- Upgrade github.com/sirupsen/logrus to v1.9.3 to address [PRISMA-2023-0056](https://github.com/etcd-io/etcd/pull/17580).
- Compile binaries using [go 1.23.7](https://github.com/etcd-io/etcd/pull/19528).
- Bump [golang.org/x/crypto to v0.35.0 to address CVE-2025-22869](https://github.com/etcd-io/etcd/pull/19478).
- Bump [golang.org/x/net to v0.36.0 to address CVE-2025-22870](https://github.com/etcd-io/etcd/pull/19530).
<hr>
## v3.5.18 (2025-01-24)
### etcd server
- Avoid deadlock in etcd.Close when stopping during bootstrapping, see https://github.com/etcd-io/etcd/pull/19167 and https://github.com/etcd-io/etcd/pull/19258.
- [Print warning messages if any of the deprecated v2store related flags is set](https://github.com/etcd-io/etcd/pull/18999)
- Fix [missing delete event on watch opened on same revision as compaction request](https://github.com/etcd-io/etcd/pull/19249)
### Package `clientv3`
- Fix [runtime panic that occurs when KeepAlive is called with a Context implemented by an uncomparable type](https://github.com/etcd-io/etcd/pull/18937)
- Add [`tls min/max version to grpc proxy`](https://github.com/etcd-io/etcd/pull/18829) to support setting TLS min and max version.
### Dependencies
- Bump [golang-jwt/jwt to 4.5.1 to address GO-2024-3250](https://github.com/etcd-io/etcd/pull/18899).
- Compile binaries using [go 1.22.11](https://github.com/etcd-io/etcd/pull/19211).
- Bump [golang.org/x/crypto to 0.32.0 to address CVE-2024-45337](https://github.com/etcd-io/etcd/pull/19154).
- Bump [golang.org/x/net to 0.34.0 to address CVE-2024-45338](https://github.com/etcd-io/etcd/pull/19158).
<hr>
## v3.5.17 (2024-11-12)
### etcd server
- Fix [watchserver related goroutine leakage](https://github.com/etcd-io/etcd/pull/18784)
- Fix [risk of a partial write txn being applied](https://github.com/etcd-io/etcd/pull/18799)
- Fix [panicking occurred due to improper error handling during defragmentation](https://github.com/etcd-io/etcd/pull/18842)
- Fix [close temp file(s) in case an error happens during defragmentation](https://github.com/etcd-io/etcd/pull/18854)
### Dependencies
- Compile binaries using [go 1.22.9](https://github.com/etcd-io/etcd/pull/18849).
<hr>
## v3.5.16 (2024-09-10)
### etcd server
- Fix [performance regression issue caused by the `ensureLeadership` in lease renew](https://github.com/etcd-io/etcd/pull/18439).
- [Keep the tombstone during compaction if it happens to be the compaction revision](https://github.com/etcd-io/etcd/pull/18474)
- Add [`etcd --experimental-compaction-sleep-interval`](https://github.com/etcd-io/etcd/pull/18514) flag to control the sleep interval between each compaction batch.
### Dependencies
- Compile binaries using [go 1.22.7](https://github.com/etcd-io/etcd/pull/18550).
- Upgrade [bbolt to v1.3.11](https://github.com/etcd-io/etcd/pull/18489).
<hr>
## v3.5.15 (2024-07-19)
### etcd server
- Fix [add prometheus metric registration for metric `etcd_disk_wal_write_duration_seconds`](https://github.com/etcd-io/etcd/pull/18174).
- Add [Support multiple values for allowed client and peer TLS identities](https://github.com/etcd-io/etcd/pull/18160)
- Fix [noisy logs from simple auth token expiration by reducing log level to debug](https://github.com/etcd-io/etcd/pull/18245)
- [Differentiate the warning message for rejected client and peer connections](https://github.com/etcd-io/etcd/pull/18319)
### Package clientv3
- [Print gRPC metadata in guaranteed order using the official go fmt pkg](https://github.com/etcd-io/etcd/pull/18312).
### Dependencies
- Compile binaries using [go 1.21.12](https://github.com/etcd-io/etcd/pull/18271).
- [Fully address CVE-2023-45288 and fix govulncheck CI check](https://github.com/etcd-io/etcd/pull/18170)
## v3.5.14 (2024-05-29)
### etcd server
- Fix [LeaseTimeToLive returns error if leader changed](https://github.com/etcd-io/etcd/pull/17704).
- Fix [not validating database consistent index, and panicking on nil backend](https://github.com/etcd-io/etcd/pull/17151)
- Document [`experimental-enable-lease-checkpoint-persist` flag in etcd help](https://github.com/etcd-io/etcd/pull/17190)
- Fix [needlessly flocking snapshot files when deleting](https://github.com/etcd-io/etcd/pull/17206)
- Add [digest for etcd base image](https://github.com/etcd-io/etcd/pull/17205)
- Fix [delete inconsistencies in read buffer](https://github.com/etcd-io/etcd/pull/17230)
- Add [mvcc: print backend database size and size in use in compaction logs](https://github.com/etcd-io/etcd/pull/17291)
### Dependencies
- Compile binaries using [go 1.20.13](https://github.com/etcd-io/etcd/pull/17275)
- Upgrade [golang.org/x/crypto to v0.17+ to address CVE-2023-48795](https://github.com/etcd-io/etcd/pull/17346)
## v3.5.11 (2023-12-07)
### etcd server
- Fix distributed tracing by ensuring `--experimental-distributed-tracing-sampling-rate` configuration option is available to [set tracing sample rate](https://github.com/etcd-io/etcd/pull/16951).
- Fix [url redirects while checking peer urls during new member addition](https://github.com/etcd-io/etcd/pull/16986)
@ -6,6 +6,49 @@ Previous change logs can be found at [CHANGELOG-3.5](https://github.com/etcd-io/
## v3.6.0 (TBD)
<hr>
## v3.6.0-rc.3 (TBD)
### etcd server
- [Auto sync members in v3store for the issues which have already been affected by #19557](https://github.com/etcd-io/etcd/pull/19636).
<hr>
## v3.6.0-rc.2 (2025-03-05)
### etcd server
- Add [Prometheus metric to query server feature gates](https://github.com/etcd-io/etcd/pull/19495).
### Dependencies
- Compile binaries using [go 1.23.7](https://github.com/etcd-io/etcd/pull/19527).
- Bump [golang.org/x/net to v0.36.0 to address CVE-2025-22870](https://github.com/etcd-io/etcd/pull/19531).
- Bump [github.com/grpc-ecosystem/grpc-gateway/v2 to v2.26.3 to fix the issue of etcdserver crashing on receiving REST watch stream requests](https://github.com/etcd-io/etcd/pull/19522).
<hr>
## v3.6.0-rc.1 (2025-02-25)
### etcdctl v3
- Add [`DowngradeInfo` in result of endpoint status](https://github.com/etcd-io/etcd/pull/19471)
### etcd server
- Add [`DowngradeInfo` to endpoint status response](https://github.com/etcd-io/etcd/pull/19471)
### Dependencies
- Bump [golang.org/x/crypto to v0.35.0 to address CVE-2025-22869](https://github.com/etcd-io/etcd/pull/19480).
<hr>
## v3.6.0-rc.0 (2025-02-13)
See [code changes](https://github.com/etcd-io/etcd/compare/v3.5.0...v3.6.0).
### Breaking Changes
@ -23,7 +66,7 @@ See [code changes](https://github.com/etcd-io/etcd/compare/v3.5.0...v3.6.0).
- [Count the number of keys from users perspective](https://github.com/etcd-io/etcd/pull/19344)
### Package `clientv3`
@ -55,8 +101,6 @@ See [code changes](https://github.com/etcd-io/etcd/compare/v3.5.0...v3.6.0).
- Package `datadir` was moved to `storage/datadir`
### Package `raft`
- Send empty `MsgApp` when entry in-flight limits are exceeded. See [pull/14633](https://github.com/etcd-io/etcd/pull/14633).
- Add [MaxInflightBytes](https://github.com/etcd-io/etcd/pull/14624) setting in `raft.Config` for better flow control of entries.
- [Decouple raft from etcd](https://github.com/etcd-io/etcd/issues/14713). Migrated raft to a separate [repository](https://github.com/etcd-io/raft), and renamed raft module to `go.etcd.io/raft/v3`.
### etcd server
@ -76,12 +120,16 @@ See [code changes](https://github.com/etcd-io/etcd/compare/v3.5.0...v3.6.0).
- Add [`etcd --experimental-snapshot-catch-up-entries`](https://github.com/etcd-io/etcd/pull/15033) flag to configure number of entries for a slow follower to catch up after compacting the raft storage entries and defaults to 5k.
- Decreased [`--snapshot-count` default value from 100,000 to 10,000](https://github.com/etcd-io/etcd/pull/15408)
- Add [`etcd --tls-min-version --tls-max-version`](https://github.com/etcd-io/etcd/pull/15156) to enable support for TLS 1.3.
- Add [`etcd --experimental-stop-grpc-service-on-defrag`](https://github.com/etcd-io/etcd/pull/16278) to enable client failover on defrag.
- Add [quota to endpoint status response](https://github.com/etcd-io/etcd/pull/17877)
- Add [feature gate `SetMemberLocalAddr`](https://github.com/etcd-io/etcd/pull/19413) to [enable using the first specified and non-loopback local address from initial-advertise-peer-urls as the local address when communicating with a peer]((https://github.com/etcd-io/etcd/pull/17661))
- Add [Support multiple values for allowed client and peer TLS identities](https://github.com/etcd-io/etcd/pull/18015)
- Add [`embed.Config.GRPCAdditionalServerOptions`](https://github.com/etcd-io/etcd/pull/14066) to support updating the default internal gRPC configuration for embedded use cases.
### etcd grpc-proxy
- Add [`etcd grpc-proxy start --endpoints-auto-sync-interval`](https://github.com/etcd-io/etcd/pull/14354) flag to enable and configure interval of auto sync of endpoints with server.
- Add [`etcd grpc-proxy start --listen-cipher-suites`](https://github.com/etcd-io/etcd/pull/14308) flag to support adding configurable cipher list.
- Add [`tls min/max version to grpc proxy`](https://github.com/etcd-io/etcd/pull/18816) to support setting TLS min and max version.
### tools/benchmark
@ -93,14 +141,16 @@ See [List of metrics](https://etcd.io/docs/latest/metrics/) for all metrics per
- Compile with [Go 1.21+](https://go.dev/doc/devel/release#go1.21.minor). Please refer to [gc-guide](https://go.dev/doc/gc-guide) to configure `GOGC` and `GOMEMLIMIT` properly.
- Compile with [Go 1.23+](https://go.dev/doc/devel/release#go1.21.minor). Please refer to [gc-guide](https://go.dev/doc/gc-guide) to configure `GOGC` and `GOMEMLIMIT` properly.
### Other
- Use Distroless as base image to make the image less vulnerable and reduce image size.
- [Upgrade grpc-gateway from v1 to v2](https://github.com/etcd-io/etcd/pull/16595).
- [Switch from grpc-ecosystem/go-grpc-prometheus to grpc-ecosystem/go-grpc-middleware/providers/prometheus](https://github.com/etcd-io/etcd/pull/19195).
The project could always use some help to deflake tests. [These](https://github.com/etcd-io/etcd/issues?q=is%3Aissue+is%3Aopen+label%3Atype%2Fflake) are the currently open flaky test issues.
For more, because etcd uses Kubernetes' prow infrastructure to run CI jobs, the past test results can be viewed at [testgrid](https://testgrid.k8s.io/sig-etcd).
1. Check [existing issues](https://github.com/etcd-io/etcd/issues?q=is%3Aissue+is%3Aopen+label%3Atype%2Fflake) to see if an issue has already been opened for this test. If not, open an issue with the `type/flake` label.
2. Try to reproduce the flaky test on your machine via [`stress`](https://pkg.go.dev/golang.org/x/tools/cmd/stress), for example, to reproduce the failure of `TestPeriodicSkipRevNotChange`:
For both options the only supported architecture is `linux-amd64`. Bug reports for other environments will generally be ignored. Supporting new environments requires introduction of proper tests and maintainer support that is currently lacking in the etcd project.
For both options, the only supported architecture is `linux-amd64`. Bug reports for other environments will generally be ignored. Supporting new environments requires the introduction of proper tests and maintainer support that is currently lacking in the etcd project.
If you would like etcd to support your preferred environment you can [file an issue].
### Option 1 - Manually setup local environment
### Option 1 - Manually setup the local environment
This is the original etcd development environment, is most supported and is backwards compatible for development of older etcd versions.
This is the original etcd development environment, is most supported, and is backward compatible for the development of older etcd versions.
Follow the steps below to setup the environment:
Follow the steps below to setup the environment:
- [Clone the repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository)
- Install Go by following [installation](https://go.dev/doc/install). Please check minimal go version in [go.mod file](./go.mod#L3).
- Install Go by following [installation](https://go.dev/doc/install). Please check the minimal go version in [go.mod file](./go.mod#L3).
- Install build tools:
-`make`: For debianbased distributions you can run `sudo apt-get install build-essential`
-`protoc`: You can download for your os. Use version [`v3.20.3`](https://github.com/protocolbuffers/protobuf/releases/tag/v3.20.3).
-`yamllint`: For debian based distribution you can run `sudo apt-get install yamllint`
-[`make`](https://www.gnu.org/software/make/): For Debian-based distributions
you can run `sudo apt-get install build-essential`
-[`protoc`](https://protobuf.dev/): You can download it for your os. Use
- [`yamllint`](https://www.yamllint.com/): For Debian-based distribution you
can run `sudo apt-get install yamllint`
- [`jq`](https://jqlang.github.io/jq/): For Debian-based distribution you can
run `sudo apt-get install jq`
- [`xz`](https://tukaani.org/xz/): For Debian-based distribution you can run
`sudo apt-get install xz-utils`
- Verify that everything is installed by running `make build`
Note: `make build` runs with `-v`. Other build flags can be added through env `GO_BUILD_FLAGS`, **if required**. Eg.,
@ -73,17 +113,17 @@ Note: `make build` runs with `-v`. Other build flags can be added through env `G
GO_BUILD_FLAGS="-buildmode=pie" make build
```
### Option 2 - Automatically setup devcontainer
### Option 2 - Automatically setup devcontainer
This is a more recently added environmnent that aims to make it faster for new contributors to get started with etcd. This option is supported for etcd versions 3.6 onwards.
This is a more recently added environment that aims to make it faster for new contributors to get started with etcd. This option is supported for etcd versions 3.6 onwards.
This option can be [used locally](https://code.visualstudio.com/docs/devcontainers/tutorial) on a system running Visual Studio Code and Docker, or in a remote cloudbased [Codespaces](https://github.com/features/codespaces) environment.
This option can be [used locally](https://code.visualstudio.com/docs/devcontainers/tutorial) on a system running Visual Studio Code and Docker, or in a remote cloud-based [Codespaces](https://github.com/features/codespaces) environment.
To get started, create a codespace for this repository by clicking this 👇
[](https://github.com/codespaces/new?hide_repo_select=true&ref=main&repo=11225014)
A codespace will open in a web-based version of Visual Studio Code. The [dev container](.devcontainer/devcontainer.json) is fully configured with software needed for this project.
A codespace will open in a web-based version of Visual Studio Code. The [dev container](.devcontainer/devcontainer.json) is fully configured with the software needed for this project.
**Note**: Dev containers is an open spec which is supported by [GitHub Codespaces](https://github.com/codespaces) and [other tools](https://containers.dev/supporting).
@ -91,30 +131,31 @@ A codespace will open in a web-based version of Visual Studio Code. The [dev con
## Implement your change
etcd code should follow coding style suggested by the Golang community.
See the [style doc](https://github.com/golang/go/wiki/CodeReviewComments) for details.
etcd code should follow the coding style suggested by the Golang community.
See the [style doc](https://go.dev/wiki/CodeReviewComments) for details.
Please ensure that your change passes static analysis (requires [golangci-lint](https://golangci-lint.run/usage/install/)):
Please ensure that your change passes static analysis (requires
-`make verify-*` to verify a single check, for example `make verify-bom` to verify if bill-of-materials.json file is up-to-date.
-`make verify-*` to verify a single check, for example,`make verify-bom` to verify if `bill-of-materials.json` file is up-to-date.
-`make fix` to fix all checks.
-`make fix-*` to fix a single checks, for example `make fix-bom` to update bill-of-materials.json.
-`make fix-*` to fix a single check, for example,`make fix-bom` to update `bill-of-materials.json`.
Please ensure that your change passes tests.
-`make test-unit` to run unit tests.
-`make test-integration` to run integration tests.
-`make test-e2e` to run e2e tests.
All changes are expected to come with unit test.
All changes are expected to come with a unit test.
All new features are expected to have either e2e or integration tests.
## Commit your change
etcd follows a rough convention for commit messages:
* First line:
* Should start name of package (for example `etcdserver`, `etcdctl`) followed by `:` character.
* Should start with the name of the package (for example `etcdserver`, `etcdctl`) followed by the `:` character.
* Describe the `what` behind the change
* Optionally author might provide the `why` behind the change in the main commit message body.
* Optionally, the author might provide the `why` behind the change in the main commit message body.
* Last line should be `Signed-off-by: firstname lastname <email@example.com>` (can be automatically generate by providing `--signoff` to git commit command).
Please follow [making a pull request](https://docs.github.com/en/get-started/quickstart/contributing-to-projects#making-a-pull-request) guide.
Please follow the [making a pull request](https://docs.github.com/en/get-started/quickstart/contributing-to-projects#making-a-pull-request) guide.
If you are still working on the pull request, you can convert it to draft by clicking `Convert to draft` link just below list of reviewers.
If you are still working on the pull request, you can convert it to a draft by clicking `Convert to draft` link just below the list of reviewers.
Multiple small PRs are preferred over single large ones (>500 lines of code).
Please make sure there is an associated issue for each PR you submit. Create one if it doesn't exist yet, and close the issue
once the PR gets merged and has been backported to previous stable releases, if necessary. If there are multiple PRs linked to
the same issue, refrain from closing the issue until all PRs have been merged and, if needed, backported to previous stable
releases.
## Get your pull request reviewed
Before requesting review please ensure that all GitHub checks were successful.
Before requesting review please ensure that all GitHub and Prow checks are successful. In some cases your pull request may have the label `needs-ok-to-test`. If so an `etcd-io` organisation member will leave a comment on your pull request with `/ok-to-test` to trigger all checks to be run.
It might happen that some unrelated tests on your PR are failing, due to their flakiness.
In such cases please [file an issue] to deflake the problematic test and ask one of [maintainers] to rerun the tests.
If all checks were successful feel free to reach out for review from people that were involved in the original discussion or [maintainers].
Depending on complexity of the PR it might require between 1 and 2 maintainers to approve your change before merging.
Depending on the complexity of the PR it might require between 1 and 2 maintainers to approve your change before merging.
* New development occurs on the [main branch][main].
*Main branch should always have a green build!
*The main branch should always have a green build!
* Backwards-compatible bug fixes should target the main branch and subsequently be ported to stable branches.
* Once the main branch is ready for release, it will be tagged and become the new stable branch.
@ -15,13 +15,12 @@ The `main` branch is our development branch. All new features land here first.
To try new and experimental features, pull `main` and play with it. Note that `main` may not be stable because new features may introduce bugs.
Before the release of the next stable version, feature PRs will be frozen. A [release manager](./release.md#release-management) will be assigned to major/minor version and will lead the etcd community in test, bug-fix and documentation of the release for one to two weeks.
Before the release of the next stable version, feature PRs will be frozen. A [release manager](./release.md#release-management) will be assigned to the major/minor version and will lead the etcd community in testing, bug-fix, and documentation of the release for one to two weeks.
### Stable branches
All branches with prefix `release-` are considered _stable_ branches.
All branches with the prefix `release-` are considered _stable_ branches.
After every minor release ([semver.org](https://semver.org/)), we will have a new stable branch for that release, managed by a [patch release manager](./release.md#release-management). We will keep fixing the backwards-compatible bugs for the latest two stable releases. A _patch_ release to each supported release branch, incorporating any bug fixes, will be once every two weeks, given any patches.
After every minor release ([semver.org](https://semver.org/)), we will have a new stable branch for that release, managed by a [patch release manager](./release.md#release-management). We will keep fixing the backward-compatible bugs for the latest two stable releases. A _patch_ release to each supported release branch, incorporating any bug fixes, will be once every two weeks, given any patches.
The dependabot is enabled & [configured](https://github.com/etcd-io/etcd/blob/main/.github/dependabot.yml) to
manage dependencies for etcd `main` branch. But dependabot doesn't work well for multi-module repository like `etcd`,
see [dependabot-core/issues/6678](https://github.com/dependabot/dependabot-core/issues/6678).
Usually human intervention is required each time when dependabot automatically opens some PRs to bump dependencies.
Please see guidance below.
Usually, human intervention is required each time when dependabot automatically opens some PRs to bump dependencies.
Please see the guidance below.
### Dependencies used in workflows
The PRs which automatically bump dependencies (see examples below) used in workflows are fine, and can be approved & merged directly as long as all checks are successful.
The PRs that automatically bump dependencies (see examples below) used in workflows are fine and can be approved & merged directly as long as all checks are successful.
- [build(deps): bump github/codeql-action from 2.2.11 to 2.2.12](https://github.com/etcd-io/etcd/pull/15736)
- [build(deps): bump actions/checkout from 3.5.0 to 3.5.2](https://github.com/etcd-io/etcd/pull/15735)
@ -33,7 +34,7 @@ The PRs which automatically bump dependencies (see examples below) used in workf
When multiple etcd modules depend on the same package, please bump the package version for all the modules in the correct order. The rule is simple:
if module A depends on module B, then bump the dependency for module B before module A. If the two modules do not depend on each other, then
it doesn't matter to bump which module first. For example, multiple modules depend on `github.com/spf13/cobra`, we need to bump the dependency
it doesn't matter to bump which module first. For example, multiple modules depend on `github.com/spf13/cobra`, so we need to bump the dependency
in the following order,
- go.etcd.io/etcd/pkg/v3
@ -49,7 +50,7 @@ Note the module `go.etcd.io/etcd/tools/v3` doesn't depend on any other modules,
### Steps to bump a dependency
Use the `github.com/spf13/cobra` as an example, follow steps below to bump it from 1.6.1 to 1.7.0 for module `go.etcd.io/etcd/etcdctl/v3`,
Use the `github.com/spf13/cobra` as an example, follow the steps below to bump it from 1.6.1 to 1.7.0 for module `go.etcd.io/etcd/etcdctl/v3`,
```bash
cd${ETCD_ROOT_DIR}/etcdctl
@ -71,11 +72,26 @@ Please close the related PRs which were automatically opened by dependabot.
When you bump multiple dependencies in one PR, it's recommended to create a separate commit for each dependency. But it isn't a must; for example,
you can get all dependencies bumping for the module `go.etcd.io/etcd/tools/v3` included in one commit.
#### Troubleshooting
In an event of bumping the version of protoc, protoc plugins or grpc-gateway, it might change `*.proto` file which can result in the following error:
```bash
[0;31mFAIL: 'genproto' FAILED at Wed Jul 31 07:09:08 UTC 2024
To fix the above error, run the following script from the root of etcd repository:
```bash
./scripts/genproto.sh
```
### Indirect dependencies
Usually we don't bump a dependency if all modules just indirectly depend on it, such as `github.com/go-logr/logr`.
Usually, we don't bump a dependency if all modules just indirectly depend on it, such as `github.com/go-logr/logr`.
If an indirect dependency (e.g. `D1`) causes any CVE or bugs which affect etcd, usually the module (e.g. `M1`, not part of etcd, but used by etcd)
If an indirect dependency (e.g. `D1`) causes any CVE or bugs that affect etcd, usually the module (e.g. `M1`, not part of etcd, but used by etcd)
which depends on it should bump the dependency (`D1`), and then etcd just needs to bump `M1`. However, if the module (`M1`) somehow doesn't
bump the problematic dependency, then etcd can still bump it (`D1`) directly following the same steps above. But as a long-term solution, etcd should
try to remove the dependency on such module (`M1`) that lack maintenance.
@ -83,7 +99,7 @@ try to remove the dependency on such module (`M1`) that lack maintenance.
For mixed cases, in which some modules directly while others indirectly depend on a dependency, we have multiple options,
- Bump the dependency for all modules, no matter it's direct or indirect dependency.
- Bump the dependency only for modules which directly depend on it.
- Bump the dependency only for modules that directly depend on it.
We should try to follow the first way, and temporarily fall back to the second one if we run into any issue on the first way. Eventually we
should fix the issue and ensure all modules depend on the same version of the dependency.
@ -97,32 +113,50 @@ Please refer to [build(deps): bump arduino/setup-protoc from 1.3.0 to 2.0.0](htt
### Rotation worksheet
The dependabot scheduling interval is weekly; it means dependabot will automatically raise a bunch of PRs per week.
Usually human intervention is required each time. We have a [rotation worksheet](https://docs.google.com/spreadsheets/d/1DDWzbcOx1p32MhyelaPZ_SfYtAD6xRsrtGRZ9QXPOyQ/edit#gid=0),
Usually, human intervention is required each time. We have a [rotation worksheet](https://docs.google.com/spreadsheets/d/1jodHIO7Dk2VWTs1IRnfMFaRktS9IH8XRyifOnPdSY8I/edit#gid=1394774387),
and everyone is welcome to participate; you just need to register your name in the worksheet.
## Stable branches
Usually we don't proactively bump dependencies for stable releases unless there are any CVEs or bugs that affect etcd.
Usually, we don't proactively bump dependencies for stable releases unless there are any CVEs or bugs that affect etcd.
If we have to do it, then follow the same guidance above. Note that there is no `./scripts/fix.sh` in release-3.4, so no need to
execute it for 3.4.
## Golang versions
The etcd project aims to maintain a development branch that is on the latest [Go version](https://go.dev/dl), ideally this will align with the Go version in use for Kubernetes project development. For an example on how to update etcd to a new minor release of Go refer to issue <https://github.com/etcd-io/etcd/issues/16393> and the linked pull requests.
The etcd project aims to maintain a development branch that is on the latest [Go version](https://go.dev/dl), ideally, this will align with the Go version in use for Kubernetes project development. For an example of how to update etcd to a new minor release of Go refer to issue <https://github.com/etcd-io/etcd/issues/16393> and the linked pull requests.
Suggested steps for performing a minor version upgrade for the etcd development branch:
1. Carefully review new Go version release notes and potentially related blog for any deprecations, performance impacts or other considerations.
2. Create a github issue to signal intent to upgrade and invite discussion, example <https://github.com/etcd-io/etcd/issues/16393>.
3. Complete the upgrade locally in your development environment.
1. Carefully review new Go version release notes and potentially related blog posts for any deprecations, performance impacts, or other considerations.
2. Create a GitHub issue to signal intent to upgrade and invite discussion, for example,<https://github.com/etcd-io/etcd/issues/16393>.
3. Complete the upgrade locally in your development environment by editing `.go-version` and running `make fix`.
4. Run performance benchmarks locally to compare before and after.
5. Raise a pull request for the changes, example <https://github.com/etcd-io/etcd/pull/16394>.
5. Raise a pull request for the changes, for example,<https://github.com/etcd-io/etcd/pull/16394>.
Stable etcd release branches will be maintained to stay on the latest patch release of a supported Go version, however upgrading minor versions will be avoided unless the minor version in use is now out of support. Refer to the [Go release policy](https://go.dev/doc/devel/release).
Stable etcd release branches will be maintained to stay on the latest patch release of a supported Go version. Upgrading minor versions will be completed before the minor version in use currently is no longer supported. Refer to the [Go release policy](https://go.dev/doc/devel/release).
For an example of how to update etcd to a new patch release of Go refer to issue <https://github.com/etcd-io/etcd/issues/16343> and the linked pull requests.
[bbolt](https://github.com/etcd-io/bbolt) and [raft](https://github.com/etcd-io/raft) are two core dependencies of etcd.
Both etcd 3.4.x and 3.5.x depend on bbolt 1.3.x, and etcd 3.6.x (`main` branch) depends on bbolt 1.4.x.
raft is included in the etcd repository for release-3.4 and release-3.5 branches, so etcd 3.4.x and 3.5.x do not depend on any
external raft module. We moved raft into [a separate repository](https://github.com/etcd-io/raft) starting from 3.6 (`main` branch), and the first raft
release will be v3.6.0, so etcd 3.6.x will depend on raft 3.6.x.
@ -4,80 +4,84 @@ This document provides an overview of etcd features and general development guid
## Overview
The etcd features fall into three stages, experimental, stable, and unsafe.
The etcd features fall into three stages: Alpha, Beta, and GA.
### Experimental
### Alpha
Any new feature is usually added as an experimental feature. An experimental feature is characterized as below:
Any new feature is usually added as an Alpha feature. An Alpha feature is characterized as below:
- Might be buggy due to a lack of user testing. Enabling the feature may not work as expected.
- Disabled by default when added initially.
- Disabled by default.
- Support for such a feature may be dropped at any time without notice
- Featurerelated issues may be given lower priorities.
- It can be removed in the next minor or major release without following the feature deprecation policy unless it graduates to the stable future.
- Feature-related issues may be given lower priorities.
- It can be removed in the next minor or major release without following the feature deprecation policy unless it graduates to a more stable stage.
### Stable
### Beta
A stable feature is characterized as below:
A Beta feature is characterized as below:
- Supported as part of the supported releases of etcd.
-May be enabled by default.
-Enabled by default.
- Discontinuation of support must follow the feature deprecation policy.
### Unsafe
### GA
Unsafe features are rare and listed under the `Unsafe feature:` section in the etcd usage documentation. By default, they are disabled. They should be used with caution following documentation. An unsafe feature can be removed in the next minor or major release without following feature deprecation policy.
A GA feature is characterized as below:
- Supported as part of the supported releases of etcd.
- Always enabled; you cannot disable it. The corresponding feature gate is no longer needed.
- Discontinuation of support must follow the feature deprecation policy.
## Development Guidelines
### Adding a new feature
Any new enhancements to the etcd are typically added as an experimental feature. The general development requirements are listed below. They can be somewhat flexible depending on the scope of the feature and review discussions, and will evolve over time.
- Open an issue
Any new enhancements to the etcd are typically added as an Alpha feature.
etcd follows the Kubernetes [KEP process](https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/0000-kep-process/README.md) for new enhancements. The general development requirements are listed below. They can be somewhat flexible depending on the scope of the feature and review discussions and will evolve over time.
- Open a [KEP](https://github.com/kubernetes/enhancements/issues) issue
- It must provide a clear need for the proposed feature.
- It should list development work items as checkboxes. There must be one work item towards future graduation to the stable future.
- Label the issue with `type/feature` and `experimental`.
- Keep the issue open for tracking purpose until a decision is made on graduation.
- Open a Pull Request (PR)
-Provide unit tests. Integreation tests are also recommended as possible.
-Provide robust e2e test coverage. If the feature being added is complicated or quickly needed, maintainers can decide to go with e2e tests for basic coverage initially and have robust coverage added at the later time before feature graduation to the stable feature.
- It should list development work items as checkboxes. There must be one work item towards future graduation to Beta.
- Label the issue with `/sig etcd`.
- Keep the issue open for tracking purposes until a decision is made on graduation.
- Open a [KEP](https://github.com/kubernetes/enhancements) Pull Request (PR).
-The KEP template can be simplified for etcd.
-It must provide clear graduation criteria for each stage.
- The KEP doc should reside in [keps/sig-etcd](https://github.com/kubernetes/enhancements/tree/master/keps/sig-etcd/)
- Open Pull Requests (PRs) in [etcd](https://github.com/etcd-io/etcd)
- Provide unit tests. Integration tests are also recommended as possible.
- Provide robust e2e test coverage. If the feature being added is complicated or quickly needed, maintainers can decide to go with e2e tests for basic coverage initially and have robust coverage added at a later time before the feature graduation to the stable feature.
- Provide logs for proper debugging.
- Provide metrics and benchmarks as needed.
-The Feature should be disabled by default.
- Any configuration flags related to the implementation of the feature must be prefixed with `experimental` e.g. `--experimental-feature-name`.
-Add an Alpha [feature gate](https://etcd.io/docs/v3.6/feature-gates/).
- Any code changes or configuration flags related to the implementation of the feature must be gated with the feature gate e.g. `if cfg.ServerFeatureGate.Enabled(features.FeatureName)`.
- Add a CHANGELOG entry.
- At least two maintainers must approve feature requirements and related code changes.
- At least two maintainers must approve the KEP and related code changes.
### Graduating an Experimental feature to Stable
### Graduating a feature to the next stage
It is important that experimental features don't get stuck in that stage. They should be revisited and moved to the stable stage following the graduation steps as described here.
#### Locate graduation candidate
Decide if an experimental feature is ready for graduation to the stable stage.
- Find the issue that was used to enable the experimental feature initially. One way to find such issues is to search for issues with `type/feature` and `experimental` labels.
- Fix any known open issues against the feature.
- Make sure the feature was enabled for at least one previous release. Check the PR(s) reference from the issue to see when the feature related code changes were merged.
It is important that features don't get stuck in one stage. They should be revisited and moved to the next stage once they meet the graduation criteria listed in the KEP. A feature should stay at one stage for at least one release before being promoted.
#### Provide implementation
If an experimental feature is found ready for graduation to the stable stage, open a Pull Request (PR) with the following changes.
- Add robust e2e tests if not already provided.
-Add a new stable feature flag identical to the experimental feature flag but without the `--experimental` prefix.
-Deprecate the experimental feature following the [feature deprecation policy](#Deprecating-a-feature).
- Implementation must ensure that both the graduated and deprecated experimental feature flags work as expected. Note that both these flags will co-exist for the timeframe described in the feature deprecation policy.
- Enable the graduated feature by default if needed.
If a feature is found ready for graduation to the next stage, open a Pull Request (PR) with the following changes.
-Update the feature `PreRelease` stage in `server/features/etcd_features.go`.
-Update the status in the original KEP issue.
At least two maintainers must approve the work. Patch releases should not be considered for graduation.
### Deprecating a feature
#### Experimental
An experimental feature deprecates when it graduates to the stable stage.
-Add a deprecation message in the documentation of the experimental feature with a recommendation to use related stable feature. e.g. `DEPRECATED. Use <feature-name> instead.`
-Add a `deprecated` label in the issue that was initially used to enable the experimental feature.
#### Alpha
Alpha features can be removed without going through the deprecation process.
-Remove the feature gate in `server/features/etcd_features.go`, and clean up all relevant code.
-Close the original KEP issue with reasons to drop the feature.
#### Stable
As the project evolves, a stable feature may sometimes need to be deprecated and removed. Such a situation should be handled using the steps below:
- Create an issue for tracking purpose.
- Add a deprecation message in the feature usage documentation before a planned release for feature deprecation. e.g. `To be deprecated in <release>.`. If a new feature replaces the `To be deprecated` feature, then also provide a message saying so. e.g. `Use <feature-name> instead.`.
- Deprecate the feature in the planned release with a message as part of the feature usage documentation. e.g. `DEPRECATED`. If a new feature replaces the deprecated feature, then also provide a message saying so. e.g. `DEPRECATED. Use <feature-name> instead.`.
- Add a `deprecated` label in the related issue.
#### Beta and GA
As the project evolves, a Beta/GA feature may sometimes need to be deprecated and removed. Such a situation should be handled using the steps below:
Remove the deprecated feature in the following release. Close any related issue(s). At least two maintainers must approve the work. Patch releases should not be considered for deprecation.
- A Beta/GA feature can only be deprecated after at least 2 minor or major releases.
- Update original KEP issue if it has not been closed or create a new etcd issue with reasons and steps to deprecate the feature.
- Add the feature deprecation documentation in the release notes and feature gates documentation of the next minor/major release.
- In the next minor/major release, set the feature gate to `{Default: false, PreRelease: featuregate.Deprecated, LockedToDefault: false}` in `server/features/etcd_features.go`. Deprecated feature gates must respond with a warning when used.
- If the feature has GAed, and the original gated codes has been cleaned up, add the disablement codes back with the feature gate.
- In the minor/major release after the next, set the feature gate to `{Default: false, PreRelease: featuregate.Deprecated, LockedToDefault: true}` in `server/features/etcd_features.go`, and start cleaning the code.
At least two maintainers must approve the work. Patch releases should not be considered for deprecation.
For testing and development deployments, the quickest and easiest way is to configure a local cluster. For a production deployment, refer to the [clustering][clustering] section.
@ -28,7 +28,7 @@ Use `etcdctl` to interact with the running cluster:
OK
```
If OK is printed, storing key-value pair is successful.
If OK is printed, storing the key-value pair is successful.
2. Retrieve the value of `foo`:
@ -69,7 +69,7 @@ Use `etcdctl` to interact with the running cluster:
```
$ etcdctl --write-out=table --endpoints=localhost:2379 member list
```
The list of etcd members are displayed as follows:
@ -88,7 +88,7 @@ Use `etcdctl` to interact with the running cluster:
OK
```
If OK is printed, storing key-value pair is successful.
If OK is printed, storing the key-value pair is successful.
### Testing fault tolerance
@ -144,7 +144,7 @@ To exercise etcd's fault tolerance, kill a member and attempt to retrieve the ke
hello
```
Restarting the member re-establish the connection. `etcdctl` will now be able to retrieve the key successfully. To learn more about interacting with etcd, read [interacting with etcd section][interacting].
Restarting the member re-establishs the connection. `etcdctl` will now be able to retrieve the key successfully. To learn more about interacting with etcd, read [interacting with etcd section][interacting].
@ -7,14 +7,14 @@ etcd uses the [zap][zap] library for logging application output categorized into
* Send a normal message to a remote peer
* Write a log entry to disk
* Info: Normal, working log information, everything is fine, but helpful notices for auditing or common operations. Should rather not be logged more frequently than once per a few seconds in normal server's operation.
* Info: Normal, working log information, everything is fine, but helpful notices for auditing or common operations. Should rather not be logged more frequently than once per a few seconds in a normal server's operation.
* Examples:
* Startup configuration
* Start to do snapshot
* Start to do a snapshot
* Warning: (Hopefully) Temporary conditions that may cause errors, but may work fine. A replica disappearing (that may reconnect) is a warning.
* Examples:
* Failure to send raft message to a remote peer
* Failure to send a raft message to a remote peer
* Failure to receive heartbeat message within the configured election timeout
* Error: Data has been lost, a request has failed for a bad reason, or a required resource has been lost.
@ -6,70 +6,126 @@ The procedure includes some manual steps for sanity checking, but it can probabl
## Release management
etcd community members are assigned to manage the release each etcd major/minor version as well as manage patches
and to each stable release branch. The managers are responsible for communicating the timelines and status of each
release and for ensuring the stability of the release branch.
Under the leadership of **James Blair** [@jmhbnz](https://github.com/jmhbnz) and **Ivan Valdes Castillo** [@ivanvc](https://github.com/ivanvc), the following pool of release candidates manages the release of each etcd major/minor version as well as manages patches
to each stable release branch. They are responsible for communicating the timelines and status of each release and
All releases version numbers follow the format of [semantic versioning 2.0.0](http://semver.org/).
All release version numbers follow the format of [semantic versioning 2.0.0](http://semver.org/).
### Major, minor version release, or its pre-release
- Ensure the relevant milestone on GitHub is complete. All referenced issues should be closed, or moved elsewhere.
- Ensure the latest upgrade documentation is available.
- Ensure the relevant [milestone](https://github.com/etcd-io/etcd/milestones) on GitHub is complete. All referenced issues should be closed or moved elsewhere.
- Ensure the latest [upgrade documentation](https://etcd.io/docs/next/upgrades) is available.
- Bump [hardcoded MinClusterVerion in the repository](https://github.com/etcd-io/etcd/blob/v3.4.15/version/version.go#L29), if necessary.
- Add feature capability maps for the new version, if necessary.
### Patch version release
- To request a backport, devlopers submit cherrypick PRs targeting the release branch. The commits should not include merge commits. The commits should be restricted to bug fixes and security patches.
- The cherrypick PRs should target the appropriate release branch (`base:release-<major>-<minor>`). `hack/patch/cherrypick.sh` may be used to automatically generate cherrypick PRs.
- The release patch manager reviews the cherrypick PRs. Please discuss carefully what is backported to the patch release. Each patch release should be strictly better than it's predecessor.
- To request a backport, developers submit cherry-pick PRs targeting the release branch. The commits should not include merge commits. The commits should be restricted to bug fixes and security patches.
- The cherrypick PRs should target the appropriate release branch (`base:release-<major>-<minor>`). The k8s infra cherry pick robot `/cherrypick <branch>` PR chatops command may be used to automatically generate cherrypick PRs.
- The release patch manager reviews the cherrypick PRs. Please discuss carefully what is backported to the patch release. Each patch release should be strictly better than its predecessor.
- The release patch manager will cherry-pick these commits starting from the oldest one into stable branch.
## Write release note
## Write a release note
- Write introduction for the new release. For example, what major bug we fix, what new features we introduce or what performance improvement we make.
- Put `[GH XXXX]` at the head of change line to reference Pull Request that introduces the change. Moreover, add a link on it to jump to the Pull Request.
- Find PRs with `release-note` label and explain them in `NEWS` file, as a straightforward summary of changes for end-users.
- Write an introduction for the new release. For example, what major bug we fix, what new features we introduce, or what performance improvement we make.
- Put `[GH XXXX]` at the head of the change line to reference the Pull Request that introduces the change. Moreover, add a link on it to jump to the Pull Request.
- Find PRs with the `release-note` label and explain them in the `NEWS` file, as a straightforward summary of changes for end-users.
## Build and push the release artifacts
## Patch release criteria
- Ensure `docker` is available.
The etcd project aims to release a new patch version if any of the following conditions are met:
Run release script in root directory:
- Fixed one or more major CVEs (>=7.5).
- Fixed one or more critical bugs.
- Fixed three or more major bugs.
- Fixed five or more minor bugs.
```
DRY_RUN=false ./scripts/release.sh ${VERSION}
## Release guide
### Prerequisites
There are some prerequisites, which should be done before the release process. These are one-time operations,
which don't need to be executed before releasing each version.
1. Generate a GPG key and add it to your GitHub account. Refer to the links on [settings](https://github.com/settings/keys).
2. Ensure you have a Linux machine, on which the git, Golang, and docker have been installed.
- Ensure the Golang version matches the version defined in `.go-version` file.
- Ensure non-privileged users can run docker commands, refer to the [Linux postinstall](https://docs.docker.com/engine/install/linux-postinstall/).
- Ensure there is at least 5GB of free space on your Linux machine.
3. Install gsutil, refer to [gsutil_install](https://cloud.google.com/storage/docs/gsutil_install). When asked about cloud project to use, pick `etcd-development`.
4. Authenticate the image registry, refer to [Authentication methods](https://cloud.google.com/container-registry/docs/advanced-authentication).
-`gcloud auth login`
-`gcloud auth configure-docker`
5. Install gh, refer to [GitHub's documentation](https://github.com/cli/cli#installation). Ensure that running
`gh auth login` succeeds for the GitHub account you use to contribute to etcd,
and that `gh auth status` has a clean exit and doesn't show any issues.
### Release steps
1. Raise an issue to publish the release plan, e.g. [issues/17350](https://github.com/etcd-io/etcd/issues/17350).
2. Raise a `kubernetes/org` pull request to ensure members of the release team are added to the [release github team](https://github.com/orgs/etcd-io/teams/release-etcd).
3. Verify you can pass the authentication to the image registries,
-`docker login gcr.io`
-`docker login quay.io`
- If the release person doesn't have access to 1password, one of the owners (@ahrtr, @ivanvc, @jmhbnz, @serathius) needs to share the password with them per [this guide](https://support.1password.com/share-items/). See rough steps below,
- [Sign in](https://team-etcd.1password.com/home) to your account on 1password.com.
- Click `Your Vault Items` on the right side.
- Select `Password of quay.io`.
- Click `Share` on the top right, and set expiration as `1 hour` and only available to the release person using his/her email.
- Click `Copy Link` then send the link to the release person via slack or email.
4. Clone the etcd repository and checkout the target branch,
It generates all release binaries under the directory `/tmp/etcd-release-${VERSION}/etcd/release/` and images. Binaries are pushed to the Google Cloud bucket
under project `etcd-development`, and images are pushed to `quay.io` and `gcr.io`.
6. Publish the release page on GitHub
- Open the **draft** release URL shown by the release script
- Click the pen button at the top right to edit the release
- Review that it looks correct, reviewing that the bottom checkboxes are checked depending on the
release version (v3.4 no checkboxes, v3.5 has the set as latest release checkbox checked,
v3.6 has the set as pre-release checkbox checked)
- Then, publish the release
7. Announce to the etcd-dev googlegroup
Follow the format of previous release emails sent to etcd-dev@googlegroups.com, see an example below. After sending out the email, ask one of the mailing list maintainers to approve the email from the pending list. Additionally, label the release email as `Release`.
Thanks to everyone who contributed to the release!
etcd team
```
It generates all release binaries and images under directory ./release.
Binaries are pushed to gcr.io and images are pushed to quay.io and gcr.io.
8. Update the changelog to reflect the correct release date.
9. Paste the release link to the issue raised in Step 1 and close the issue.
10. Raise a follow-up `kubernetes/org` pull request to return the GitHub release team to empty, least privilege state.
11. Crease a new stable branch through `git push origin release-${VERSION_MAJOR}.${VERSION_MINOR}` if this is a new major or minor stable release.
12. Re-generate a new password for quay.io if needed (e.g. shared to a contributor who isn't in the release team, and we should rotate the password at least once every 3 months).
## Publish release page in GitHub
#### Release known issues
- Set release title as the version name.
- Follow the format of previous release pages.
- Attach the generated binaries and signatures.
- Select whether it is a pre-release.
- Publish the release!
1. Timeouts pushing binaries - If binaries fail to fully upload to Google Cloud storage, the script must be re-run using the same command. Any artifacts that are already pushed will be overwritten to ensure they are correct. The storage bucket does not use object versioning so incorrect files cannot remain.
## Announce to the etcd-dev Googlegroup
2. Timeouts pushing images - It is rare, although possible for connection timeouts to occur when publishing etcd release images to `quay.io` or `gcr.io`. If this occurs, it is known to be safe to rerun the release script command appending the `--no-upload` flag, and image uploads will gracefully resume.
- Follow the format of [previous release emails](https://groups.google.com/g/etcd-dev).
- Make sure to include a list of authors that contributed since the previous release - something like the following might be handy:
- Create new stable branch through `git push origin ${VERSION_MAJOR}.${VERSION_MINOR}` if this is a major stable release. This assumes `origin` corresponds to "https://github.com/etcd-io/etcd".
- Bump [hardcoded Version in the repository](https://github.com/etcd-io/etcd/blob/v3.4.15/version/version.go#L30) to the version `${VERSION}+git`.
3. GPG vs SSH signing - The release scripts assume that git tags will be signed with a GPG key. Since 2022 GitHub has supported [signing commits and tags using ssh](https://github.blog/changelog/2022-08-23-ssh-commit-verification-now-supported). Until further release script updates are completed you will need to disable this feature in your `~/.gitconfig` and revert to signing via GPG to perform etcd releases.
@ -4,13 +4,13 @@ If any part of the etcd project has bugs or documentation mistakes, please let u
To make the bug report accurate and easy to understand, please try to create bug reports that are:
- Specific. Include as much details as possible: which version, what environment, what configuration, etc. If the bug is related to running the etcd server, please attach the etcd log (the starting log with etcd configuration is especially important).
- Specific. Include as many details as possible: which version, what environment, what configuration, etc. If the bug is related to running the etcd server, please attach the etcd log (the starting log with the etcd configuration is especially important).
- Reproducible. Include the steps to reproduce the problem. We understand some issues might be hard to reproduce, please includes the steps that might lead to the problem. If possible, please attach the affected etcd data dir and stack strace to the bug report.
- Reproducible. Include the steps to reproduce the problem. We understand some issues might be hard to reproduce, please include the steps that might lead to the problem. If possible, please attach the affected etcd data dir and stack trace to the bug report.
- Isolated. Please try to isolate and reproduce the bug with minimum dependencies. It would significantly slow down the speed to fix a bug if too many dependencies are involved in a bug report. Debugging external systems that rely on etcd is out of scope, but we are happy to provide guidance in the right direction or help with using etcd itself.
- Unique. Do not duplicate existing bug report.
- Unique. Do not duplicate existing bug reports.
- Scoped. One bug per report. Do not follow up with another bug inside one report.
@ -26,7 +26,7 @@ We might ask for further information to locate a bug. A duplicated bug report wi
$ kill -QUIT $PID
```
### How to get etcd version
### How to get the etcd version
``` bash
$ etcd --version
@ -39,7 +39,7 @@ $ sudo systemctl cat etcd2
$ sudo journalctl -u etcd2
```
Due to an upstream systemd bug, journald may miss the last few log lines when its processes exit. If journalctl says etcd stopped without fatal or panic message, try `sudo journalctl -f -t etcd2` to get full log.
Due to an upstream systemd bug, journald may miss the last few log lines when its processes exit. If journalctl says etcd stopped without a fatal or panic message, try `sudo journalctl -f -t etcd2` to get the full log.
etcd uses GitHub milestones to track all tasks in each major or minor release. The `roadmap.md` file only records the
most important tasks for each release. The list is based on current maintainers capacity that may shift over time.
Proposed milestones is what we think we can deliver with people we have. If we have more support on the important
stuff, we could pick up more items from backlog. Note that etcd will continue to mainly focus on technical debt over
most important tasks for each release. The list is based on the current maintainer capacity that may shift over time.
Proposed milestones are what we think we can deliver with the people we have. If we have more support on the important
stuff, we could pick up more items from the backlog. Note that etcd will continue to mainly focus on technical debt over
the next few major or minor releases.
Each item has an assigned priority:
- P0 - Critical for the current milestone, and blocks the release.
- P1 - Important for the current milestone, and critical for the next milestone.
- P2 - Nice to have, can be always skipped and should not block anything.
Each item has an assigned priority. Refer to [priority definitions](https://github.com/etcd-io/etcd/blob/main/Documentation/contributor-guide/triage_issues.md#step-5---prioritise-the-issue).
## v3.6.0
@ -17,16 +14,16 @@ For a full list of tasks in `v3.6.0`, please see [milestone etcd-v3.6](https://g
| [Support downgrade](https://github.com/etcd-io/etcd/issues/11716) | P0 | In progress | etcd will support downgrade starting from 3.6.0. But it will also support offline downgrade from 3.5 to 3.4. |
| [StoreV2 deprecation](https://github.com/etcd-io/etcd/issues/12913) | P0 | In progress | This task will be covered in both 3.6 and 3.7. |
| [Release raft 3.6.0](https://github.com/etcd-io/raft/issues/89) | P0 | Not started | etcd 3.6.0 will depends on raft 3.6.0 |
| [Release bbolt 1.4.0](https://github.com/etcd-io/bbolt/issues/553) | P0 | Not started | etcd 3.6.0 will depends on bbolt 1.4.0 |
| [Support /livez and /readyz endpoints](https://github.com/etcd-io/etcd/issues/16007) | P1 | In progress | It provides clearer APIs, and can also workaround the stalled writes issue |
| [Bump gRPC](https://github.com/etcd-io/etcd/issues/16290) | P1 | Completed | It isn't guaranteed to be resolved in 3.6, and might be postponed to 3.7 depending on the effort and risk. |
| [Deprecate grpc-gateway or bump it](https://github.com/etcd-io/etcd/issues/14499) | P1 | Completed | It isn't guaranteed to be resolved in 3.6, and might be postponed to 3.7 depending on the effort and risk. |
| [bbolt: Add logger into bbolt](https://github.com/etcd-io/bbolt/issues/509) | P1 | In progress | It's important to diagnose bbolt issues |
| [bbolt: Add surgery commands](https://github.com/etcd-io/bbolt/issues/370) | P1 | Completed | Surgery commands are important for fixing corrupted db files |
| [Evaluate and (Gradulate or deprecate/remove) experimental features](https://github.com/etcd-io/etcd/issues/16292) | P2 | Not started | This task will be covered in both 3.6 and 3.7. |
| [Support downgrade](https://github.com/etcd-io/etcd/issues/11716) | priority/important-soon | In progress | etcd will support downgrade starting from 3.6.0. But it will also support offline downgrade from 3.5 to 3.4. |
| [StoreV2 deprecation](https://github.com/etcd-io/etcd/issues/12913) | priority/important-soon | In progress | This task will be covered in both 3.6 and 3.7. |
| [Release raft 3.6.0](https://github.com/etcd-io/raft/issues/89) | priority/important-soon | Not started | etcd 3.6.0 will depends on raft 3.6.0 |
| [Release bbolt 1.4.0](https://github.com/etcd-io/bbolt/issues/553) | priority/important-soon | Not started | etcd 3.6.0 will depends on bbolt 1.4.0 |
| [Support /livez and /readyz endpoints](https://github.com/etcd-io/etcd/issues/16007) | priority/important-longterm | In progress | It provides clearer APIs, and can also workaround the stalled writes issue |
| [Bump gRPC](https://github.com/etcd-io/etcd/issues/16290) | priority/important-longterm | Completed | It isn't guaranteed to be resolved in 3.6, and might be postponed to 3.7 depending on the effort and risk. |
| [Deprecate grpc-gateway or bump it](https://github.com/etcd-io/etcd/issues/14499) | priority/important-longterm | Completed | It isn't guaranteed to be resolved in 3.6, and might be postponed to 3.7 depending on the effort and risk. |
| [bbolt: Add logger into bbolt](https://github.com/etcd-io/bbolt/issues/509) | priority/important-longterm | Completed | It's important to diagnose bbolt issues |
| [bbolt: Add surgery commands](https://github.com/etcd-io/bbolt/issues/370) | priority/important-longterm | Completed | Surgery commands are important for fixing corrupted db files |
| [Evaluate and (Gradulate or deprecate/remove) experimental features](https://github.com/etcd-io/etcd/issues/16292) | priority/backlog | Not started | This task will be covered in both 3.6 and 3.7. |
## v3.7.0
@ -36,7 +33,7 @@ For a full list of tasks in `v3.7.0`, please see [milestone etcd-v3.7](https://g
| [Refactor lease: Lease might be revoked by mistake by old leader](https://github.com/etcd-io/etcd/issues/15247) | P1 | to be investigated & discussed |
| [Integrate raft's new feature (async write) into etcd](https://github.com/etcd-io/etcd/issues/16291) | P1 | It should can improve the performance |
| [Integrate raft's new feature (async write) into etcd](https://github.com/etcd-io/etcd/issues/16291) | P1 | It should improve the performance |
| [bbolt: Support customizing the bbolt rebalance threshold](https://github.com/etcd-io/bbolt/issues/422) | P2 | It may get rid of etcd's defragmentation. Both bbolt and etcd need to be changed. |
| [Evaluate and (graduate or deprecate/remove) experimental features](https://github.com/etcd-io/etcd/issues/16292) | P2 | Finish the remaining tasks 3.7. |
The `etcd` issues are listed at <https://github.com/etcd-io/etcd/issues> and are identified with labels. For example, an issue that is identified as a bug will be set to label `type/bug`.
The `etcd` issues are listed at <https://github.com/etcd-io/etcd/issues> and are identified with labels. For example, an issue that is identified as a bug will be set to the label `type/bug`.
The etcd project uses labels to indicate common attributes such as `area`, `type` and `priority` of incoming issues.
The etcd project uses labels to indicate common attributes such as `area`, `type`, and `priority` of incoming issues.
New issues will often start out without any labels, but typically `etcd` maintainers, reviewers and members will add labels by following these triage guidelines. The detailed list of labels can be found at <https://github.com/etcd-io/etcd/labels>.
New issues will often start without any labels, but typically `etcd` maintainers, reviewers, and members will add labels by following these triage guidelines. The detailed list of labels can be found at <https://github.com/etcd-io/etcd/labels>.
## Scope
This document serves as the primary guidelines for triaging incoming issues in `etcd`.
All contributors are encouraged and welcome to help manage issues which will help reduce burden on project maintainers, though the work and responsibilities discussed in this document are created with `etcd` project reviewers and members in mind as these individuals will have triage access to the etcd project which is a requirement for actions like applying labels or closing issues.
All contributors are encouraged and welcome to help manage issues which will help reduce the burden on project maintainers, though the work and responsibilities discussed in this document are created with `etcd` project reviewers and members in mind as these individuals will have triage access to the etcd project which is a requirement for actions like applying labels or closing issues.
Refer to [etcd community membership](https://github.com/etcd-io/etcd/blob/main/Documentation/contributor-guide/community-membership.md) for guidance on becoming and etcd project member or reviewer.
Refer to [etcd community membership](https://github.com/etcd-io/etcd/blob/main/Documentation/contributor-guide/community-membership.md) for guidance on becoming an etcd project member or reviewer.
## Step 1 - Find an issue to triage
@ -34,33 +34,33 @@ Before we start adding labels or trying to work out a priority, our first triage
### Issues that don't belong to etcd
Sometime issues are reported that actually belongs to other projects that `etcd` use. For example, `grpc` or `golang` issues. Such issues should be addressed by asking reporter to open issues in appropriate other project.
Sometimes issues are reported that belong to other projects that `etcd` use. For example, `grpc` or `golang` issues. Such issues should be addressed by asking the reporter to open issues in the appropriate other projects.
These issues can generally be closed unless a maintainer and issue reporter see a need to keep it open for tracking purpose. If you have triage permissions please close it, alternatively mention the @etcd-io/members group to request a member with triage access close the issue.
These issues can generally be closed unless a maintainer and issue reporter see a need to keep it open for tracking purposes. If you have triage permissions please close it, alternatively mention the @etcd-io/members group to request a member with triage access to close the issue.
### Duplicate issues
If an issue is a duplicate, add a comment stating so along with a reference for the original issue and if you have triage permissions please close it, alternatively mention the @etcd-io/members group to request a member with triage access close the issue.
## Step 3 - Apply the appropriate type label
## Step 3 - Apply the appropriate type of label
Adding a `type` label to an issue helps create visibility on the health of the project and helps contributors identify potential priorities, i.e. addressing existing bugs or test flakes before implementing new features.
### Support requests
As a general rule the focus for etcd support is to address common themes in a broad way that helps all users, i.e. through channels like known issues, frequently asked questions and highquality documentation. To make the best use of project members time we should avoid providing 1:1 support if a broad approach is available.
As a general rule, the focus for etcd support is to address common themes in a broad way that helps all users, i.e. through channels like known issues, frequently asked questions, and high-quality documentation. To make the best use of project members time we should avoid providing 1:1 support if a broad approach is available.
Some people mistakenly use our GitHub bug report or feature request templates to file support requests. Usually they are asking for help operating or configuring some aspect of etcd. Support requests for etcd should instead be raised as [discussions](https://github.com/etcd-io/etcd/discussions).
Some people mistakenly use our GitHub bug report or feature request templates to file support requests. Usually, they are asking for help operating or configuring some aspect of etcd. Support requests for etcd should instead be raised as [discussions](https://github.com/etcd-io/etcd/discussions).
Common types of support requests are:
1. Questions about configuring or operating existing welldocumented etcd features, for example <https://github.com/etcd-io/etcd/issues/15945>. Note - If an existing feature is not well documented please apply the `area/documentation` label and propose documentation improvements that would prevent future users from stumbling on the problem again.
1. Questions about configuring or operating existing well-documented etcd features, for example,<https://github.com/etcd-io/etcd/issues/15945>. Note - If an existing feature is not well documented please apply the `area/documentation` label and propose documentation improvements that would prevent future users from stumbling on the problem again.
2. Bug reports or questions about unspported versions of etcd, for example <https://github.com/etcd-io/etcd/issues/15796>. When responding to these issues please refer to our [supported versions documentation](https://etcd.io/docs/latest/op-guide/versioning) and encourage the reporter to upgrade to a recent patch release of a supported version as soon as possible. We should limit the effort supporting users that do not make the effort to run a supported version of etcd or ensure their version is patched.
2. Bug reports or questions about unsupported versions of etcd, for example <https://github.com/etcd-io/etcd/issues/15796>. When responding to these issues please refer to our [supported versions documentation](https://etcd.io/docs/latest/op-guide/versioning) and encourage the reporter to upgrade to a recent patch release of a supported version as soon as possible. We should limit the effort supporting users that do not make the effort to run a supported version of etcd or ensure their version is patched.
3. Bug reports that do not provide a complete list of steps to reproduce issue and/or contributors are not able to reproduce the issue, for example <https://github.com/etcd-io/etcd/issues/15740>. We should limit the effort we put into reproducing issues ourselves and motivate users to provide necessary information to accept the bug report.
3. Bug reports that do not provide a complete list of steps to reproduce the issue and/or contributors are not able to reproduce the issue, for example,<https://github.com/etcd-io/etcd/issues/15740>. We should limit the effort we put into reproducing issues ourselves and motivate users to provide the necessary information to accept the bug report.
4. General questions that are filed using feature request or bug report issue templates, for example <https://github.com/etcd-io/etcd/issues/15914>. Note - These types of requests may surface good additions to our [frequently asked questions](https://etcd.io/docs/v3.5/faq).
4. General questions that are filed using feature request or bug report issue templates, for example,<https://github.com/etcd-io/etcd/issues/15914>. Note - These types of requests may surface good additions to our [frequently asked questions](https://etcd.io/docs/v3.5/faq).
If you identify that an issue is a support request please:
@ -70,7 +70,7 @@ If you identify that an issue is a support request please:
> Thank you for your question, this support issue will be moved to our [Discussion Forums](https://github.com/etcd-io/etcd/discussions).
>
> We are trying to consolidate the channels to which questions for help/support are posted so that we can improve our efficiency in responding to your requests, and to make it easier for you to find answers to frequently asked questions and how to address common use cases.
> We are trying to consolidate the channels to which questions for help/support are posted so that we can improve our efficiency in responding to your requests, and make it easier for you to find answers to frequently asked questions and how to address common use cases.
>
> We regularly see messages posted in multiple forums, with the full response thread only in one place or, worse, spread across multiple forums. Also, the large volume of support issues on GitHub is making it difficult for us to use issues to identify real bugs.
>
@ -83,23 +83,23 @@ If you identify that an issue is a support request please:
>
> The etcd team
3. Finally, click `Convert to discussion` on the righthand panel, selecting the appropriate discussion category.
3. Finally, click `Convert to discussion` on the right-hand panel, selecting the appropriate discussion category.
### Bug reports
If an issue has been raised as a bug it should already have the `type/bug` label, however if this is missing for an issue you determine to be a bug please add the label manually.
If an issue has been raised as a bug it should already have the `type/bug` label, however, if this is missing for an issue you determine to be a bug please add the label manually.
The next step is to validate if the issue is indeed a bug. If not, add a comment with findings and close trivial issue. For non-trivial issue, wait to hear back from issue reporter and see if there is any objection. If issue reporter does not reply in 30 days, close the issue.
The next step is to validate if the issue is indeed a bug. If not, add a comment with the findings and close the trivial issue. For non-trivial issues, wait to hear back from the issue reporter and see if there is any objection. If the issue reporter does not reply in 30 days, close the issue.
If the problem can not be reproduced or requires more information, leave a comment for the issue reporter as soon as possible while the issue will be fresh for the issue reporter.
If the problem can not be reproduced or requires more information, leave a comment for the issue reporter as soon as possible while the issue is fresh for the issue reporter.
### Feature requests
New feature requests should be created via the etcd feature request template and in theory already have the `type/feature` label, however if this is missing for an issue you determine to be a feature please add the label manually.
New feature requests should be created via the etcd feature request template and in theory already have the `type/feature` label, however, if this is missing for an issue you determine to be a feature please add the label manually.
### Test flakes
Test flakes are a specific type of bug that the etcd project tracks separately as these are a priority to address. These should be created via the test flake template and in theory already have the `type/flake` label, however if this is missing for an issue you determine to be related to a flaking test please add the label manually.
Test flakes are a specific type of bug that the etcd project tracks separately as these are a priority to address. These should be created via the test flake template and in theory already have the `type/flake` label, however, if this is missing for an issue you determine to be related to a flaking test please add the label manually.
## Step 4 - Define the areas impacted
@ -121,15 +121,25 @@ Below is a brief summary of the area labels in active use by the etcd project al
| area/auth | |
| area/etcdctl | |
| area/etcdutl | |
| area/contrib | Not to be confused with `area/community` this label is specifically used for issues relating to communitymaintained scripts or files in the `contrib/` directory which aren't part of the core etcd project. |
| area/contrib | Not to be confused with `area/community` this label is specifically used for issues relating to community-maintained scripts or files in the `contrib/` directory which aren't part of the core etcd project. |
| area/documentation | |
| area/tooling | Generally used in relation to the third party / external utilities or tools that are used in various stages of the etcd build, test or release process, for example tooling to create sboms. |
| area/tooling | Generally used in relation to the third party / external utilities or tools that are used in various stages of the etcd build, test, or release process, for example, tooling to create sboms. |
| area/testing | |
| area/robustness-testing | |
## Step 5 - Prioritise the issue
Placeholder.
If an issue lacks a priority label it has not been formally prioritized yet.
Adding a `priority` label helps the etcd project understand what is important and should be worked on now, and conversely, what is not as important and is on the project backlog.
|Priority label|What it means|Examples|
|---|---|---|
| `priority/critical-urgent` | Maintainers are responsible for making sure that these issues (in their area) are being actively worked on—i.e., drop what you're doing. The stuff is burning. These should be fixed before the next release. | user-visible critical bugs in core features <br> broken builds on tier1 supported platforms <br> tests and critical security issues |
| `priority/important-soon` | Must be staffed and worked on either currently or very soon—ideally in time for the next release. | |
| `priority/important-longterm` | Important over the long term, but may not be currently staffed and/or may require multiple releases to complete. | |
| `priority/backlog` | General agreement that this is a nice-to-have, but no one's available to work on it anytime soon. Community contributions would be most welcome in the meantime, though it might take a while to get them reviewed if reviewers are fully occupied with higher-priority issues—for example, immediately before a release.| |
| `priority/awaiting-more-evidence` | Possibly useful, but not yet enough support to actually get it done. | Mostly placeholders for potentially good ideas, so that they don't get completely forgotten, and can be referenced or deduped every time they come up |
## Step 6 - Support new contributors
@ -169,11 +179,11 @@ Once initial triage has been completed, issues need to be re-evaluated over time
### Track important issues
If an issue is at risk of being closed by stale bot in future, but is an important issuefor the etcd project, then please apply the `stage/tracked` label and remove any `stale` labels that exist. This will ensure the project does not lose sight of the issue.
If an issue is at risk of being closed by the stale bot in the future, but is an important issuefor the etcd project, then please apply the `stage/tracked` label and remove any `stale` labels that exist. This will ensure the project does not lose sight of the issue.
### Close incomplete issues
Issues that lack enough information from the issue reporter should be closed if issue reporter do not provide information in 30 days. Issues can always be re-opened at a later date if new information is provided.
Issues that lack enough information from the issue reporter should be closed if the issue reporter does not provide information in 30 days. Issues can always be re-opened at a later date if new information is provided.
The `etcd` PRs are listed at https://github.com/etcd-io/etcd/pulls
A PR can have various labels, milestone, reviewer etc. The detailed list of labels can be found at
A PR can have various labels, milestones, reviewers, etc. The detailed list of labels can be found at
https://github.com/kubernetes/kubernetes/labels
Following are few example searches on PR for convenience:
Following are a few example searches on PR for convenience:
* [Open PRS for milestone etcd-v3.6](https://github.com/etcd-io/etcd/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+milestone%3Aetcd-v3.6)
* [PRs under investigation](https://github.com/etcd-io/etcd/labels/Investigating)
## Scope
These guidelines serves as a primary document for managing PRs in `etcd`. Everyone is welcome to help manage PRs but the work and responsibilities discussed in this document is created with `etcd` maintainers and active contributors in mind.
These guidelines serve as a primary document for managing PRs in `etcd`. Everyone is welcome to help manage PRs but the work and responsibilities discussed in this document are created with `etcd` maintainers and active contributors in mind.
## Ensure tests are run
The etcd project use Kubernetes Prow and GitHub Actions to run tests. To ensure all required tests run if a pull request is ready for testing and still has the `needs-ok-to-test` label then please comment on the pull request `/ok-to-test`.
## Handle inactive PRs
Poke PR owner if review comments are not addressed in 15 days. If PR owner does not reply in 90 days, update the PR with a new commit if possible. If not, inactive PR should be closed after 180 days.
Poke PR owner if review comments are not addressed in 15 days. If the PR owner does not reply in 90 days, update the PR with a new commit if possible. If not, inactive PR should be closed after 180 days.
## Poke reviewer if needed
Reviewers are responsive in a timely fashion, but considering everyone is busy, give them some time after requesting review if quick response is not provided. If response is not provided in 10 days, feel free to contact them via adding a comment in the PR or sending an email or message on the Slack.
Reviewers are responsive in a timely fashion, but considering everyone is busy, give them some time after requesting a review if a quick response is not provided. If the response is not provided in 10 days, feel free to contact them via adding a comment in the PR or sending an email or message on Slack.
"title":"Stream result of etcdserverpbSnapshotResponse"
@ -1386,7 +1386,7 @@
"default":{
"description":"An unexpected error response.",
"schema":{
"$ref":"#/definitions/rpcStatus"
"$ref":"#/definitions/googlerpcStatus"
}
}
},
@ -1419,7 +1419,7 @@
"default":{
"description":"An unexpected error response.",
"schema":{
"$ref":"#/definitions/rpcStatus"
"$ref":"#/definitions/googlerpcStatus"
}
}
},
@ -1452,7 +1452,7 @@
"default":{
"description":"An unexpected error response.",
"schema":{
"$ref":"#/definitions/rpcStatus"
"$ref":"#/definitions/googlerpcStatus"
}
}
},
@ -1485,7 +1485,7 @@
"$ref":"#/definitions/etcdserverpbWatchResponse"
},
"error":{
"$ref":"#/definitions/rpcStatus"
"$ref":"#/definitions/googlerpcStatus"
}
},
"title":"Stream result of etcdserverpbWatchResponse"
@ -1494,7 +1494,7 @@
"default":{
"description":"An unexpected error response.",
"schema":{
"$ref":"#/definitions/rpcStatus"
"$ref":"#/definitions/googlerpcStatus"
}
}
},
@ -2135,6 +2135,19 @@
}
}
},
"etcdserverpbDowngradeInfo":{
"type":"object",
"properties":{
"enabled":{
"type":"boolean",
"description":"enabled indicates whether the cluster is enabled to downgrade."
},
"targetVersion":{
"type":"string",
"description":"targetVersion is the target downgrade version."
}
}
},
"etcdserverpbDowngradeRequest":{
"type":"object",
"properties":{
@ -2689,7 +2702,7 @@
"count":{
"type":"string",
"format":"int64",
"description":"count is set to the number of keys within the range when requested."
"description":"count is set to the actual number of keys within the range when requested.\nUnlike Kvs, it is unaffected by limits and filters (e.g., Min/Max, Create/Modify, Revisions)\nand reflects the full count within the specified range."
}
}
},
@ -2834,7 +2847,16 @@
},
"storageVersion":{
"type":"string",
"description":"storageVersion is the version of the db file. It might be get updated with delay in relationship to the target cluster version."
"description":"storageVersion is the version of the db file. It might be updated with delay in relationship to the target cluster version."
},
"dbSizeQuota":{
"type":"string",
"format":"int64",
"title":"dbSizeQuota is the configured etcd storage quota in bytes (the value passed to etcd instance by flag --quota-backend-bytes)"
},
"downgradeInfo":{
"$ref":"#/definitions/etcdserverpbDowngradeInfo",
"description":"downgradeInfo indicates if there is downgrade process."
}
}
},
@ -2977,7 +2999,7 @@
},
"canceled":{
"type":"boolean",
"description":"canceled is set to true if the response is for a cancel watch request.\nNo further events will be sent to the canceled watcher."
"description":"canceled is set to true if the response is for a cancel watch request\nor if the start_revision has already been compacted.\nNo further events will be sent to the canceled watcher."
The infrastructure to build for arm64 is provided by [Equinix Metal](https://www.equinix.com/) via the [CNCF Community Infrastructure Lab](https://github.com/cncf/cluster/issues).
Previously, several maintainers were responsible for managing two bare-metal machines with a self-hosted runner installed. This was a manual process, and side effects could be left over from previous builds.
As part of a joint program between Ampere and the CNCF, [actuated.dev](https://actuated.dev) is providing managed Arm64 builds.
To use the new infrastructure, add the following to your workflow:
```yaml
runs-on:actuated-arm64-8cpu-8gb
```
The vCPUs and RAM are customizable, i.e. `actuated-arm64-8cpu-16gb` or `actuated-arm64-8cpu-32gb`.
For urgent support, contact @alexellis or the [actuated team](https://actuated.dev).
etcd is a distributed reliable key-value store for the most critical data of a distributed system, with a focus on being:
@ -141,18 +144,21 @@ Now it's time to dig into the full etcd API and other guides.
### Community meetings
etcd contributors and maintainers meet every week at 11:00 AM (USA Pacific) on Thursday and meetings alternate between community meetings and issue triage meetings. An initial agenda will be posted to the [shared Google docs][shared-meeting-notes] a day before each meeting, and everyone is welcome to suggest additional topics or other agendas.
etcd contributors and maintainers meet every week at `11:00` AM (USA Pacific) on Thursday and meetings alternate between community meetings and issue triage meetings. Meeting agendas are recorded in a [shared Google doc][shared-meeting-notes] and everyone is welcome to suggest additional topics or other agendas.
Issue triage meetings are aimed at getting through our backlog of PRs and Issues. Triage meetings are open to any contributor; you don't have to be a reviewer or approver to help out! They can also be a good way to get started contributing.
Meeting recordings are uploaded to official etcd [YouTube channel].
The meeting lead role is rotated for each meeting between etcd maintainers or sig-etcd leads and is recorded in a [shared Google sheet][shared-rotation-sheet].
Get calendar invitation by joining [etcd-dev](https://groups.google.com/g/etcd-dev) mailing group.
Meeting recordings are uploaded to the official etcd [YouTube channel].
// the original implementation ensures the result is non-nil
return[]string{}
}
// use "/dev/null" to discard all
ifslices.Contains(old,"/dev/null"){
return[]string{"/dev/null"}
}
// clone a new one; don't modify the original, in case it matters.
dup:=slices.Clone(old)
slices.Sort(dup)
returnslices.Compact(dup)
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
