Weave 1.1.2

This release contains a small number of bug fixes. More details in the
change log.

The release is fully compatible with 1.1.0 versions, so existing
clusters can be upgraded incrementally. When upgrading from 1.0.x,
note the compatibility information in the
Installation & Upgrading instructions for Weave 1.1.0.

bug fixes

• large multicast packets get dropped - we now lock the MTU on the multicast route to prevent Linux setting the DF flag #1507
• weave proxy unexpectedly closes the connection after /start request - this was a regression introduced in 1.1.1 #1514
• weaveproxy would give a strange response if you tried to inspect an unknown container #1523
• log message "dropping too big DF broadcast frame" has source and destination IP swapped #1507

testing

• smoke-test setup script needed updating for Go 1.5 (note this release is built with Go 1.4.2) #1543
• one smoke-test hardcoded the docker bridge IP, which changes in Docker 1.9 #1540

Weave 1.1.1

This release contains a number of bug fixes and minor enhancements. More details below and in the change log.

Follow the installation instructions to install this latest release of Weave. The release is fully compatible with 1.1.0 versions, so existing clusters can be upgraded
incrementally. When upgrading from 1.0.x, note the compatibility information in the Installation & Upgrading instructions for Weave 1.1.0.

bug fixes

• on kernel versions < 3.18, starting the proxy would prevent the
  weave network interfaces of existing containers from being
  fully removed when they terminated. This could cause traffic for
  subsequently started containers with the same IP to be
  mis-routed to these stale interfaces. #1455/#1476
• on kernel versions >= 4.2, weave reset could leave containers with dangling weave
  network interfaces. #1364/#1504
• cancellation of simultaneous IP allocation requests could crash
  weave. #1424/#1429
• cancelling a docker run against the proxy could result in a
  spurious "invalid CIDR address: Allocate" error
  message. #1418/#1425/#1426
• when dynamically attaching a container to additional subnets,
  visibility of the container in those subnets could be
  delayed. #1405/#1409/#1411
• the weave version had a stray v prefix in a few
  places. #1397/#1431
• weave launch-proxy would mis-report an already running
  proxy. #1413
• the error message about disabled IP address allocation had a
  typo. #1427
• the weave stop advice regarding weave env --restore had a
  typo. #1408
• a recent docker-machine change broke the weave build. #1466/1467
• one of the DNS tests had a data race. #1480/#1487

minor enhancements

• sanity check the size of gossip messages in order to help track down
  memory allocation errors seen in the wild. #1484/#1485
• link to release notes from "Weave latest" release. #1399
• update build & test VMs to Docker 1.8. #1428/#1435, #1433/#1454
• disable a spuriously failing test until we fix it. #1486
• simplify IP address allocation code in weave script. #1460

Weave v1.1.0

Highlights

• weave launch now launches all weave components, simplifying
  startup.
• weave status has been completely revamped, with a much improved
  presentation of the information, and the option to select and output
  data in JSON.
• weaveDNS has been rewritten and embedded in the router. The new
  implementation simplifies configuration, improves performance, and
  provides fault resilience for services.
• the weave Docker API proxy now provides an even more seamless user
  experience, and enables easier integration of weave with other
  systems such as kubernetes.
• many usability improvements
• a few minor bug fixes, including a couple of security
  vulnerabilities

More details below and in the change log.

Installation & Upgrading

Follow the installation instructions to install this latest release of weave.

If upgrading from weave 1.0.x, note that a cluster can be upgraded incrementally, with some caveats:

• Any installation using weaveDNS will experience a rolling partition
  of name resolution functionality, i.e. containers only see names
  belonging to containers on weave peers with the same version.

• weave launch now launches all weave components, including
  weaveDNS and the proxy.
  For weaveDNS, if the existing installation was

  • launching weaveDNS without any options, then no action is
    required, since the weave launch-dns and weave stop-dns
    commands still exist but are no-ops,
  • launching weaveDNS with options, then these need to be moved to
    the weave launch invocation,
  • not launching weaveDNS, then you may want to disable it with the
    --no-dns option to weave launch, though generally this should
    not be necessary.

  For the proxy, if the existing installation was

  • launching the proxy without any options, then remove the weave launch-proxy invocation and instead just invoke weave launch
  • launching the proxy with options, then you need to launch the router and proxy separately, supplying the proxy options to the latter, i.e. weave launch-router && weave launch-proxy <options>,
  • not launching the proxy, then you may want to only launch the router (and embedded weaveDNS) with weave launch-router, though typically running weave launch instead is fine, since launching the proxy is harmless.

• The default IP address allocation range has changed from
  10.128.0.0/10 to 10.32.0.0/12. If you are using weave's IP
  address allocator, and are not explicitly specifying a range (with
  -iprange), then you need to force weave
  to use the old range by specifying --ipalloc-range=10.128.0.0/10.

• weave proxy-env|proxy-config are deprecated in favour of weave env|config. The former still work but will display a deprecation
  warning when invoked, so you should update any scripts to use the
  new commands.

• The proxy now listens on a unix domain socket instead of TCP/IP if that is how the launching environment connects to the Docker daemon. This is reflected in weave env|config, so any local code/scripts using those to configure their connection to the proxy should be unaffected. However, if you have code/scripts that have the proxy's TCP/IP endpoint hard-coded, then you may need to force the proxy to listen on the TCP/IP, as it did previously, by launching it with weave launch-proxy -H tcp://0.0.0.0:12375. Note that this potentially opens a security vulnerability, which is why it is no longer the default behaviour. Consider a) switching to unix domain sockets, if you are connecting to the proxy locally, b) restricting the network interfaces/IP addresses by supplying something other than 0.0.0.0, or c) switching to TLS.

• weaveDNS has far fewer options than previously. The removed options do not make sense in the new implementation and are unlikely to have been used in many installations, but if they were, simply removing them should be safe in most setups.

• A number of options have been renamed. The old names still work but
  you should update any scripts to use the new ones.

Changes

Command Line Interface

• make weave launch launch the router, weaveDNS and the proxy. As a
  result weave startup is simpler than
  ever. In
  situations where special configuration of the proxy is required, the
  router and proxy can be launched separately with weave launch-router and weave launch-proxy. #382/#962/#1009/#1011/#1012, #1043/#1072
• completely revamp weave status.
  The main command now shows a much more concise and readable summary,
  which, for example, makes it easier to spot connectivity
  issues. Sub-commands provide additional information, which is better
  presented and more informative than was previously the case. And
  weave report produces a status report in JSON format, with the
  ability to select specific pieces of information with a
  template. #1025/#1141/#1027/#908/#1248, #1315, #1328/#1335, #1185/#1283
• improve consistency in command line option naming. Long options
  start with two hyphens, the --<option>= notation is supported, and
  multi-word options are hyphenated. Also, all DNS options now start
  with --dns-. All old option names have been retained for backward
  compatibility; their usage results in a deprecation warning in the
  logs. #602/#1084, #1087/#1096
• log a more helpful error when an invalid flag is specified in weave launch. #1321/#1324
• output weave usage message on stderr instead stdout, thus preventing
  odd behaviour for the likes of eval $(weave env) when the command
  is mistyped. #1082/#1092
• add --init-peer-count to usage output, from which it was
  missing. #1041/#1045.
• make weave --help|help work even when we cannot communicate with
  Docker. #1322/#1325
• reduce start-up time of weave launch. #992/#993
• introduce --log-level option for better control over log
  levels. #329/#1057
• improve Docker version compatibility checking, preventing misleading
  error messages. #576/#1297/#1298/#1326
• improve download times by re-arranging the layers of the weavexec
  image. #1170

Docker API proxy

• enable listening on a unix domain socket, and do so automatically if
  the launching environment connects to the Docker daemon that way. This
  simplifies configuration and also prevents weakening of Docker access security. #1003/#1026, #1055/#1099
• rename --no-default-ipam option to --no-default-ipalloc. The
  former still works but will log a deprecation warning. #1040/#1048
• remove -D option since it wasn't doing anything useful. #972/#978
• replace weave proxy-env|proxy-config with weave env|config. The former still work but will display a deprecation
  warning when invoked. #1014/#1080/#1081
• introduce weave env --restore,
  which restores the environment modified with weave env. This would
  typically be invoked just prior to weave stop|reset. #1288/#1327
• introduce rewriting of /etc/hosts so that hostname -i returns the weave IP
  instead of Docker IP. hostname -i, and its equivalent system call,
  is invoked by some clustered applications like cassandra and consul;
  this change gets them to operate over the weave
  network by default. The feature can be disabled with the
  --no-rewrite-hosts proxy
  option. #68/#1079, #1252/#1265, #1373/#1375
• add --rewrite-inspect
  flag to
  make docker inspect return the weave network settings (such as the
  container's weave IP address) instead of the Docker settings. This
  is useful for integration of weave with systems such as kubernetes
  that depend on the docker inspect output. #117/#212/#1199/#1222/#1376, #1390/#1391
• attach containers to the weave network by default unless they were started with
  --net=host or --net=container:.... In particular, containers
  started with --net=none now get attached. #1302/#1303
• permit (the equivalent of) --net=container:(another container with weave networking) to be specified at container start
  time. Previously this would hang. Note that specifying a network
  mode that way is a backward compatibility feature of the Docker
  Remote API; normally the mode is set during container creation. So
  this did not affect the Docker CLI and most other systems, but did
  cause problems when integrating weave with Kubernetes. #1258/#1314
• handle chunked responses correctly. Failure to do so was causing
  errors when some Docker API clients, though not the Docker CLI, were
  pointed at the proxy. #1103/#1110/#1112, #1257/#1259
• do not disable restart policies, or stomp on the --volume-driver
  option, of containers started via the proxy. #1209/#1314, #1378
• eliminate a very rare race condition that could cause container
  start to hang. #1300/#1314
• improve logging of errors and warnings. #1056/#1067, #1310

Router

• prevent repeated connection attempts from peers to themselves, which
  could result in a lot of log noise and some performance
  degradation. #1305/#1318
• weave attach|detach
  and weave expose|hide
  now output the IP addresses involved. #954/#968
• eliminate a...

Weave 1.0.3

This release contains minor fixes for improved stability and robustness in addition to a bug fix to weaveDNS.

More details below and in the change log.

Follow the installation instructions to install this latest release of Weave. The release is fully compatible with other 1.0.x versions, so existing clusters can be upgraded
incrementally.

• weaveDNS now exposes a TCP listener as well as UDP to support large answers. #1333/#1319
• Compatibility with upstream changes to docker-py. #1366/#1367
• Improved router/IPAM stability. #1329/#1330
• Improved weave reset handling of error conditions. #1356/#1365
• Don't allocated oversized buffers. #1340
• Improved IPAM fuzz test robustness. #1336/#1342

Weave 1.0.2

This release fixes a number of bugs, including some security vulnerabilities in the Weave Docker API proxy, hangs and failures in address allocation, and sporadic failures in name resolution.

More details below and in the change log.

Follow the installation instructions to install this latest release of Weave. The release is fully compatible with other 1.0.x versions, so existing clusters can be upgraded incrementally.

Docker API proxy

• Application containers had access to portions of the host's
  filesystem, and had part of their own filesystem shadowed. The
  former allowed apps to access to and modify potentially privileged
  information and compromise the host. The latter could could cause
  application breakages. #1232/#1237/#1238, #1287/#1291
• Application containers could inject arbitrary code into containers
  subsequently started via the proxy, causing such code to be executed
  with the (potentially elevated) privileges of that
  container. #1201/#1206
• docker exec would fail for containers not attached to the weave
  network. #1143/#1271/#1152/#1153
• Starting a container in the host network namespace (--net=host)
  would still attempt to attach that container to the weave network,
  and pollute the host network namespace. #1157/#1165/#1167
• Containers started with weave run via the proxy could get an
  additional IP address. #1279/#1284
• When connecting to the proxy with TLS, and using streaming, as
  happens when running a container in the foreground or attaching to
  it, the stream would not terminate. #1182/#1187
• The absence of a command when running a container would not produce
  the expected "No command specified" error. #1241/#1253
• A chain of /w/w entrypoints, instead of a single one, could be
  created when containers were started based on images created by
  docker committing containers on the weave network. This does not
  materially affect behaviour but obscures the real application
  entrypoint in the likes of docker ps. #979/#980
• The proxy did not detect the presence of a custom docker bridge,
  specified with DOCKER_BRIDGE. #1109/#1136/#1137
• The proxy was mounting any specified TLS certificate files in
  read/write mode, which is unnecessary. #1293

Address allocation

• weave launch could hang when restarting a weave peer in a
  multi-node network when there were automatically allocated weave IP
  addresses associated with surviving local application container,
  weavedns, or weave expose. #700/#1083/#1104
• Container startup would fail if IP address allocation took more than
  20s. This timeout has now been removed. #1023/#1064
• IP address allocation could take a long time when the local peer had
  run out of space, and some other peers had recently left the weave
  network. This in turn could cause container startup to be delayed
  excessively, and fail with timeouts. #896/#1005/#1010
• When an IP address range specified with -iprange overlaps with a
  host route, no warning was issued. #1276/#1278

Naming and discovery

• Concurrent resolution of a name could fail temporarily. #1270/#1273
• Due to a bug in Docker 1.7.0 (only; not earlier or later versions),
  name resolution would sometimes fail, especially when there was a
  high churn of containers. #1171/#1192/#1229/#1231
• Resolution of names outside the weavedns domain could fail if the
  upstream DNS server returned a compressed response. #1306/#1313
• Container startup could fail with an obscure error for container
  with a long name, since, unless specified otherwise, weave derives
  hostnames from container names, and the former have a spec-based
  limit of 63 characters. Weave now suppresses the hostname derivation
  when this condition arises and reports a warning. #1006/#1062/#1038
• When weave run was invoked with --dns-search=<arg>, instead of
  --dns-search <arg>, the weavedns domain (typically weave.local)
  could be searched during name resolution even though it
  shouldn't. #1086/#1088/#1089

Other

• weave attach on a container that was started in the host network
  namespace (--net=host) would succeed - even though it shouldn't -
  and pollute the host network namespace. #1162/#1164
• Weave could deplete the OS random number generator's entropy pool
  when connections to a weave peer configured to use encryption were
  made at a high rate. This does not affect weave security but can
  cause other applications to block. We have mitigated this by
  introducing a more sophisticated connection rate limiting
  algorithm - instead of permitting a sustained connection rate of
  1kHz we now only permit 10Hz but allow short bursts of up to 100
  connections. For details, see the
  weave crypto docs. #1037/#1111/#1124
• An application container with multiple weave IP addresses could be
  inaccessible on all but the first for a while. #1261
• When weave detected that the UDP IP/port of a peer had changed, the
  resulting log message did not contain the original IP/port. #1106
• The gopacket package moved from Google Code to GitHub, which broke
  the build. #1071
• The details of failures in the docker-py integration test suite
  weren't being shown. #981
• Several race conditions in the unit and integration tests, and their
  infrastructure, could cause them to fail spuriously. #982/#1017/#1024, #1042/#1052/#1054, #1294/#1296

Weave 1.0.1

This is a bug fix release, addressing the following issue:

• executing docker run from a Docker 1.7 client against the weave
  proxy would report a no such image error when the requested image
  wasn't present on the Docker host, instead of downloading it. #967/#969

Weave 1.0.0

Highlights:

• It is now easier than ever to start containers and for them to communicate, across multiple hosts. Automatic IP address allocation, and name resolution via weaveDNS are now enabled by default, and the proxy has become more fully-featured. In short, once weave has been launched the following is possible:

    host1$ docker run --name=pingme -dti ubuntu
    host2$ docker run -ti ubuntu
    root@d11e9287f65b:/# ping pingme
  

• Containers can now be
  load-balanced
  easily.

• IP address allocation is now available across multiple
  subnets,
  and hence can be employed when running multiple, isolated
  applications.

• The proxy now supports TLS
  connections,
  enabling its deployment when the communication between docker
  clients and the server must be secured.

There are many other new features, plus the usual assortment of bug fixes and improvements under the hood. More detail below and in the change log.

NB: This release changes the weave protocol version. Therefore, when upgrading an existing installation, all hosts need to be upgraded in order to for them to be able to communicate and form a network.

new IP address allocation features

• enabled automatic IP address allocation by
  default,
  allocating in the range 10.128.0.0/10. #743/#870/#893/#905
• add ability to automatically allocate/free IP addresses in specific
  subnets
  by supplying net:<cidr> as the address. #675/#827
• let weave launch-dns get an automatically allocated IP address if
  none (or a subnet) is specified. #762/#900
• weave detach with no addresses now detaches the container from the
  default IP allocation subnet. #862/#827

new weaveDNS features

• add DNS-based load
  balancing
  for
  services. #226/#615/#739/#761, #737, #736/#775, #923/#924/#926/#929, #930/#933
• enable weaveDNS-based name resolution by
  default,
  without requiring any extra parameters
  • application containers are configured to use weaveDNS as their
    name resolver by default. #383/#898
  • resolvers are configured to search the weaveDNS domain
    (i.e. typically weave.local) by default, so names in that domain
    can be resolved without fully qualifying them. #749/#931
  • the container hostname is derived from the container name, for
    easy, automatic registration in weaveDNS. #750/#890, #922/#925
• make it possible to remove individual DNS
  records
  by providing an FQDN to weave dns-remove. #631/#706
• make weaveDNS
  TTL
  configurable. #711/#795, #941/#943

new proxy features

• support connecting to proxy with
  TLS. #506/#813/#814/#815
• enable automatic IP address allocation by default, unless --no-default-ipam is specified. #940/#947, #950/#952
• add weave proxy-env and weave proxy-config
  for easily obtaining the settings required to use the
  proxy. #753/#848, #939/#949
• add weave stop-proxy command. #754/#790
• add ability to specify the proxy listening
  address. #805/#810/#875
• add proxy to weave status
  output. #756/#800,#854,#876/#877/#878
• shorten proxy entrypoint, so that it doesn't obscure the application
  command in the likes of docker ps. #768/#769

new administrative features

• finer-grained control over peer
  topology
  • introduce weave connect --replace to replace command line peer
    addresses. #658/#794
  • permit invocation of weave connect/forget with multiple
    peers. #759/#697
  • add -nodisco option to weave launch to disable peer discovery
    and thus give complete control over peer topology. #847/#853
  • add command line peers to status output. #659/#764, #660/#764
• document recommendations on using a strong
  password. #641/#844
• more detailed documentation on -initpeercount. #758/#946
• improvements to weave and container startup
  • don't time out in weave launch/launch-dns/launch-proxy, since that
    can lead to spurios failures on busy machines. #666/#828
  • don't leave weave containers running when their network
    configuration failed on startup. #192/#831
  • reduce container startup time. #710/#785, #654/#706
  • more helpful error message when weave, weavedns or the proxy fail on startup. #958
• make weave status fail when weave isn't running, which is useful
  for scripted monitoring. #784/#789
• facilitate installation of weave from private docker registries, by
  supplying a custom DOCKERHUB_USER. #887

bug fixes

• various edge cases could cause leaked IP addresses or stale DNS records:
  • restarting weave when there are containers with automatically
    allocated IP addresses that subsequently die. #818/#823
  • death of container just as we are registering it in
    DNS. #821/#865/#904
  • death of container just after we requested automatic IP allocation
    for it. #819/#907
  • death of container that was started with weave start using a
    container name or short id. #881/#884
  • weave detaching an automatically allocated IP address. #861/#827
• some errors were being misreported:
  • network configuration errors during weave ... command execution
    were swallowed and misreported as container deaths. #829/#830
  • when starting application containers, a failure to obtain an
    automatically allocated IP address would be misreported, and leave
    the container running. #921/#889/#932
  • when a container started via the proxy terminates quickly that
    could be misreported as an unexpected container
    death. #812/#820/#824
  • weave run was terminating silently when weave got stopped during
    IP allocation. #916/#918
  • weave --local run, without further arguments, would show the
    weave usage instead of letting docker complain about the lack of
    arguments. #910
  • running weave --local ... on a system w/o nsenter would
    produce a hard to decipher error. #895
• miscellaneous fixes:
  • weave crypto could use the same nonce twice, which provided
    potential attack vectors. #927/#928
  • prevent access to the weaveDNS HTTP API from containers, which had
    made running weaveDNS in the same subnet as application containers
    more insecure than it should be. #899/#906
  • specifying any weave launch argument before -password, -port, or
    -iprange would result in the latter being ignored or not processed
    correctly. #816/#852
  • failed connection attempts between peers could be re-tried too
    quickly. #412/#832
  • fix a race condition in peer topology encoder, resulting from a
    missing lock. #883

build & tests bug fixes and improvements

• transient Alpine Linux repository issues during build could result
  in silently broken weaveexec image. #663
• fixed a number of race conditions that caused spurious failures in
  the unit tests for IPAM (#779/#793, #802/#822, #915/#919), DNS
  (#798/#836/#892/#917, #934/#937, #935), and topology gossip
  (#885/#886/#902)
• prevent port clashes. #720/#792
• fix occasional timeout for non-weave name resolution in
  tests. #347/#761
• shrink top level dir by moving exe/image sub-dirs. #420/#817
• run linter on travis. #765
• various fixes and improvements to CircleCI
  integration. #791/#796/#797
• introduce a mechanism to run individual smoke tests. #728

improvements "under the hood"

• switch to a new protocol header and version negotiation, which is
  flexible enough to permit radical changes with the possibility of
  retaining compatibility. #871/#920
• make it easier to change some aspects of the weave protocol w/o
  breaking compatibility. #911/#914
• limit acceptance rate on peer connections in order to guard against
  online dictionary attacks on the weave password. #837/#839.
• simplify UDP fragmentation check. #746/#888
• simplify proxy interceptor code. #879
• don't hash gossip channel names. #745/#748
• improve IPAM HTTP API to allow lookup of addresses allocated to a
  particular container. #825
• remove pointless DOCKER_HOST parsing for proxy. #807/#808
• restore the "--fallback" argument in WeaveDNS. #773
• introduce helper function to make status output more
  consistent. #863

Weave fast-datapath-preview-20150612

Weaving Containers into Applications

Weave 0.11.2

This is a bug fix release, addressing the following issues:

• weave run did not respect DOCKER_CLIENT_ARGS. #855/#856/#857/#858
• WeaveDNS negative result cache did not expire if requeried within TTL. #845/#849

More details in the change log.

NB: This release does not change the weave protocol version.
Therefore, when upgrading an existing 0.11 installation incrementally,
connectivity between peers will be retained.

Weave 0.11.1

This is a bug fix release, addressing the following issues:

• The IP Allocator could crash in some relatively rare
  circumstances. #782/#783.
• When the proxy failed to attach a container to the weave network,
  there was no failure indication and descriptive error anywhere, and
  the application process would still start. Now an error is reported
  to the client (i.e. typically the Docker CLI), recorded in the proxy
  logs, and the container is terminated. #788/#799.
• weave launch-proxy --with-ipam failed to configure the entrypoint
  and DNS unless a (possibly blank) WEAVE_CIDR was
  specified. Affected containers could start the application process
  w/o the weave network interface being available, and without
  functioning name resolution for the weaveDNS domain. #744/#747/#751/#752
• The weave status output for the IP Allocator was misleadingly
  conveying a sense of brokenness when no IP allocation requests had
  been made yet. #787/#801
• When invoking weave launch-proxy twice, the second invocation
  would output a blank line and terminate with a success exit
  status. Now it reports that the proxy is already running and exits
  with a non-zero status. #767/#780
• weave launch-proxy was not respecting WEAVEPROXY_DOCKER_ARGS, so
  any user-supplied custom configuration for the weaveproxy container
  was ignored. #755/#780
• The proxy was not intercepting API calls to the unversioned (1.0)
  Docker Remote API. Hence none of the weave functionality was available
  when Docker clients were using that version of the
  API. #770/#774/#777,#809
• The proxy would crash when certain elements of the
  /containers/create JSON were missing. We are not aware of any
  Docker clients doing this, but it's been fixed regardless. #778/#777

More details in the change log.

NB: This release does not change the weave protocol version. Therefore, when upgrading an existing 0.11 installation incrementally, connectivity between peers will be retained.