Wire weaveutil unique-id into weave script

Also ensure the right host directories are mounted when create-bridge
is called from either the weave script or weave-kube.
This commit is contained in:
Bryan Boreham committed 2017-01-11 13:14:35 +00:00
1 parent ebcb7f6108
commit 7d308a4ac5
4 files changed
+29 -27

No files matched your search

+1 -1
View File
@@ -29,6 +29,7 @@ if [ "${EXPECT_NPC}" = "0" ]; then
WEAVE_NPC_OPTS=""
fi
export HOST_ROOT=/host
/home/weave/weave --local create-bridge --force $WEAVE_NPC_OPTS
# Kubernetes sets HOSTNAME to the host's hostname
@@ -100,7 +101,6 @@ post_start_actions() {
fi
fi
mkdir -p $HOST_ROOT/etc/cni/net.d
export HOST_ROOT
/home/weave/weave --local setup-cni
# Expose the weave network so host processes can communicate with pods
+5
View File
@@ -44,6 +44,8 @@ spec:
mountPath: /host/home
- name: cni-conf
mountPath: /host/etc
- name: dbus
mountPath: /host/var/lib/dbus
resources:
requests:
cpu: 10m
@@ -68,3 +70,6 @@ spec:
- name: cni-conf
hostPath:
path: /etc
- name: dbus
hostPath:
path: /var/lib/dbus
+12 -8
View File
@@ -49,14 +49,18 @@ When the router is launched on a host, it derives its peer name in order of pref
* From the command line, where the user is responsible for uniqueness and
stability
* From the BIOS product UUID, which is generally stable across
restarts and unique across different physical hardware and certain
cloned VMs
* From the hypervisor UUID, which is generally stable across restarts
and unique across VMs which do not provide access to a BIOS product
UUID
* From a random value, practically unique across different physical
hardware and cloned VMs but not stable across restarts
* From Weave's data volume container (`weavedb`), if you upgrade your
Weave Net install from a pre-1.9 version and the underlying machine
IDs still match.
* From a unique machine ID. This is generated by combining IDs from
[systemd](https://www.freedesktop.org/software/systemd/man/machine-id.html)
or [D-Bus](https://dbus.freedesktop.org/doc/dbus-uuidgen.1.html)
with the BIOS product UUID or hypervisor UUID. Most machines have
one or two of these IDs, and the combination is practically stable
across restarts unless a user re-generates it.
* If none of the machine IDs are found, a random value is generated.
This is practically unique across different physical hardware and
cloned VMs but not stable across restarts.
The appropriate strategy for assigning peer names depends on the type
and method of your particular deployment and is discussed in more
+11 -18
View File
@@ -140,6 +140,11 @@ exec_options() {
setup|setup-cni|launch|launch-router)
echo -v /:/host -e HOST_ROOT=/host
;;
# All the other commands that may create the bridge and need machine id files.
# We don't mount '/' to avoid recursive mounts of '/var'
create-bridge|attach-router|run|start|attach|restart|expose|hide)
echo -v /etc:/host/etc -v /var/lib/dbus:/host/var/lib/dbus -e HOST_ROOT=/host
;;
esac
}
@@ -466,14 +471,6 @@ mac_from_hex() {
read a b c d e f && printf "%02x:$b:$c:$d:$e:$f" $((0x$a & ~1 | 2))
}
mac_from_file() {
UUID=$(cat $1 2>/dev/null) || return 1
# We salt the input just as a precaution to avoid clashes with
# other applications who might have had the bright idea of
# generating MACs in the same way.
echo "9oBJ0Jmip-$UUID" | sha256sum | sed 's/\(..\)/\1 /g' | cut -c1-17 | mac_from_hex
}
# Generate a random MAC value
random_mac() {
od -txC -An -N6 /dev/urandom | mac_from_hex
@@ -721,16 +718,12 @@ init_bridge_prep() {
ip link add name $BRIDGE type bridge
# Derive the bridge MAC from the system (aka bios) UUID, or,
# failing that, the hypervisor UUID. Elsewhere we in turn derive
# the peer name from that, which we want to be stable across
# reboots but otherwise unique. The system/hypervisor UUID fits
# that bill, unlike, say, /etc/machine-id, which is often
# identical on VMs created from cloned filesystems. If we cannot
# determine the system/hypervisor UUID we just generate a random MAC.
MAC=$(mac_from_file /sys/class/dmi/id/product_uuid) || \
MAC=$(mac_from_file /sys/hypervisor/uuid) || \
MAC=$(random_mac)
# for Docker 1.12 this needs to be docker inspect -f '{{with index .Mounts 0}}{{.Source}}{{end}}'
# so running this from 'weave --local' may fail.
# also if weaveexec is not on the path it will be run as a Docker container
# that does not have access to /etc/machine-id
WEAVEDB_PATH=$(docker inspect -f '{{index .Volumes "/weavedb"}}' $DB_CONTAINER_NAME 2>/dev/null)
MAC=$(util_op unique-id "$HOST_ROOT/$WEAVEDB_PATH/weave" "$HOST_ROOT")
ip link set dev $BRIDGE address $MAC