If a plugin stops or restarts, Docker isn't aware of the stop or restart. It is only concerned with the plugin when a call is required from the network like port/bridge/network CRUD operations.
We populate the OVSDB cache at plugin runtime so any existing ports are cached and so a port delete is handled just fine.
Problem: What isn't in the cache are network IDs. So libnetwork sends a create endpoint with a network ID that doesn't exist because it isn't persistent through the plugin restart.
Proposed Solution: Since we have a persistent database in OVSDB, we could simply write libnetwork network ID's to a bridge row in the bridge table in a metadata/options/stamp collection field.
= Docker daemon error from a new container request if the plugin was restarted since the original network create:
Cannot start container 2c7f4ff12b2d808a9032c6dd99d6603a4a30cc76693756360d883d2b58af9643: remote: No such network 9696d65c1e227aabdf9794f49a4638f78e5da3cb36f5578a2ef1c74e46acc624
If a plugin stops or restarts, Docker isn't aware of the stop or restart. It is only concerned with the plugin when a call is required from the network like port/bridge/network CRUD operations.
We populate the OVSDB cache at plugin runtime so any existing ports are cached and so a port delete is handled just fine.
Problem: What isn't in the cache are network IDs. So libnetwork sends a create endpoint with a network ID that doesn't exist because it isn't persistent through the plugin restart.
Proposed Solution: Since we have a persistent database in OVSDB, we could simply write libnetwork network ID's to a bridge row in the bridge table in a metadata/options/stamp collection field.
= Docker daemon error from a new container request if the plugin was restarted since the original network create: