app-admin/locksmith: bump commit ID

[tormath1]

closes flatcar/Flatcar#407

Signed-off-by: Mathieu Tortuyaux mathieu@kinvolk.io

This commit pulls the latest flatcar-master of locksmith - it includes the following PR:

• locksmithcl: reset endpoints when we set a new one flatcar/locksmith#13
• locksmithctl/locksmithcl: fix endpoints resilience flatcar/locksmith#11
• locksmithd will not reboot outside of reboot windows, if no semaphore was acquired before flatcar/locksmith#10
• Doc: Update the IRC link from freenode to libera flatcar/locksmith#9
• Update github.com/godbus/dbus and github.com/coreos/go-systemd flatcar/locksmith#8
• update go mod deps flatcar/locksmith#6
• README.md: update flatcar repo URL flatcar/locksmith#7
• A number of CoreOS -> Flatcar updates flatcar/locksmith#5

Testing done

• CI (:large_blue_circle: except for kubeadm.* on QEMU but not related) : http://jenkins.infra.kinvolk.io:8080/job/os/job/manifest/3393/cldsv/

[tormath1]

getting random failure on the etcd client when the endpoint is not explicit - not sure why but it might be related to the etcd upgrade maybe:

core@localhost ~ $ for i in {1..10}; do locksmithctl status && sleep 1; done
Error initializing etcd client: dial tcp 127.0.0.1:4001: connect: connection refused
Available: 1
Max: 1
Available: 1
Max: 1
Available: 1
Max: 1
Error initializing etcd client: dial tcp 127.0.0.1:4001: connect: connection refused
Available: 1
Max: 1
Available: 1
Max: 1
Available: 1
Max: 1
Error initializing etcd client: dial tcp 127.0.0.1:4001: connect: connection refused
Error initializing etcd client: dial tcp 127.0.0.1:4001: connect: connection refused
core@localhost ~ $ for i in {1..10}; do locksmithctl -endpoint http://localhost:2379 status && sleep 1; done
Available: 1
Max: 1
Available: 1
Max: 1
Available: 1
Max: 1
Available: 1
Max: 1
Available: 1
Max: 1
Available: 1
Max: 1
Available: 1
Max: 1
Available: 1
Max: 1
Available: 1
Max: 1
Available: 1
Max: 1

[jepio]

The default endpoints list is [localhost:2379,localhost:4001]. Looking at the code it seems to that "go.etcd.io/etcd/client" shuffles the passed in endpoints. But the comments say that if one is unreachable it will try another one, which is not happening correctly.

[tormath1]

yeah I arrived to the very same conclusion - it's very weird, I'll try tomorrow to revert / upgrade the etcd lib to see if it changes something.

Reverting flatcar/locksmith@1b5eb50 fixes the issue; this PR seems to be the cause of the trouble: etcd-io/etcd#5888 but it seems it has been resolved in etcd-io/etcd#8515.

The issue is the following: when we create the etcd client, we call the getClient which initialize a lock etcd client. In the init, it calls a Create (a Set) methods which provides the isOneShotCtxValue -> if there is an error, the action won't be retry. So basically we don't have anymore the endpoints resilience - we could update the tests to run on a specific endpoint but it keeps the main issue: user with multiple endpoints can experiencing this kind of issue.

[tormath1]

This PR is currently on-hold because locksmithctl behaves not correctly due to the etcd upgrade.

We are currently exploring various fixes, like a custom patch (flatcar/locksmith#11) or upgrade to etcd/v3 (flatcar/locksmith#12).

EDIT: we merged the following patch flatcar/locksmith#11 in order to properly make the upgrade to etcd/v3; this PR is no more on-hold.