Comment 29 for bug 1701023

> Unfortunately it turns out this change does not fix the issue of interfaces not
> coming up correctly for a bond with a (static) network configuration

Please keep in mind this bug is *specifically* about the regression caused by the change from bug 1573272, as described in this bug description. My test criteria for the patches for this bug are listed in comment 17 and comment 18. This bug is *not* about any issue that has never worked. If your configuration worked using (assuming Xenial) vlan version 1.9-3.2ubuntu1.16.04.1, but does not work now, then please let me know the details; however if your config doesn't work with (assuming Xenial) vlan version 1.9-3.2ubuntu1.16.04.1 then it's unrelated to this bug and you should open a new bug (or un-dup bug 1759573, if appropriate).

> Executing "ifdown -a; ifup -a" shows that ifupdown tries to bring up the bond BEFORE the slaves

what's your EXACT e/n/i configuration. single file or multiple files? ifup -a brings them up in order that they are listed in e/n/i

> bonds relying on slaves having "bond-master"...

this is nothing new and has nothing to do with this bug. If this is an issue for you, please open a new bug. I agree with you in principle that this should be better, but that's no guarantee it will actually get fixed.

> bringing a specific interface up automatically brings up it's child vlans...

this also is nothing new. this is how things have worked for a long time, and it has nothing to do with this bug. If this is a problem for you, please open a new bug and discuss there. Note I do not think this will change without some significant justification (provided in a new bug, not here please) for why it's a problem.

> a vlan running on top of a bond cannot be brought up directly...

also...nothing new. unrelated to this bug. please open a new bug if this is a problem for you. Also, doubt this will change without specific justification (not provided here, please) for why this is a problem.

I can understand your frustration with the delicate nature of ifupdown; its configuration is more 'delicate' than most users would like, and calling ifup directly for specific interfaces doesn't always work the way you would like, for more complicated configurations. However, it's been like this, and for the most part you just have to learn its limitations and live with them. Opening bugs for ifupdown limitations is fine, but some things just won't be changed.

In the future, netplan and/or systemd-networkd take over interface configuration, and I think you may find them much more reliable and robust, although maybe more complicated to configure and/or less "flexible" than ifupdown in some ways.