Use GetAllByCap to get list of network plugins in docker info #29877
Conversation
|
@cpuguy83 idk how this PR causes the 2 failures (TestAuthZPluginBadManifestFailsDaemonStart and TestExternalVolumeDriverRetryNotImmediatelyExists). It seems call to |
returned in "docker info". Currently info endpoint isnt using the GetAllByCap, but relies on existing networks to get the plugin names. This causes a basic issue when it comes to global network plugins which swarm-mode relies on, wherein swarmkit will not be able to schedule the network on the worker nodes due to the filtering logic. In order to break this chicken & egg issue, we must start to use the GetAllManagedPluginsByCap. We are unable to use GetAllByCap due to various issues with Plugin-V1's lazy loading approach causing issues especially during daemon restarts (which uses SystemInfo) Signed-off-by: Madhu Venugopal <madhu@docker.com>
|
@cpuguy83 as discussed, since |
This makes the test a bit more robust to change and is a bit cleaner. As implemented before this commit, we have two named plugins pointing to the same http service. If the daemon makes any unexpected calls to the plugin (e.g. during startup) we'll get more counts on the event counter than expected since the daemon sees 2 plugins. Found this while working on moby#29877 which broke this test originally (but is no longer using V1 plugins, so is this is no longer broken there) and took some time to debug what was going on. Signed-off-by: Brian Goff <cpuguy83@gmail.com>
|
LGTM. |
|
LGTM |
Cherry-pick #29877 : Use GetAllByCap to get list of network plugins in docker info
|
I'm not sure if its a good idea to ignore v1 network plugins in swarm mode. moby/swarmkit#1808 enabled swarm filtering support for both v1 and v2. Did 1.12 ever support plugin filters? And if yes, wouldnt this PR cause a regression? cc @aaronlehmann @aluzzardi |
No, it was disabled before release. The problem was that plugins were lazy-loaded, so the list of plugins wasn't useful for scheduling. |
returned in "docker info". Currently info endpoint isnt using the
GetAllByCap, but relies on existing networks to get the plugin names.
This causes a basic issue when it comes to global network plugins which
swarm-mode relies on, wherein swarmkit will not be able to schedule the
network on the worker nodes due to the filtering logic.
In order to break this chicken & egg issue, we must start to use the
GetAllManagedPluginsByCap. We are unable to use GetAllByCap due to
various issues with Plugin-V1's lazy loading approach causing issues
especially during daemon restarts (which uses SystemInfo)
Signed-off-by: Madhu Venugopal madhu@docker.com