This still fails, but differently now. On a current and clean F-29, with etcd-3.2.16-6.fc29.x86_64:

# systemctl status -l etcd
● etcd.service - Etcd Server
   Loaded: loaded (/usr/lib/systemd/system/etcd.service; disabled; vendor preset: disabled)
   Active: active (running) since Tue 2019-04-16 02:18:20 EDT; 35s ago
 Main PID: 7797 (etcd)
    Tasks: 9 (limit: 1147)
   Memory: 35.6M
      CPU: 226ms
   CGroup: /system.slice/etcd.service
           └─7797 /usr/bin/etcd --name=default --data-dir=/var/lib/etcd/default.etcd --listen-client-urls=http://localhost:2379

Apr 16 02:18:20 m1.cockpit.lan etcd[7797]: 8e9e05c52164694d received MsgVoteResp from 8e9e05c52164694d at term 2
Apr 16 02:18:20 m1.cockpit.lan etcd[7797]: 8e9e05c52164694d became leader at term 2
Apr 16 02:18:20 m1.cockpit.lan etcd[7797]: raft.node: 8e9e05c52164694d elected leader 8e9e05c52164694d at term 2
Apr 16 02:18:20 m1.cockpit.lan etcd[7797]: setting up the initial cluster version to 3.2
Apr 16 02:18:20 m1.cockpit.lan etcd[7797]: published {Name:default ClientURLs:[http://localhost:2379]} to cluster cdf818194e3a8c32
Apr 16 02:18:20 m1.cockpit.lan systemd[1]: Started Etcd Server.
Apr 16 02:18:20 m1.cockpit.lan etcd[7797]: ready to serve client requests
Apr 16 02:18:20 m1.cockpit.lan etcd[7797]: serving insecure client requests on 127.0.0.1:2379, this is strongly discouraged!
Apr 16 02:18:20 m1.cockpit.lan etcd[7797]: set the initial cluster version to 3.2
Apr 16 02:18:20 m1.cockpit.lan etcd[7797]: enabled capabilities for version 3.2

Somehow dnf upgrade --enablerepo=updates-testing etcd and dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2019-049b108f40 say "nothing to do", so it seems this isn't yet published. However, I downloaded the build manually with koji download-build, and it fails again:

# systemctl status -l etcd
● etcd.service - Etcd Server
   Loaded: loaded (/usr/lib/systemd/system/etcd.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2019-04-16 02:25:42 EDT; 2min 33s ago
  Process: 23291 ExecStart=/bin/bash -c GOMAXPROCS=$(nproc) /usr/bin/etcd --name="${ETCD_NAME}" --data-dir="${ETCD_DATA_DIR}" --listen-client-urls="${ETCD_LISTEN_>
 Main PID: 23291 (code=exited, status=1/FAILURE)
      CPU: 16ms

Apr 16 02:25:42 m1.cockpit.lan systemd[1]: Starting Etcd Server...
Apr 16 02:25:42 m1.cockpit.lan etcd[23291]: recognized and used environment variable ETCD_ADVERTISE_CLIENT_URLS=http://localhost:2379
Apr 16 02:25:42 m1.cockpit.lan etcd[23291]: conflicting environment variable "ETCD_LISTEN_CLIENT_URLS" is shadowed by corresponding command-line flag (either unset environment variable or disable flag)
Apr 16 02:25:42 m1.cockpit.lan systemd[1]: etcd.service: Main process exited, code=exited, status=1/FAILURE
Apr 16 02:25:42 m1.cockpit.lan systemd[1]: etcd.service: Failed with result 'exit-code'.
Apr 16 02:25:42 m1.cockpit.lan systemd[1]: Failed to start Etcd Server.

Exactly the same failure as in the previous update:

Apr 15 05:13:18 localhost.localdomain bash[4139]: /usr/bin/etcd: line 1: syntax error near unexpected token `newline'
Apr 15 05:13:18 localhost.localdomain bash[4139]: /usr/bin/etcd: line 1: `!<arch>'

full journal, pull request that exhibits this

In cockpit we regularly build a Fedora (29 currently) with updates-testing enabled: Last run today: https://github.com/cockpit-project/cockpit/pull/11572 This shows that this breaks kubernetes. The journal says this:

Apr 12 11:20:31 localhost.localdomain systemd[1]: Starting Etcd Server...
Apr 12 11:20:31 localhost.localdomain bash[5877]: /usr/bin/etcd: line 1: syntax error near unexpected token `newline'
Apr 12 11:20:31 localhost.localdomain bash[5877]: /usr/bin/etcd: line 1: `!<arch>'
Apr 12 11:20:31 localhost.localdomain audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=etcd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Apr 12 11:20:31 localhost.localdomain systemd[1]: etcd.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Apr 12 11:20:31 localhost.localdomain systemd[1]: etcd.service: Failed with result 'exit-code'.

I haven't reproduced this yet, but as this is dangerously close to slipping into stable, I want to raise a red flag here.