Removing a port from a VLAN filtering bridge is broken #869
Comments
wkz
added
bug
wkz
added a commit
that referenced
this issue
Dec 16, 2024
TL;DR: > New code, all bugs removed ;) Incremental reconfiguration of bridge related settings had lots of ordering issues. This change tries to remedy that by: - Introducing the concept of "snippets": Instead of having to run C code in the correct order (which is doomed to fail since teardowns typically need to run in reverse), collect related settings in a snippet. Later on, we can then concatenate snippets into a larger file in the proper order. - Refactoring the bridge setup to take advantage of snippets. Now we can call out to functions that _both_ generate the VLAN config _and_ sets some bridge global options, for example. This gets us out of having to pass back settings to the main generation function. - Ensuring that deleted objects are always removed - in the proper order - in the exit action of the previous generation. This was previously not true for VLANs, fix #869. - Generating `mcd`:s config orthogonally from the bridge setup. Since we need to keep track of _all_ bridges, figure out when VLAN uppers exist etc., it becomes _very_ messy to generate the configuration from the diff of a single interface. There were lots of cases here where disabling the querier service on one bridge would disable the whole daemon, thereby disabling the service for other bridges that still had it enabled.
wkz
added a commit
that referenced
this issue
Dec 16, 2024
TL;DR: > New code, all bugs removed ;) Incremental reconfiguration of bridge related settings had lots of ordering issues. This change tries to remedy that by: - Introducing the concept of "snippets": Instead of having to run C code in the correct order (which is doomed to fail since teardowns typically need to run in reverse), collect related settings in a snippet. Later on, we can then concatenate snippets into a larger file in the proper order. - Refactoring the bridge setup to take advantage of snippets. Now we can call out to functions that _both_ generate the VLAN config _and_ sets some bridge global options, for example. This gets us out of having to pass back settings to the main generation function. - Ensuring that deleted objects are always removed - in the proper order - in the exit action of the previous generation. This was previously not true for VLANs, fix #869. - Generating `mcd`:s config orthogonally from the bridge setup. Since we need to keep track of _all_ bridges, figure out when VLAN uppers exist etc., it becomes _very_ messy to generate the configuration from the diff of a single interface. There were lots of cases here where disabling the querier service on one bridge would disable the whole daemon, thereby disabling the service for other bridges that still had it enabled.
wkz
added a commit
that referenced
this issue
Dec 16, 2024
TL;DR: > New code, all bugs removed ;) Incremental reconfiguration of bridge related settings had lots of ordering issues. This change tries to remedy that by: - Introducing the concept of "snippets": Instead of having to run C code in the correct order (which is doomed to fail since teardowns typically need to run in reverse), collect related settings in a snippet. Later on, we can then concatenate snippets into a larger file in the proper order. - Refactoring the bridge setup to take advantage of snippets. Now we can call out to functions that _both_ generate the VLAN config _and_ sets some bridge global options, for example. This gets us out of having to pass back settings to the main generation function. - Ensuring that deleted objects are always removed - in the proper order - in the exit action of the previous generation. This was previously not true for VLANs, fix #869. - Generating `mcd`:s config orthogonally from the bridge setup. Since we need to keep track of _all_ bridges, figure out when VLAN uppers exist etc., it becomes _very_ messy to generate the configuration from the diff of a single interface. There were lots of cases here where disabling the querier service on one bridge would disable the whole daemon, thereby disabling the service for other bridges that still had it enabled.
wkz
added a commit
that referenced
this issue
Dec 17, 2024
TL;DR: > New code, all bugs removed ;) Incremental reconfiguration of bridge related settings had lots of ordering issues. This change tries to remedy that by: - Introducing the concept of "snippets": Instead of having to run C code in the correct order (which is doomed to fail since teardowns typically need to run in reverse), collect related settings in a snippet. Later on, we can then concatenate snippets into a larger file in the proper order. - Refactoring the bridge setup to take advantage of snippets. Now we can call out to functions that _both_ generate the VLAN config _and_ sets some bridge global options, for example. This gets us out of having to pass back settings to the main generation function. - Ensuring that deleted objects are always removed - in the proper order - in the exit action of the previous generation. This was previously not true for VLANs, fix #869. - Generating `mcd`:s config orthogonally from the bridge setup. Since we need to keep track of _all_ bridges, figure out when VLAN uppers exist etc., it becomes _very_ messy to generate the configuration from the diff of a single interface. There were lots of cases here where disabling the querier service on one bridge would disable the whole daemon, thereby disabling the service for other bridges that still had it enabled.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current Behavior
When operating on
candidate, we should infer the removal of all VLAN memberships associated with a port being removed from the bridge.But even if that is manually done, it is not possible to detach the port in a single transaction:
Whereas if we split it in two transactions, it works fine:
This has to do with the fact that
confdwill incorrectly generate the VLAN deletions in the init action of the new config generation, rather than in the exit action of the previous one.Expected Behavior
Should work
Steps To Reproduce
From the CLI:
Additional information
No response
The text was updated successfully, but these errors were encountered: