After quite a bit of work to get bridging setup correctly on VLAN interfaces, I'm wondering if we can remove some keys that seem unnecessary. I've started working through the NM codebase, but I'm not familiar with it yet, so I'm not sure how feasible these suggestions are.
The [connection] section in keyfiles is confusing. It's clearly about identification and general information (id, uuid, permissions, autoconnect, zone, etc.). There are three keys that standout: master, type, and slave-type. I don't think that there's a compelling need for any of them. Additionally, I would like to see interface-name be consolidated to [connection] exclusively. Let's go through each one: type ----- The problem with type is that it's inferred by the rest of the configuration. For example, if I have a VLAN interface, I am required to have a [vlan] section. It seems like NM should be able to determine the type just based on what sections are present. Some settings objects like bridge-port, ipv4, and ipv6 wouldn't be able to set the inferred type, but things like vlan, ppp, and 802-3-ethernet would. master ---------- Master is the most confusing of these keys because it is used so erratically. Master is used to convey relationship to another connection -- sometimes. The problem is that some of the other sections have their own keys to specify relationships. For example, a vlan interface specifies its relationship with the "parent" key in [vlan]. Specifying "master" silently does nothing. On the other hand, to attach an interface to a bridge, one does not use the [bridge-port] section. Instead one needs to use [connection] master. The inconsistency is the problem. To me, it seems like every use of [connection] master would be better served by using the "parent" key in that interface's inferred type section (like bridge-port in the example above). slave-type -------------- There's not much to say here. This key is basically an amalgamation of master and type. The type and slave relationship can be inferred in another section. interface-name --------------------- I don't understand why many of the sections have an interface-name key in addition to connection. Since [connection] is primarily about identifying connections (id, uuid, interface-name), that's the only place where it should be allowed and all the settings objects should inherit from it. There's also some inconsistency. An 802-3-ethernet start without a defined interface-name in [802-3-ethernet], but vlans and bridges both need interface-name in their sub-sections to start. That's the rationale. Let's take a look at a mildly complex configuration that I just setup. This is how I would like the keyfiles to work based on my comments above. Lines that are commented out are now unnecessary, and new lines are noted. [connection] id=p118p1 uuid=8b639214-5806-4135-8e0a-d243f88e562c # type=802-3-ethernet [802-3-ethernet] mac-address=bc:5f:f4:00:2a:0a [ipv4] method=disabled [ipv6] method=ignore #################### [connection] id=vmbr0 interface-name=vmbr0 uuid=105acc55-5bbf-483f-95fe-a9d86a0284f2 # type=bridge [bridge] # interface-name=vmbr0 stp=false [ipv4] method=manual address1=10.3.1.1/24;0.0.0.0 [ipv6] method=ignore ######################## [connection] id=vlan3 interface-name=vlan3 uuid=5aa46e95-8c37-45f1-b683-8b0268818189 # type=vlan # master=105acc55-5bbf-483f-95fe-a9d86a0284f2 # slave-type=bridge [vlan] parent=p118p1 id=3 # interface-name=vlan3 [bridge-port] # NEW parent=vmbr0 # NEW [ipv4] method=disabled [ipv6] method=ignore This configuration feels far more natural. In this example, 7 lines are removed and 2 are added. Thanks, Justin _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
