RFC: Simplifying Keyfiles

[Justin Brown <justin brown fandingo org>]

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