Allow multiple macvlan networks to share a parent #47318

andrewbaxter · 2024-02-04T06:58:44Z

Closes [macvlan] Same parent and gateway for multiple networks #47317

The only case where macvlan interfaces are unable to share a parent is when the macvlan mode is passthru. This change tightens the check to that situation.

- What I did

If two macvlan networks have the same parent and id -> already exists
If two macvlan networks have the same parent, different ids, and at least one is passthru -> error
If two macvlan networks have the same parent, different ids -> create network
If two macvlan networks have different parents -> create network

- How I did it

A new if and continue to skip marking as "found existing".

- How to verify it

Create two macvlan networks with the same parent.

- Description for the changelog

Allow multiple macvlan networks with the same parent [moby#47318](https://github.com/moby/moby/pull/47318).

- A picture of a cute animal (not mandatory but encouraged)

Man sets fire to smoke out opossums, burns down house instead

andrewbaxter · 2024-02-04T07:01:27Z

Just a note, I haven't managed to get tests running locally. I built this with nix, which I think might run tests as part of the build. I tested it manually with with two macvlan interfaces with the same parent (eth0) and at least the interfaces were created with no errors.

Edit: I also added more specificity to the error message. I think it would have been possible to accidentally have an interface set to passthru, see the error message, and become confused thinking that sharing parents is never correct. I'm not 100% sure that the ids used for the message are appropriate though, I think I would have used the network name but I'll wait for clarity on that.

thaJeztah · 2024-02-04T10:11:18Z

Thank you for contributing! It appears your commit message is missing a DCO sign-off,
causing the DCO check to fail.

We require all commit messages to have a Signed-off-by line with your name
and e-mail (see "Sign your work"
in the CONTRIBUTING.md in this repository), which looks something like:

Signed-off-by: YourFirsName YourLastName <yourname@example.org>

There is no need to open a new pull request, but to fix this (and make CI pass),
you need to amend the commit(s) in this pull request, and "force push" the amended
commit.

Unfortunately, it's not possible to do so through GitHub's web UI, so this needs
to be done through the git commandline.

You can find some instructions in the output of the DCO check (which can be found
in the "checks" tab on this pull request), as well as in the Moby contributing guide.

Steps to do so "roughly" come down to:

Set your name and e-mail in git's configuration:
```
git config --global user.name "YourFirstName YourLastName"
git config --global user.email "yourname@example.org"
```
(Make sure to use your real name (not your GitHub username/handle) and e-mail)
Clone your fork locally
Check out the branch associated with this pull request
Sign-off and amend the existing commit(s)
```
git commit --amend --no-edit --signoff
```
If your pull request contains multiple commits, either squash the commits (if
needed) or sign-off each individual commit.
Force push your branch to GitHub (using the --force or --force-with-lease flags) to update the pull request.

Sorry for the hassle (I wish GitHub would make this a bit easier to do), and let me know if you need help or more detailed instructions!

thaJeztah · 2024-02-04T10:14:24Z

Oh! If you're updating; could you remove the Closes #47317 from the commit message? Unfortunately, GitHub has a tendency to either close related tickets prematurely (or producing "noice / notifications") when commits are merged in various places (which could be in forks of this repository). For that reason, we try to avoid referencing tickets in commit messages (and only put them in the description on GitHub, not the commit message).

andrewbaxter · 2024-02-04T10:15:30Z

Oh sure, and sorry about the DCO thing! I should re-read contributing more carefully...

thaJeztah · 2024-02-04T10:25:31Z

No worries! iIt happens frequently (hence my "canned reply" above, which I wrote so that I didn't have to come up with a good way to describe the steps every time 😂 ❤️)

thaJeztah · 2024-02-04T10:27:04Z

Oh! Looks like there's no e-mail address in your sign-off;

Signed-off-by: Andrew Baxter <>

thaJeztah · 2024-02-05T09:46:53Z

/cc @akerouanton @robmry

robmry

Thank you for looking at this, it looks like the right approach - but there are a couple of issues ...

Integration test, TestDockerNetworkMacvlan/OverlapParent in macvlan_test.go was supposed to be checking it's not possible to create two macvlan networks with the same parent.

Unfortunately, the test hasn't been running for a while. But, when that's fixed (#47382), it'll fail with this change.

Also, with a sequence like this ...

# docker network create -d macvlan mv1
# docker network create -d macvlan -o parent=dm-8a604e8c9839 mv2
# docker network rm mv1
# docker run --rm -ti --network mv2 alpine
docker: Error response from daemon: the requested parent interface dm-8a604e8c9839 was not found on the Docker host.

... the first 'create' doesn't specify a parent interface, so a dummy link is created ("dm-8a604e8c9839"). That's remembered in config.CreatedSlaveLink, and the link is deleted by driver.DeleteNetwork() when the network's removed.

That was ok when the dummy link could only be the parent for one macvlan network but now, deleting mv1 leaves mv2 without a parent (and so, would break connectivity for containers on mv2).

Are you up for dealing with that and updating the integration test? I think we should also have a new tests for the pass-through special case, and the create/delete sequence above - if that's permitted.

libnetwork/drivers/macvlan/macvlan_network.go

andrewbaxter · 2024-02-14T17:28:48Z

Thanks for the review! And good point on the logs, I applied the suggestion.

Thank you for looking at this, it looks like the right approach - but there are a couple of issues ...

Integration test, TestDockerNetworkMacvlan/OverlapParent in macvlan_test.go was supposed to be checking it's not possible to create two macvlan networks with the same parent.

Unfortunately, the test hasn't been running for a while. But, when that's fixed (#47382), it'll fail with this change.

Roger, I'll try to update that.

Also, with a sequence like this ...
# docker network create -d macvlan mv1
# docker network create -d macvlan -o parent=dm-8a604e8c9839 mv2
# docker network rm mv1
# docker run --rm -ti --network mv2 alpine
docker: Error response from daemon: the requested parent interface dm-8a604e8c9839 was not found on the Docker host.
... the first 'create' doesn't specify a parent interface, so a dummy link is created ("dm-8a604e8c9839"). That's remembered in config.CreatedSlaveLink, and the link is deleted by driver.DeleteNetwork() when the network's removed.

That was ok when the dummy link could only be the parent for one macvlan network but now, deleting mv1 leaves mv2 without a parent (and so, would break connectivity for containers on mv2).

I need to dig into this further, but before I drop off -- off the top of my head, three ways to handle this would be:

Keep track of children and only delete the interface when no more children exist
Don't delete the dummy(/vlan) parent interface, but instead clean it up in system prune
Re-restrict this so that sharing parents is only allowed for existing interfaces

For 1 I guess iterating all the networks and counting parent users before deleting would probably be the simplest/safest. Reference counting, associating a set of children, deleting the parent in a finalizer are other options but have probably worse drawbacks.

For 2, if someone wanted to share dummy parent interfaces they might want it to keep existing even if they delete all the users. If they're really going to do that, would it be easier to do it outside of moby (i.e. create the interface with their own tooling, the same that would look up the dummy interface id)? If so maybe 3 would be better, otherwise for 2 maybe the dummy interface could be turned into a normal network that could be managed with network tools.

Sorry, I'm probably missing some context here so my guesses may be wildly off.

Did you have any thoughts on how this should be handled?

Are you up for dealing with that and updating the integration test? I think we should also have a new tests for the pass-through special case, and the create/delete sequence above - if that's permitted.

Right, makes sense. I'll look into doing those too.

Thanks again for the review!

robmry · 2024-02-14T18:42:29Z

Keep track of children and only delete the interface when no more children exist

Don't delete the dummy(/vlan) parent interface, but instead clean it up in system prune

Re-restrict this so that sharing parents is only allowed for existing interfaces

Leaving it to system-prune might be tricky, we'd need to be certain that the interface is a docker-created dummy (just deleting interfaces named "dm-nnnn" when there's no "nnnn" network in-use might zap something it shouldn't). And, it'd rely on people running prune to declutter, when we could have dealt with when the last network went-away.

Disallowing sharing of a moby-created dummy interface (a variant on '3') would solve the problem, and this PR would still be a step forward in terms of being able to share real interfaces. It'd be easy to do by just raising an error if nw.config.CreatedSlaveLink is set on the existing interface, as another else if when checking for passthru networks. But, there might be a reason to want to share one of those interfaces for testing... although I'm not convinced and, as you say, it'd be possible to create the dummy parent outside of moby as a workaround.

So, some form of option 1 might be best ...

I agree that explicitly linking the networks or keeping a reference count could get messy.

Maybe set config.CreatedSlaveLink on the new network, if an existing network with the same parent already has the flag set. Then, everything sharing that moby-created dummy parent ends up with the flag set.

Then - in the delete, if the flag is set, search for another network with the same parent - only removing the dummy interface if none are found. That way, the search is only necessary if the flag is set, the order of deletions doesn't matter, and it's not necessary to work out whether the interface is a dummy created for some other already-deleted network.

Right, makes sense. I'll look into doing those too.

Brilliant, thank you!

andrewbaxter · 2024-02-14T18:45:41Z

So, some form of option 1 might be best ...

I was thinking about this a bunch and I think for vlan parents we'd need 1 either way, so probably I was focusing on the dummy interfaces too much.

I'll probably need some time for your updates to sink in to my brain too but that all makes sense.

I'll start by trying 1 iterating the networks and counting uses at delete time and see where that gets me.

robmry · 2024-02-14T20:34:49Z

I was thinking about this a bunch and I think for vlan parents we'd need 1 either way, so probably I was focusing on the dummy interfaces too much.

Oh, yes - my description's also focussed on the dummy interfaces ... but it applies equally to the moby-created VLAN interfaces.

The suggestion is just to make sure CreatedSlaveLink is set on all the networks sharing a moby-created parent, not just the one that actually created it. Then it doesn't matter which order networks are deleted in, the parent interface for a network with CreatedSlaveLink set can be removed when no other networks have the same parent.

thaJeztah · 2024-02-15T13:29:59Z

DOH! Looks like the "accept suggestion" added a separate commit, which.. of course doesn't get a DCO sign-off.

It's probably fine to squash the commits into a single one (you can include the co-authored-by, but we're not always very fussy about that if it's suggestions from maintainers - it's usually fine to skip 😅)

andrewbaxter · 2024-02-17T11:04:25Z

The suggestion is just to make sure CreatedSlaveLink

Right, that makes sense.

It's probably fine to squash the commits into a single one

Ah sorry, I was intending to do that when I got back to this. I'll do that now.

andrewbaxter · 2024-02-17T13:32:47Z

Okay, I think I've taken care of everything: counting other users, integration tests.

Notes on the use counting - I'm not sure if the ok := ...; ok is a convention, but I'd have to add another if/level of nesting to check the use count so I collapsed the 3 clauses into a single if. The counting could be delayed until it was confirmed to be a dummy/vlan parent, but the vlan code has the "is this a vlan device" checks within the delete/create functions and I'm not sure how hot this path is in real life so I went with the less disruptive change.

Notes on the tests - I think these were the key things to check:

Sharing a dummy/vlan/physical/etc interface
Deleting the original interface first
Deleting the 2nd interface first
Existing interfaces don't get deleted
Sharing a parent with a passthru
Creating a passthru with a shared parent

I didn't see explicit tests for ex: implicitly creating a dummy interface, and the existing overlap test would test one of the delete cases. I'm not sure if it's better to have one test per thing to check or if because integration tests are slower it's better to combine them when reasonably possible, but I believe all of the new code paths are reasonably covered with the new test cases.

robmry

LGTM - thank you!

thaJeztah · 2024-03-04T10:33:19Z

@akerouanton PTAL

andrewbaxter · 2024-06-13T18:10:07Z

Hey, just wanted to check in @thaJeztah @akerouanton to make sure you're not waiting on me. I'm still interested in getting this merged, I have current use cases where it would be useful.

akerouanton · 2024-06-13T19:10:28Z

@andrewbaxter I'll take a look tomorrow.

andrewbaxter · 2024-06-14T14:11:57Z

Oh awesome, thanks so much!

thaJeztah · 2024-06-15T12:59:36Z

Tentatively adding this to the v27.0 milestone (assuming review doesn't bring up concerns).

I have a small follow-up to this PR (some cleaning up that I think could be done while I looked at the code); we can merge that one once this PR is approved/merged;

libnetwork: ipvlan, macvlan: cleanup getDummyName utility #47994

❓ Does the same apply to ipvlan; do we need a follow-up to update that driver as well with the same changes?

thaJeztah · 2024-06-15T17:41:14Z

integration/internal/network/ops.go

 }

+// WithMacvlanPassthru sets the network as macvlan with the specified parent in passthru mode
+func WithMacvlanPassthru(parent string) func(*types.NetworkCreate) {


Looks like this no longer compiles when merged into master; I noticed this was failing when I restarted Jenkins (which does a merge before testing);

[2024-06-15T13:02:18.893Z] # github.com/docker/docker/integration/internal/network
[2024-06-15T13:02:18.893Z] integration/internal/network/ops.go:49:47: undefined: types
[2024-06-15T13:02:18.893Z] integration/internal/network/ops.go:50:17: undefined: types

This needs to be updated to use network.CreateOptions.

Let me do a quick rebase, and fix this so that Ci can do another run 👍

The only case where macvlan interfaces are unable to share a parent is when the macvlan mode is passthru. This change tightens the check to that situation. It also makes the error message more specific to avoid suggesting that sharing parents is never correct. Signed-off-by: Andrew Baxter <423qpsxzhh8k3h@s.rendaw.me> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

thaJeztah · 2024-06-15T17:43:04Z

@andrewbaxter I did a quick rebase, and fixed that compile failure I mentioned above 😅 #47318 (comment)

andrewbaxter · 2024-06-15T18:05:16Z

Oh thanks! Sorry, I should have done that.

I'm not sure if the ipvlan question was directed to me, my knowledge is pretty limited though. I'll try to read up on ipvlan in the meantime.

thaJeztah · 2024-06-15T18:12:36Z

I'm not sure if the ipvlan question was directed to me, my knowledge is pretty limited though. I'll try to read up on ipvlan in the meantime.

Not necessarily; in all honesty, it's not my "forte" either, but I know the implementations for the ipvlan and macvlan drivers are very similar, so I was wondering if this was also a property they share (and if so, if we need to do a follow-up to make the changes there as well); for sure not a blocker for this pull request though!

andrewbaxter · 2024-06-24T17:21:54Z

Thanks again for helping me with this and the reviews!

[![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com) This PR contains the following updates: | Package | Update | Change | |---|---|---| | [docker/docker](https://togithub.com/docker/docker) | major | `26.1.4` -> `27.0.3` | --- ### Release Notes <details> <summary>docker/docker (docker/docker)</summary> ### [`v27.0.3`](https://togithub.com/moby/moby/releases/tag/v27.0.3) [Compare Source](https://togithub.com/docker/docker/compare/v27.0.2...v27.0.3) #### 27.0.3 For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones: - [docker/cli, 27.0.3 milestone](https://togithub.com/docker/cli/issues?q=is%3Aclosed+milestone%3A27.0.3) - [moby/moby, 27.0.3 milestone](https://togithub.com/moby/moby/issues?q=is%3Aclosed+milestone%3A27.0.3) - Deprecated and removed features, see [Deprecated Features](https://togithub.com/docker/cli/blob/v27.0.3/docs/deprecated.md). - Changes to the Engine API, see [API version history](https://togithub.com/moby/moby/blob/v27.0.3/docs/api/version-history.md). ##### Bug fixes and enhancements - Fix a regression that incorrectly reported a port mapping from a host IPv6 address to an IPv4-only container as an error. [moby/moby#48090](https://togithub.com/moby/moby/pull/48090) - Fix a regression that caused duplicate subnet allocations when creating networks. [moby/moby#48089](https://togithub.com/moby/moby/pull/48089) - Fix a regression resulting in "fail to register layer: failed to Lchown" errors when trying to pull an image with rootless enabled on a system that supports native overlay with user-namespaces. [moby/moby#48086](https://togithub.com/moby/moby/pull/48086) ### [`v27.0.2`](https://togithub.com/moby/moby/releases/tag/v27.0.2) [Compare Source](https://togithub.com/docker/docker/compare/v27.0.1-rc.1...v27.0.2) #### 27.0.2 For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones: - [docker/cli, 27.0.2 milestone](https://togithub.com/docker/cli/issues?q=is%3Aclosed+milestone%3A27.0.2) - [moby/moby, 27.0.2 milestone](https://togithub.com/moby/moby/issues?q=is%3Aclosed+milestone%3A27.0.2) - Deprecated and removed features, see [Deprecated Features](https://togithub.com/docker/cli/blob/v27.0.2/docs/deprecated.md). - Changes to the Engine API, see [API version history](https://togithub.com/moby/moby/blob/v27.0.2/docs/api/version-history.md). ##### Bug fixes and enhancements - Fix a regression that caused port numbers to be ignored when parsing a Docker registry URL. [docker/cli#5197](https://togithub.com/docker/cli/pull/5197), [docker/cli#5198](https://togithub.com/docker/cli/pull/5198) ##### Removed - api/types: deprecate `ContainerJSONBase.Node` field and `ContainerNode` type. These definitions were used by the standalone ("classic") Swarm API, but never implemented in the Docker Engine itself. [moby/moby#48055](https://togithub.com/moby/moby/pull/48055) ### [`v27.0.1`](https://togithub.com/moby/moby/releases/tag/v27.0.1) [Compare Source](https://togithub.com/docker/docker/compare/v26.1.4...v27.0.1-rc.1) #### 27.0.1 For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones: - [docker/cli, 27.0.0 milestone](https://togithub.com/docker/cli/issues?q=is%3Aclosed+milestone%3A27.0.0) - [moby/moby, 27.0.0 milestone](https://togithub.com/moby/moby/issues?q=is%3Aclosed+milestone%3A27.0.0) - Deprecated and removed features, see [Deprecated Features](https://togithub.com/docker/cli/blob/v27.0.1/docs/deprecated.md). - Changes to the Engine API, see [API version history](https://togithub.com/moby/moby/blob/v27.0.1/docs/api/version-history.md). ##### New - containerd image store: Add `--platform` flag to `docker image push` and improve the default behavior when not all platforms of the multi-platform image are available locally. [docker/cli#4984](https://togithub.com/docker/cli/pull/4984), [moby/moby#47679](https://togithub.com/moby/moby/pull/47679) - Add support to `docker stack deploy` for `driver_opts` in a service's networks. [docker/cli#5125](https://togithub.com/docker/cli/pull/5125) - Consider additional `/usr/local/libexec` and `/usr/libexec` paths when looking up the userland proxy binaries by a name with a `docker-` prefix. [moby/moby#47804](https://togithub.com/moby/moby/pull/47804) ##### Bug fixes and enhancements - `*client.Client` instances are now always safe for concurrent use by multiple goroutines. Previously, this could lead to data races when the `WithAPIVersionNegotiation()` option is used. [moby/moby#47961](https://togithub.com/moby/moby/pull/47961) - Fix a bug causing the Docker CLI to leak Unix sockets in `$TMPDIR` in some cases. [docker/cli#5146](https://togithub.com/docker/cli/pull/5146) - Don't ignore a custom seccomp profile when used in conjunction with `--privileged`. [moby/moby#47500](https://togithub.com/moby/moby/pull/47500) - rootless: overlay2: support native overlay diff when using rootless-mode with Linux kernel version 5.11 and later. [moby/moby#47605](https://togithub.com/moby/moby/pull/47605) - Fix the `StartInterval` default value of healthcheck to reflect the documented value of 5s. [moby/moby#47799](https://togithub.com/moby/moby/pull/47799) - Fix `docker save` and `docker load` not ending on the daemon side when the operation was cancelled by the user, for example with <kbd>Ctrl+C</kbd>. [moby/moby#47629](https://togithub.com/moby/moby/pull/47629) - The `StartedAt` property of containers is now recorded before container startup, guaranteeing that the `StartedAt` is always before `FinishedAt`. [moby/moby#47003](https://togithub.com/moby/moby/pull/47003) - The internal DNS resolver used by Windows containers on Windows now forwards requests to external DNS servers by default. This enables `nslookup` to resolve external hostnames. This behaviour can be disabled via `daemon.json`, using `"features": { "windows-dns-proxy": false }`. The configuration option will be removed in a future release. [moby/moby#47826](https://togithub.com/moby/moby/pull/47826) - Print a warning when the CLI does not have permissions to read the configuration file. [docker/cli#5077](https://togithub.com/docker/cli/pull/5077) - Fix a goroutine and file-descriptor leak on container attach. [moby/moby#45052](https://togithub.com/moby/moby/pull/45052) - Clear the networking state of all stopped or dead containers during daemon start-up. [moby/moby#47984](https://togithub.com/moby/moby/pull/47984) - Write volume options JSON atomically to avoid "invalid JSON" errors after system crash. [moby/moby#48034](https://togithub.com/moby/moby/pull/48034) - Allow multiple macvlan networks with the same parent. [moby/moby#47318](https://togithub.com/moby/moby/pull/47318) - Allow BuildKit to be used on Windows daemons that advertise it. [docker/cli#5178](https://togithub.com/docker/cli/pull/5178) ##### Networking - Allow sysctls to be set per-interface during container creation and network connection. [moby/moby#47686](https://togithub.com/moby/moby/pull/47686) - In a future release, this will be the only way to set per-interface sysctl options. For example, on the command line in a `docker run` command,`--network mynet --sysctl net.ipv4.conf.eth0.log_martians=1` will be rejected. Instead, you must use `--network name=mynet,driver-opt=com.docker.network.endpoint.sysctls=net.ipv4.conf.IFNAME.log_martians=1`. ##### IPv6 - `ip6tables` is no longer experimental. You may remove the `experimental` configuration option and continue to use IPv6, if it is not required by any other features. - `ip6tables` is now enabled for Linux bridge networks by default. [moby/moby#47747](https://togithub.com/moby/moby/pull/47747) - This makes IPv4 and IPv6 behaviors consistent with each other, and reduces the risk that IPv6-enabled containers are inadvertently exposed to the network. - There is no impact if you are running Docker Engine with `ip6tables` enabled (new default). - If you are using an IPv6-enabled bridge network without `ip6tables`, this is likely a breaking change. Only published container ports (`-p` or `--publish`) are accessible from outside the Docker bridge network, and outgoing connections masquerade as the host. - To restore the behavior of earlier releases, no `ip6tables` at all, set `"ip6tables": false` in `daemon.json`, or use the CLI option `--ip6tables=false`. Alternatively, leave `ip6tables` enabled, publish ports, and enable direct routing. - With `ip6tables` enabled, if `ip6tables` is not functional on your host, Docker Engine will start but it will not be possible to create an IPv6-enabled network. ##### IPv6 network configuration improvements - A Unique Local Address (ULA) base prefix is automatically added to `default-address-pools` if this parameter wasn't manually configured, or if it contains no IPv6 prefixes. [moby/moby#47853](https://togithub.com/moby/moby/pull/47853) - Prior to this release, to create an IPv6-enabled network it was necessary to use the `--subnet` option to specify an IPv6 subnet, or add IPv6 ranges to `default-address-pools` in `daemon.json`. - Starting in this release, when a bridge network is created with `--ipv6` and no IPv6 subnet is defined by those options, an IPv6 Unique Local Address (ULA) base prefix is used. - The ULA prefix is derived from the Engine host ID such that it's unique across hosts and over time. - IPv6 address pools of any size can now be added to `default-address-pools`. [moby/moby#47768](https://togithub.com/moby/moby/pull/47768) - IPv6 can now be enabled by default on all custom bridge networks using `"default-network-opts": { "bridge": {"com.docker.network.enable_ipv6": "true"}}` in `daemon.json`, or `dockerd --default-network-opt=bridge=com.docker.network.enable_ipv6=true`on the comand line. [moby/moby#47867](https://togithub.com/moby/moby/pull/47867) - Direct routing for IPv6 networks, with `ip6tables` enabled. [moby/moby#47871](https://togithub.com/moby/moby/pull/47871) - Added bridge driver option `com.docker.network.bridge.gateway_mode_ipv6=<nat|routed>`. - The default behavior, `nat`, is unchanged from previous releases running with `ip6tables` enabled. NAT and masquerading rules are set up for each published container port. - When set to `routed`, no NAT or masquerading rules are configured for published ports. This enables direct IPv6 access to the container, if the host's network can route packets for the container's address to the host. Published ports will be opened in the container's firewall. - When a port mapping only applies to `routed` mode, only addresses `0.0.0.0` or `::` are allowed and a host port must not be given. - Note that published container ports, in `nat` or `routed` mode, are accessible from any remote address if routing is set up in the network, unless the Docker host's firewall has additional restrictions. For example: `docker network create --ipv6 -o com.docker.network.bridge.gateway_mode_ipv6=routed mynet`. - The option `com.docker.network.bridge.gateway_mode_ipv4=<nat|routed>` is also available, with the same behavior but for IPv4. - If firewalld is running on the host, Docker creates policy `docker-forwarding` to allow forwarding from any zone to the `docker` zone. This makes it possible to configure a bridge network with a routable IPv6 address, and no NAT or masquerading. [moby/moby#47745](https://togithub.com/moby/moby/pull/47745) - When a port is published with no host port specified, or a host port range is given, the same port will be allocated for IPv4 and IPv6. [moby/moby#47871](https://togithub.com/moby/moby/pull/47871) - For example `-p 80` will result in the same ephemeral port being allocated for `0.0.0.0` and `::`, and `-p 8080-8083:80` will pick the same port from the range for both address families. - Similarly, ports published to specific addresses will be allocated the same port. For example, `-p 127.0.0.1::80 -p '[::1]::80'`. - If no port is available on all required addresses, container creation will fail. - Environment variable `DOCKER_ALLOW_IPV6_ON_IPV4_INTERFACE`, introduced in release 26.1.1, no longer has any effect. [moby/moby#47963](https://togithub.com/moby/moby/pull/47963) - If IPv6 could not be disabled on an interface because of a read-only `/proc/sys/net`, the environment variable allowed the container to start anyway. - In this release, if IPv4 cannot be disabled for an interface, IPv6 can be explicitly enabled for the network simply by using `--ipv6` when creating it. Other workarounds are to configure the OS to disable IPv6 by default on new interfaces, mount `/proc/sys/net` read-write, or use a kernel with no IPv6 support. - For IPv6-enabled bridge networks, do not attempt to replace the bridge's kernel-assigned link local address with `fe80::1`. [moby/moby#47787](https://togithub.com/moby/moby/pull/47787) ##### Removed - Deprecate experimental GraphDriver plugins. [moby/moby#48050](https://togithub.com/moby/moby/pull/48050), [docker/cli#5172](https://togithub.com/docker/cli/pull/5172) - pkg/archive: deprecate `NewTempArchive` and `TempArchive`. These types were only used in tests and will be removed in the next release. [moby/moby#48002](https://togithub.com/moby/moby/pull/48002) - pkg/archive: deprecate `CanonicalTarNameForPath` [moby/moby#48001](https://togithub.com/moby/moby/pull/48001) - Deprecate pkg/dmesg. This package was no longer used, and will be removed in the next release. [moby/moby#47999](https://togithub.com/moby/moby/pull/47999) - Deprecate `pkg/stringid.ValidateID` and `pkg/stringid.IsShortID` [moby/moby#47995](https://togithub.com/moby/moby/pull/47995) - runconfig: deprecate `SetDefaultNetModeIfBlank` and move `ContainerConfigWrapper` to `api/types/container` [moby/moby#48007](https://togithub.com/moby/moby/pull/48007) - runconfig: deprecate `DefaultDaemonNetworkMode` and move to `daemon/network` [moby/moby#48008](https://togithub.com/moby/moby/pull/48008) - runconfig: deprecate `opts.ConvertKVStringsToMap`. This utility is no longer used, and will be removed in the next release. [moby/moby#48016](https://togithub.com/moby/moby/pull/48016) - runconfig: deprecate `IsPreDefinedNetwork`. [moby/moby#48011](https://togithub.com/moby/moby/pull/48011) ##### API - containerd image store: `POST /images/{name}/push` now supports a `platform` parameter (JSON encoded OCI Platform type) that allows selecting a specific platform-manifest from the multi-platform image. This is experimental and may change in future API versions. [moby/moby#47679](https://togithub.com/moby/moby/pull/47679) - `POST /services/create` and `POST /services/{id}/update` now support `OomScoreAdj`. [moby/moby#47950](https://togithub.com/moby/moby/pull/47950) - `ContainerList` api returns container annotations. [moby/moby#47866](https://togithub.com/moby/moby/pull/47866) - `POST /containers/create` and `POST /services/create` now take `Options` as part of `HostConfig.Mounts.TmpfsOptions` allowing to set options for tmpfs mounts. [moby/moby#46809](https://togithub.com/moby/moby/pull/46809) - The `Healthcheck.StartInterval` property is now correctly ignored when updating a Swarm service using API versions less than v1.44. [moby/moby#47991](https://togithub.com/moby/moby/pull/47991) - `GET /events` now supports image `create` event that is emitted when a new image is built regardless if it was tagged or not. [moby/moby#47929](https://togithub.com/moby/moby/pull/47929) - `GET /info` now includes a `Containerd` field containing information about the location of the containerd API socket and containerd namespaces used by the daemon to run containers and plugins. [moby/moby#47239](https://togithub.com/moby/moby/pull/47239) - Deprecate non-standard (config) fields in image inspect output. The `Config` field returned by this endpoint (used for `docker image inspect`) returned additional fields that are not part of the image's configuration and not part of the [Docker Image Spec] and the [OCI Image Spec]. These fields are never set (and always return the default value for the type), but are not omitted in the response when left empty. As these fields were not intended to be part of the image configuration response, they are deprecated, and will be removed in the future API versions. - Deprecate the daemon flag `--api-cors-header` and the corresponding `daemon.json` configuration option. These will be removed in the next major release. [moby/moby#45313](https://togithub.com/moby/moby/pull/45313) The following deprecated fields are currently included in the API response, but are not part of the underlying image's `Config`: [moby/moby#47941](https://togithub.com/moby/moby/pull/47941) - `Hostname` - `Domainname` - `AttachStdin` - `AttachStdout` - `AttachStderr` - `Tty` - `OpenStdin` - `StdinOnce` - `Image` - `NetworkDisabled` (already omitted unless set) - `MacAddress` (already omitted unless set) - `StopTimeout` (already omitted unless set) ##### Go SDK changes - Client API callback for the following functions now require a context parameter. [moby/moby#47536](https://togithub.com/moby/moby/pull/47536) - `client.RequestPrivilegeFunc` - `client.ImageSearchOptions.AcceptPermissionsFunc` - `image.ImportOptions.PrivilegeFunc` - Remove deprecated aliases for Image types. [moby/moby#47900](https://togithub.com/moby/moby/pull/47900) - `ImageImportOptions` - `ImageCreateOptions` - `ImagePullOptions` - `ImagePushOptions` - `ImageListOptions` - `ImageRemoveOptions` - Introduce `Ulimit` type alias for `github.com/docker/go-units.Ulimit`. The `Ulimit` type as used in the API is defined in a Go module that will transition to a new location in future. A type alias is added to reduce the friction that comes with moving the type to a new location. The alias makes sure that existing code continues to work, but its definition may change in future. Users are recommended to use this alias instead of the `units.Ulimit` directly. [moby/moby#48023](https://togithub.com/moby/moby/pull/48023) - Move and rename types, changing their import paths and exported names. [moby/moby#47936](https://togithub.com/moby/moby/pull/47936), [moby/moby#47873](https://togithub.com/moby/moby/pull/47873), [moby/moby#47887](https://togithub.com/moby/moby/pull/47887), [moby/moby#47882](https://togithub.com/moby/moby/pull/47882), [moby/moby#47921](https://togithub.com/moby/moby/pull/47921), [moby/moby#48040](https://togithub.com/moby/moby/pull/48040): - Move the following types to `api/types/container`: - `BlkioStatEntry` - `BlkioStats` - `CPUStats` - `CPUUsage` - `ContainerExecInspect` - `ContainerPathStat` - `ContainerStats` - `ContainersPruneReport` - `CopyToContainerOptions` - `ExecConfig` - `ExecStartCheck` - `MemoryStats` - `NetworkStats` - `PidsStats` - `StatsJSON` - `Stats` - `StorageStats` - `ThrottlingData` - Move the following types to `api/types/image`: - `ImagesPruneReport` - `ImageImportSource` - `ImageLoadResponse` - Move the `ExecStartOptions` type to `api/types/backend`. - Move the `VolumesPruneReport` type to `api/types/volume`. - Move the `EventsOptions` type to `api/types/events`. - Move the `ImageSearchOptions` type to `api/types/registry`. - Drop `Network` prefix and move the following types to `api/types/network`: - `NetworkCreateResponse` - `NetworkConnect` - `NetworkDisconnect` - `NetworkInspectOptions` - `EndpointResource` - `NetworkListOptions` - `NetworkCreateOptions` - `NetworkCreateRequest` - `NetworksPruneReport` - Move `NetworkResource` to `api/types/network`. ##### Packaging updates - Update Buildx to [v0.15.1](https://togithub.com/docker/buildx/releases/tag/v0.15.1). [docker/docker-ce-packaging#1029](https://togithub.com/docker/docker-ce-packaging/pull/1029) - Update BuildKit to [v0.14.1](https://togithub.com/moby/buildkit/releases/tag/v0.14.1). [moby/moby#48028](https://togithub.com/moby/moby/pull/48028) - Update runc to [v1.1.13](https://togithub.com/opencontainers/runc/releases/tag/v1.1.13) [moby/moby#47976](https://togithub.com/moby/moby/pull/47976) - Update Compose to [v2.28.1](https://togithub.com/docker/compose/releases/tag/v2.28.1). [moby/docker-ce-packaging#1032](https://togithub.com/docker/docker-ce-packaging/pull/1032) [Docker image spec]: https://togithub.com/moby/docker-image-spec/blob/v1.3.1/specs-go/v1/image.go#L19-L32 [OCI Image Spec]: https://togithub.com/opencontainers/image-spec/blob/v1.1.0/specs-go/v1/config.go#L24-L62 </details> --- ### Configuration 📅 **Schedule**: Branch creation - "after 6am on monday" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/earthly/dind).  Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

andrewbaxter mentioned this pull request Feb 4, 2024

[macvlan] Same parent and gateway for multiple networks #47317

Closed

andrewbaxter force-pushed the 47317-allow-macvlan-dup-parent branch from ccab90e to e63e3a5 Compare February 4, 2024 07:12

thaJeztah added status/2-code-review dco/no Automatically set by a bot when one of the commits lacks proper signature area/networking Networking area/networking/d/macvlan Networking labels Feb 4, 2024

andrewbaxter force-pushed the 47317-allow-macvlan-dup-parent branch from e63e3a5 to 087e48f Compare February 4, 2024 10:14

andrewbaxter force-pushed the 47317-allow-macvlan-dup-parent branch 2 times, most recently from 76105ae to b3c8200 Compare February 4, 2024 10:19

andrewbaxter force-pushed the 47317-allow-macvlan-dup-parent branch from b3c8200 to dfb1b82 Compare February 4, 2024 10:26

robmry mentioned this pull request Feb 14, 2024

Run the macvlan/ipvlan integration tests #47382

Merged

robmry requested changes Feb 14, 2024

View reviewed changes

libnetwork/drivers/macvlan/macvlan_network.go Outdated Show resolved Hide resolved

andrewbaxter force-pushed the 47317-allow-macvlan-dup-parent branch 2 times, most recently from e05caf1 to e634c32 Compare February 17, 2024 13:22

robmry approved these changes Feb 19, 2024

View reviewed changes

thaJeztah removed the dco/no Automatically set by a bot when one of the commits lacks proper signature label Feb 19, 2024

robmry added the kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny label Feb 19, 2024

thaJeztah requested a review from akerouanton March 4, 2024 10:33

thaJeztah added the impact/changelog label Jun 14, 2024

thaJeztah added this to the 27.0.0 milestone Jun 15, 2024

thaJeztah mentioned this pull request Jun 15, 2024

libnetwork: ipvlan, macvlan: cleanup getDummyName utility #47994

Merged

thaJeztah reviewed Jun 15, 2024

View reviewed changes

thaJeztah force-pushed the 47317-allow-macvlan-dup-parent branch from e634c32 to d41f0eb Compare June 15, 2024 17:41

thaJeztah force-pushed the 47317-allow-macvlan-dup-parent branch from d41f0eb to 528ffa9 Compare June 15, 2024 17:42

corhere approved these changes Jun 18, 2024

View reviewed changes

akerouanton approved these changes Jun 18, 2024

View reviewed changes

akerouanton merged commit fb8d8a9 into moby:master Jun 18, 2024

Allow multiple macvlan networks to share a parent #47318

Allow multiple macvlan networks to share a parent #47318

Uh oh!

Conversation

andrewbaxter commented Feb 4, 2024 • edited by thaJeztah Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

andrewbaxter commented Feb 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thaJeztah commented Feb 4, 2024

Uh oh!

thaJeztah commented Feb 4, 2024

Uh oh!

andrewbaxter commented Feb 4, 2024

Uh oh!

thaJeztah commented Feb 4, 2024

Uh oh!

thaJeztah commented Feb 4, 2024

Uh oh!

thaJeztah commented Feb 5, 2024

Uh oh!

robmry left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

andrewbaxter commented Feb 14, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

robmry commented Feb 14, 2024

Uh oh!

andrewbaxter commented Feb 14, 2024

Uh oh!

robmry commented Feb 14, 2024

Uh oh!

thaJeztah commented Feb 15, 2024

Uh oh!

andrewbaxter commented Feb 17, 2024

Uh oh!

andrewbaxter commented Feb 17, 2024

Uh oh!

robmry left a comment

Choose a reason for hiding this comment

Uh oh!

thaJeztah commented Mar 4, 2024

Uh oh!

andrewbaxter commented Jun 13, 2024

Uh oh!

akerouanton commented Jun 13, 2024

Uh oh!

andrewbaxter commented Jun 14, 2024

Uh oh!

thaJeztah commented Jun 15, 2024

Uh oh!

thaJeztah Jun 15, 2024

Choose a reason for hiding this comment

Uh oh!

thaJeztah commented Jun 15, 2024

Uh oh!

andrewbaxter commented Jun 15, 2024

Uh oh!

thaJeztah commented Jun 15, 2024

Uh oh!

andrewbaxter commented Jun 24, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

andrewbaxter commented Feb 4, 2024 •

edited by thaJeztah

Loading

andrewbaxter commented Feb 4, 2024 •

edited

Loading

andrewbaxter commented Feb 14, 2024 •

edited

Loading