We cannot just leave that to the `-port` parameter since that only
controls the container internal port weave is listening on (and uses
as the default destination port for outbound connections). Also, we
need the port for connection tracking cleanup during `stop` and
`reset`.
So we make setting `WEAVE_PORT` the only documented mechanism for
overriding the port, and let `-port` set the container internal port
only (and the script pays attentiont to that, so it can establish the
correct port mapping).
This is to make a visible break with previous releases, such that a
newly downloaded weave script will definitely work.
Without this change in name, an existing weavetools image that doesn't
include the script might be invoked, resulting in a confusing message
for the user.
In fact, remove the mention of the exported images being in the container
altogether. The images are in the host docker daemon, so it is easier to
export them again than to go fishing around with 'docker cp'.
I'm not sure about using the name 'zettio/weave-build' for the image
here. There's no intent to upload it to dockerhub, so including the
user name 'zettio' seems wrong. On the other hand, I'm not sure what
the meaning of an unslashed image name is supposed to be. Probably it
doesn't matter what a private non-pushed image is called, as long as
it doesn't clash with something.
Topology gossip can be received on a connection before that connection
has been marked as 'established'. If we do not include unestablished
connections in topology gossip, then parts of the topology can be
removed by gc, since they are deemed unreachable, which can cause
subsequent incremental topology gossips to be rejected due to them
containing references to peers that have been removed by the gc.
Including unestablished connections in topology gossip requires:
- removing the check for 'established' connections in the encoding of
peers for topology gossip,
- adding the 'established' flag to the internal representation of
remote connections,
- adding the 'established' flag to to encoding of connections in
topology gossip,
- treating the *addition* of a connection as an update to the local
peer.
The latter entails
- bumping the peer version on connection addition (as well as on
marking 'established' as previously),
- bumping the peer version *unconditionally* on connection deletion
(rather than only when the connection was 'established', as
previously),
- moving the initial sending of complete topology on the connection,
and the broadcasting of a topology update containing the two peers
at the ends of the connection, from the connection 'established'
logic to the connection addition logic,
- broadcasting just an topology update for the local peer when a
connection gets marked as 'established',
- broadcasting a topology update for the local peer *unconditionally*
when a connection is removed (rather than only doing this when the
connection was 'established', as previously).
When an update contains an older version of a peer we know about,
there is no point in including our better version in the "improved"
update, since we will have told our neighbours about that already and
any race conditions are taken care off by the periodic sending of the
complete topology.
Matthias Radestock