On daemon shutdown, the HTTP server tries to gracefully shutdown for 5
seconds. If there's an open API connection to the '/events' endpoint, it
fails to do so as nothing interrupts that connection, thus forcing the
daemon to wait until that timeout is reached.
Add a Close method to the EventsService, and call it during daemon
shutdown. It'll close any events channel, signaling to the '/events'
handler to return and close the connection.
It now takes ~1s (or less) to shutdown the daemon when there's an active
'/events' connection, instead of 5.
Signed-off-by: Albin Kerouanton <albin.kerouanton@docker.com>
This package was originally internal, but was moved out when BuildKit
used it for its integration tests. That's no longer the case, so we
can make it internal again.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These comments were added to enforce using the correct import path for
our packages ("github.com/docker/docker", not "github.com/moby/moby").
However, when working in go module mode (not GOPATH / vendor), they have
no effect, so their impact is limited.
Remove these imports in preparation of migrating our code to become an
actual go module.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When an IPv6 network is first created with no specific IPAM config,
network inspect adds a CIDR range to the gateway address. After the
daemon has been restarted, it's just a plain address.
Once the daaemon's been restated, "info" becomes "config", and the
address is reported correctly from "config".
Make the IPv6 code to report the gateway from "info" use net.IPNet.IP
instead of the whole net.IPNet - like the IPv4 code.
Signed-off-by: Rob Murray <rob.murray@docker.com>
Commit facb2323 aligned the way the default bridge's IPv6 subnet
and gateway addresses are selected with IPv4.
Part of that involved looking at addresses already on the bridge,
along with daemon config options. But, for IPv6, the kernel will
assign a link-local address to the bridge.
Make sure that address is ignored when selecting "bip6" when it's
not explicitly specified.
This is made slightly complicated because we allow fixed-cidr-v6
to be a link-local subnet (either the standard "fe80::/64", or
any other non-overlapping LL subnet in "fe80::/10").
Following this change, if fixed-cidr-v6 is (or is included by)
"fe80::/64", the bridge's kernel-assigned LL address may be used
as the network's gateway address - even though it may also get an
IPAM-assigned LL address.
Signed-off-by: Rob Murray <rob.murray@docker.com>
These tests create iptables rules for different addresses on
docker0 but, unlike tests that do that for user-defined bridges,
those rules aren't removed when the test deletes the network,
because the default bridge network can't be deleted.
So, use (abuse) the L3Segment code to run the tests in their
own network namespace.
Signed-off-by: Rob Murray <rob.murray@docker.com>
Use the same logic to generate IPAMConf for IPv6 as for IPv4.
- When no fixed-cidr-v6 is specified, rather than error out, use
the default address pools (as for an IPv4 default bridge with no
fixed-cidr, and as for user-defined networks).
- Add daemon option --bip6, similar to --bip.
- Necessary because it's the only way to override an old address
on docker0 (daemon-managed default bridge), as illustrated by
test cases.
- For a user-managed default bridge (--bridge), use IPv6 addresses
on the user's bridge to determine the pool, sub-pool and gateway.
Following the same rules as IPv4.
- Don't set up IPv6 IPAMConf if IPv6 is not enabled.
Signed-off-by: Rob Murray <rob.murray@docker.com>
When a user-managed bridge is used for the default network (--bridge),
an address from the bridge determines the subnet for the network.
If a fixed-cidr is supplied, it should fall within that subnet. If it
doesn't, it's a misconfiguration - fixed-cidr is the range of
allocatable addresses, and they need to be in the network. (Either
the user's bridge is missing an address that matches their fixed-cidr
or the fixed-cidr is wrong.)
When this happens, because it's been allowed in the past (and, because
the address-pool implementation treats fixed-cidr/SubPool as an offset
into the network rather than an actual address range, so working IP
addresses would normally still be assigned to containers) ... don't
reject the config and cause daemon startup to fail. Just log a warning
and ignore fixed-cidr.
Signed-off-by: Rob Murray <rob.murray@docker.com>
For a docker-managed default bridge (docker0), when no --bip is
supplied, the gateway address and subnet size can be inferred
from existing bridge addresses.
But, if fixed-cidr's subnet size is increased so that it's biggger
than the subnet of the bridge's existing address - the bridge's
subnet needs to be incresed to match. (fixed-cidr determines the
range of addresses that can be automatically allocated, and these
should not fall outside the default bridge's subnet.)
Signed-off-by: Rob Murray <rob.murray@docker.com>
When a docker-managed default bridge (docker0) already has an
address, and the fixed-cidr subnet fits within the subnet defined
by that address, the existing address should be used as the
gateway and to define the subnet.
But, when fixed-cidr is changed, no --bip is supplied, and no
existing bridge network includes fixed-cidr ... the existing
bridge address needs to be updated.
Signed-off-by: Rob Murray <rob.murray@docker.com>
When a user-managed bridge is used instead of docker0 (--bridge), with
a fixed-cidr - the bridge should have an IP address/subnet that
encompasses fixed-cidr ... the bridge address's subnet then defines
the network's subnet, and fixed-cidr defines the allocatable range
within that.
But, selection of the correct subnet/address from the bridge depended
on the address being within fixed-cidr (within the allocatable range).
This change removes that assumption. So, a bridge address with a
subnet that includes fixed-cidr is selected.
Signed-off-by: Rob Murray <rob.murray@docker.com>
Becuase I'm about to add tests that use netlink, and the netlink
package breaks compilation under Windows.
Signed-off-by: Rob Murray <rob.murray@docker.com>
