On 27.03.2014 19:55, Justin Brown wrote: > 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
Comparison is always welcomed, The NetworkManager compared to the systemd-networkd - Bridge-static: http://goo.gl/N9pnYe poma _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
