vendor: bump etcd v3.3.27

[kolyshkin]

fixes #31182

Bump etcd to v3.3.27, which includes etcd-io/etcd#12552,
to fix #31182

Full diff: etcd-io/etcd@v3.3.25...v3.3.27

This is a draft, pending a 3.3.26 release (etcd-io/etcd#12698)

[joakim-tjernlund]

Ping?

[thaJeztah]

I think we're waiting for the etcd maintainers to tag a new release; etcd-io/etcd#12552 (comment)

[kolyshkin]

Updated to use the upstream repo as the PR is merged. No changes other than the line in vendor.conf (and a rebase)

[joakim-tjernlund]

CI still broken?

[thaJeztah]

Looks like it adds two new dependencies (that are currently not vendored), which looks to cause the CI failure

[kolyshkin]

fixed

[kolyshkin]

Depending on how long it will take etcd-io/etcd#12698 to be fixed, maybe we should merge this as is.

[thaJeztah]

Depending on how long it will take etcd-io/etcd#12698 to be fixed, maybe we should merge this as is

It was previously a CoreOS project; do you know if the maintainers are now at Red Hat? (if so, do you have some internal cages to rattle? 😇 😅).

[joakim-tjernlund]

This is not moving forward ...

[joakim-tjernlund]

Guys, this is a really old bug, was fixed many months ago. It also reflects badly on docker/moby as this bug makes life miserably for OTHER apps but docker and you don't care.
Please make sure to merge it into maintenance branches as well.

[thaJeztah]

@joakim-tjernlund not helpful; might want to complain in the upstream etcd project instead

[kolyshkin]

I think this can be merged as is now since

• it fixes a real bug;
• cut 3.3.26 release etcd-io/etcd#12698 (tag a release) is not moving forward;
• this no longer uses my fork of etcd, but upstream repo.

and the only downside is it's using non-tagged version of etcd

[kolyshkin]

Backport to 20.10 should also be trivial (once this is merged).

[joakim-tjernlund]

@joakim-tjernlund not helpful; might want to complain in the upstream etcd project instead

I have complained to etcd, nothing happens.
You can only wait so long for upstream. You are bundling this pkg so it becomes your problem in the end.

[joakim-tjernlund]

Backport to 20.10 should also be trivial (once this is merged).

What etcd does 20.10.x use? 19.x is getting old and soon obsolete so 20.10 is the way forward.

[joakim-tjernlund]

Yet a release but without this fix ...

[joakim-tjernlund]

If you move to the etcd 3.4 branch you will get the fix ...
3.3 is apparently dead since long .

[joakim-tjernlund]

3.3.27 has been out for quite a while now ...

[thaJeztah]

Rebased and moved to v3.3.27

[kolyshkin]

LGTM (I'm the author so I can't technically LGTM it)

[kolyshkin]

I guess this needs to be backported as well.

[tianon]

LGTM; the test failure seems like a teardown race, not necessarily related?

[thaJeztah]

LGTM (although the last push was from me 😂)

[thaJeztah]

I guess this needs to be backported as well.

I added the cherry-pick label, but it may need 2bef937 to be cherry-picked as well, which brings updated dependencies, so a rather large diff (perhaps we're able to reduce the diff)

[thaJeztah]

I re-ran CI a couple of times to make sure the vendor check also passed, but it's a bit of a whack-a-mole with flaky tests in different Jenkins stages.

The remaining failure in the last run is TestFollowLogsHandleDecodeErr, which is known flaky, which will be addressed by #43105 once merged;

 === Failed
 === FAIL: daemon/logger/loggerutils TestFollowLogsHandleDecodeErr (0.01s)
 time="2022-01-04T23:38:45Z" level=error msg="Log reader notified that it must re-open log file, some log data may not be streamed to the client." file=/tmp/TestFollowLogsHandleDecodeErr497049835
     logfile_test.go:317: assertion failed: 5 (int) != 6 (dec.resetCount int)

I'll go ahead and bring this one in

[joakim-tjernlund]

I guess this needs to be backported as well.

Did this get backported ?