mirror of
https://github.com/moby/moby.git
synced 2026-07-12 18:45:06 +00:00
b656cffe4c
Field 'generic' in 'libnetwork.Network' is used to store driver options, it has type 'options.Generic', which is 'map[string]any'. In that map, there may be a key 'netlabel.GenericData' holding options known as "network generic options", used for options like: -o com.docker.network.bridge.name=br-foo The value type for key 'netlabel.GenericData' is always 'map[string]string' when created via an API request. But, some unit tests use type 'options.Generic'. That works because the bridge, ipvlan and macvlan drivers look for type 'options.Generic' as well as 'map[string]string'. If they find 'options.Generic', Go reflection is used to map keys to fields of the config struct with the expectation that the value has the same type as that field. But, that's only used in unit tests (so the tests aren't testing the same code path as the API would use). The 'options.Generic' form of the bridge name option is: "BridgeName": "br-foo" (Because "BridgeName" is the name of the field in the bridge driver's network config struct.) The libnetwork code expects "network generic options" to have type 'map[string]string', and makes no provision for 'options.Generic'. So, for example, function Network.DriverOptions will panic if called when 'Network.generic[netlabel.GenericData]' has type 'options.Generic'. The type of 'Network.generic[netlabel.GenericData]' can't be statically checked, because it's just a field in a 'map[string]any'. So - remove the driver code that converts "network generic options" from type 'options.Generic', as it's only used in tests and just makes things more confusing. This should reduce the chances of things appearing to work when the type is wrong, and converting unit tests to use 'map[string]string' means they're testing the right thing. Signed-off-by: Rob Murray <rob.murray@docker.com>
libnetwork - networking for containers
Libnetwork provides a native Go implementation for connecting containers
The goal of libnetwork is to deliver a robust Container Network Model that provides a consistent programming interface and the required network abstractions for applications.
Design
Please refer to the design for more information.
Using libnetwork
There are many networking solutions available to suit a broad range of use-cases. libnetwork uses a driver / plugin model to support all of these solutions while abstracting the complexity of the driver implementations by exposing a simple and consistent Network Model to users.
Contributing
Want to hack on libnetwork? Docker's contributions guidelines apply.
Copyright and license
Code and documentation copyright 2015 Docker, inc. Code released under the Apache 2.0 license. Docs released under Creative commons.