Skip to content

Latest commit

 

History

History
394 lines (306 loc) · 37.9 KB

CHANGELOG-3.3.md

File metadata and controls

394 lines (306 loc) · 37.9 KB
Raw

Previous change logs can be found at CHANGELOG-3.2.

v3.3.4 (2018-04-24)

See code changes and v3.3 upgrade guide for any breaking changes. Again, before running upgrades from any previous release, please make sure to read change logs below and v3.3 upgrade guide.

Metrics, Monitoring

Security, Authentication

  • Fix TLS reload when certificate SAN field only includes IP addresses but no domain names.
    • In Go, server calls (*tls.Config).GetCertificate for TLS reload if and only if server's (*tls.Config).Certificates field is not empty, or (*tls.ClientHelloInfo).ServerName is not empty with a valid SNI from the client. Previously, etcd always populates (*tls.Config).Certificates on the initial client TLS handshake, as non-empty. Thus, client was always expected to supply a matching SNI in order to pass the TLS verification and to trigger (*tls.Config).GetCertificate to reload TLS assets.
    • However, a certificate whose SAN field does not include any domain names but only IP addresses would request *tls.ClientHelloInfo with an empty ServerName field, thus failing to trigger the TLS reload on initial TLS handshake; this becomes a problem when expired certificates need to be replaced online.
    • Now, (*tls.Config).Certificates is created empty on initial TLS client handshake, first to trigger (*tls.Config).GetCertificate, and then to populate rest of the certificates on every new TLS connection, even when client SNI is empty (e.g. cert only includes IPs).

etcd

  • Add --initial-election-tick-advance flag to configure initial election tick fast-forward.
    • By default, --initial-election-tick-advance=true, then local member fast-forwards election ticks to speed up "initial" leader election trigger.
    • This benefits the case of larger election ticks. For instance, cross datacenter deployment may require longer election timeout of 10-second. If true, local node does not need wait up to 10-second. Instead, forwards its election ticks to 8-second, and have only 2-second left before leader election.
    • Major assumptions are that: cluster has no active leader thus advancing ticks enables faster leader election. Or cluster already has an established leader, and rejoining follower is likely to receive heartbeats from the leader after tick advance and before election timeout.
    • However, when network from leader to rejoining follower is congested, and the follower does not receive leader heartbeat within left election ticks, disruptive election has to happen thus affecting cluster availabilities.
    • Now, this can be disabled by setting --initial-election-tick-advance=false.
    • Disabling this would slow down initial bootstrap process for cross datacenter deployments. Make tradeoffs by configuring --initial-election-tick-advance at the cost of slow initial bootstrap.
    • If single-node, it advances ticks regardless.
    • Address disruptive rejoining follower node.

Package embed

  • Add embed.Config.InitialElectionTickAdvance to enable/disable initial election tick fast-forward.
    • embed.NewConfig() would return *embed.Config with InitialElectionTickAdvance as true by default.

Go

v3.3.3 (2018-03-29)

See code changes and v3.3 upgrade guide for any breaking changes. Again, before running upgrades from any previous release, please make sure to read change logs below and v3.3 upgrade guide.

Improved

  • Adjust election timeout on server restart to reduce disruptive rejoining servers.
    • Previously, etcd fast-forwards election ticks on server start, with only one tick left for leader election. This is to speed up start phase, without having to wait until all election ticks elapse. Advancing election ticks is useful for cross datacenter deployments with larger election timeouts. However, it was affecting cluster availability if the last tick elapses before leader contacts the restarted node.
    • Now, when etcd restarts, it adjusts election ticks with more than one tick left, thus more time for leader to prevent disruptive restart.
  • Adjust periodic compaction retention window.
    • e.g. --auto-compaction-mode=revision --auto-compaction-retention=1000 automatically Compact on "latest revision" - 1000 every 5-minute (when latest revision is 30000, compact on revision 29000).
    • e.g. Previously, --auto-compaction-mode=periodic --auto-compaction-retention=72h automatically Compact with 72-hour retention windown for every 7.2-hour. Now, Compact happens, for every 1-hour but still with 72-hour retention window.
    • e.g. Previously, --auto-compaction-mode=periodic --auto-compaction-retention=30m automatically Compact with 30-minute retention windown for every 3-minute. Now, Compact happens, for every 30-minute but still with 30-minute retention window.
    • Periodic compactor keeps recording latest revisions for every compaction period when given period is less than 1-hour, or for every 1-hour when given compaction period is greater than 1-hour (e.g. 1-hour when --auto-compaction-mode=periodic --auto-compaction-retention=24h).
    • For every compaction period or 1-hour, compactor uses the last revision that was fetched before compaction period, to discard historical data.
    • The retention window of compaction period moves for every given compaction period or hour.
    • For instance, when hourly writes are 100 and --auto-compaction-mode=periodic --auto-compaction-retention=24h, v3.2.x, v3.3.0, v3.3.1, and v3.3.2 compact revision 2400, 2640, and 2880 for every 2.4-hour, while v3.3.3 or later compacts revision 2400, 2500, 2600 for every 1-hour.
    • Futhermore, when --auto-compaction-mode=periodic --auto-compaction-retention=30m and writes per minute are about 1000, v3.3.0, v3.3.1, and v3.3.2 compact revision 30000, 33000, and 36000, for every 3-minute, while v3.3.3 or later compacts revision 30000, 60000, and 90000, for every 30-minute.

Metrics, Monitoring

Go

v3.3.2 (2018-03-08)

See code changes and v3.3 upgrade guide for any breaking changes. Again, before running upgrades from any previous release, please make sure to read change logs below and v3.3 upgrade guide.

Fixed: v3

Fixed: v2

Go

v3.3.1 (2018-02-12)

See code changes and v3.3 upgrade guide for any breaking changes. Again, before running upgrades from any previous release, please make sure to read change logs below and v3.3 upgrade guide.

Improved

Fixed: v3

Go

v3.3.0 (2018-02-01)

See code changes and v3.3 upgrade guide for any breaking changes. Again, before running upgrades from any previous release, please make sure to read change logs below and v3.3 upgrade guide.

Improved

Breaking Changes

  • Require google.golang.org/grpc v1.7.4 or v1.7.5.
  • Translate gRPC status error in v3 client Snapshot API.
  • v3 etcdctl lease timetolive LEASE_ID on expired lease now prints "lease LEASE_ID already expired".
    • <=3.2 prints "lease LEASE_ID granted with TTL(0s), remaining(-1s)".
  • Replace gRPC gateway endpoint /v3alpha with /v3beta.
    • To deprecate /v3alpha in v3.4.
    • In v3.3, curl -L http://localhost:2379/v3alpha/kv/put -X POST -d '{"key": "Zm9v", "value": "YmFy"}' still works as a fallback to curl -L http://localhost:2379/v3beta/kv/put -X POST -d '{"key": "Zm9v", "value": "YmFy"}', but curl -L http://localhost:2379/v3alpha/kv/put -X POST -d '{"key": "Zm9v", "value": "YmFy"}' won't work in v3.4. Use curl -L http://localhost:2379/v3beta/kv/put -X POST -d '{"key": "Zm9v", "value": "YmFy"}' instead.
  • Change --auto-compaction-retention flag to accept string values with finer granularity.
    • Now that --auto-compaction-retention accepts string values, etcd configuration YAML file auto-compaction-retention field must be changed to string type.
    • Previously, --config-file etcd.config.yaml can have auto-compaction-retention: 24 field, now must be auto-compaction-retention: "24" or auto-compaction-retention: "24h".
    • If configured as --auto-compaction-mode periodic --auto-compaction-retention "24h", the time duration value for --auto-compaction-retention flag must be valid for time.ParseDuration function in Go.

Dependency

Metrics, Monitoring

Security, Authentication

See security doc for more details.

etcd

API

clientv3

Fixed: clientv3

v3 etcdctl

Fixed: v3 etcdctl

v2 etcdctl

grpc-proxy

Fixed: grpc-proxy

gRPC gateway

  • Replace gRPC gateway endpoint /v3alpha with /v3beta.
    • To deprecate /v3alpha in v3.4.
    • In v3.3, curl -L http://localhost:2379/v3alpha/kv/put -X POST -d '{"key": "Zm9v", "value": "YmFy"}' still works as a fallback to curl -L http://localhost:2379/v3beta/kv/put -X POST -d '{"key": "Zm9v", "value": "YmFy"}', but curl -L http://localhost:2379/v3alpha/kv/put -X POST -d '{"key": "Zm9v", "value": "YmFy"}' won't work in v3.4. Use curl -L http://localhost:2379/v3beta/kv/put -X POST -d '{"key": "Zm9v", "value": "YmFy"}' instead.
  • Support "authorization" token.
  • Support websocket for bi-directional streams.
  • Upgrade gRPC gateway to v1.3.0.

Fixed: v3

Fixed: v2

Package raft

Other

Go