2.3 - Network preseed misconfigures static routes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Triaged
|
High
|
Unassigned |
Bug Description
In 2.3, with cloud-init configuring networking, the ENI renderer produces a valid, but suspect interfaces file when using static routes. MaaS is producing a network config that puts all the static routes in the 'network.routes' stanza instead of including each route in the 'subnets.[].routes' section for the interface that would be the source for that route.
The static routes are translated into post-up/pre-down that appear at the tail end of the interfaces file. ifup interprets this by attaching these post-up/pre-down actions to the last interface. We have seen a lot of indeterminate behavior with routes not getting configured becauses the last interface defined in the interfaces will come up before the source interface for some of the routes. The particular configuration this has shown up on is a bonded interface with multiple VLAN tagged subinterfaces on it. Each subinterface has one or more static routes, but all the route statements are attributed to the last VLAN tagged interface. Deployed nodes on reboot can have a random set of the routes not configured with the fix being to ifdown/ifup the last defined VLAN tagged interface.
Attached is a patch we are using to correct this until it is fixed in the upstream MaaS. It is rough and is likely not a final fix.
diff --git a/src/maasserve
index 1be72d6..96ee6a3 100644
--- a/src/maasserve
+++ b/src/maasserve
@@ -192,7 +192,7 @@ class InterfaceConfig
return {
route
for route in self.routes
- if route.source == source
+ if str(route.
}
def _generate_
@@ -251,8 +251,12 @@ class InterfaceConfig
- self.matching_
- self._get_
+ net_routes = self._get_
+ rl = [_generate_
+ for r
+ in net_routes]
+ v1_subnet_
+ v2_config['routes'] = rl
if dhcp_type:
Hi Scott,
MAAS doesn’t pass network configuration to cloud-init. MAAS passes the network configuration to Curtin. Curtin decided to pass through this configuration to cloud-init instead of doing it in Curtin itself.
If cloud-init is not interpreting the configuration correctly as expected by Curtin, then this is a bug in cloud-init. Could you please attach the present that’s been sent so we can triage debug this issue.