I think the difference in behavior between a bonded interface and a bridged bond can be explained by the following section of SQL:
ORDER BY node.hostname,
is_boot DESC, family(staticip.ip),
CASE
WHEN interface.type = 'bond' AND parent.id = node.boot_interface_id THEN 1
WHEN interface.type = 'physical' AND interface.id = node.boot_interface_id THEN 2
WHEN interface.type = 'bond' THEN 3
WHEN interface.type = 'physical' THEN 4
WHEN interface.type = 'vlan' THEN 5
WHEN interface.type = 'alias' THEN 6
WHEN interface.type = 'unknown' THEN 7
ELSE 8
This query was originally written before bridges were introduced in MAAS, and does not appear to consider them at all.
It looks like we might require another join here to check for the parent-of-a-parent, since we won't know if the bridge's parent-of-a-parent (the bond) is the boot interface. The query currently just checks direct parents.
I think the difference in behavior between a bonded interface and a bridged bond can be explained by the following section of SQL:
ORDER BY
node.hostname,
family( staticip. ip),
parent. id = node.boot_ interface_ id THEN 1
interface. id = node.boot_ interface_ id THEN 2
is_boot DESC,
CASE
WHEN interface.type = 'bond' AND
WHEN interface.type = 'physical' AND
WHEN interface.type = 'bond' THEN 3
WHEN interface.type = 'physical' THEN 4
WHEN interface.type = 'vlan' THEN 5
WHEN interface.type = 'alias' THEN 6
WHEN interface.type = 'unknown' THEN 7
ELSE 8
This query was originally written before bridges were introduced in MAAS, and does not appear to consider them at all.
It looks like we might require another join here to check for the parent-of-a-parent, since we won't know if the bridge's parent-of-a-parent (the bond) is the boot interface. The query currently just checks direct parents.