Re: RFC: Simplifying Keyfiles

[Dan Winship <danw gnome org>]

On 03/27/2014 02:55 PM, 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.

So, one thing to understand is that (a) the keyfile plugin is mostly a
one-to-one mapping from NMSetting subclass properties, and (b) the
NMSetting subclass properties have to maintain API stability. So some of
what you're seeing is just accumulated cruft.

In some cases, we could fix the keyfile plugin to allow some
simplifications.

> The [connection] section in keyfiles is confusing. It's clearly about
> identification and general information (id, uuid, permissions,
> autoconnect, zone, etc.).

It's called "connection" because it corresponds to NMSettingConnection.
But that mostly corresponds to the "General" page in
nm-connection-editor, and perhaps should be called that.

> 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.

Right, but if you have an ethernet interface, you *aren't* required to
have an [ethernet] section, because none of the properties on
NMSettingWired are mandatory-to-set. The value of type could, perhaps,
be inferred when a type-specific section was present.

> Master is the most confusing of these keys because it is used so
> erratically.

It's actually used 100% consistently, and maps to a specific property of
the kernel network interface.

A device that has a master has no IP configuration of its own, because
it is used only as part of the operation of its master device. This is a
completely different situation from VLAN parent, where the VLAN
interface and its parent are entirely independent of each other at the
IP level.

Also, "master" points to a device that requires this one, while
"parent" points to a device that this one requires. And in particular,
a VLAN device can have both a parent and a master. Eg, if you have
bond0 containing eth0.1 and eth1.1, then eth0.1 would have parent=eth0
and master=bond0. Whereas a device can't have two masters.

> 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).

We could in theory have separate "master" properties for each slave
type, and maybe we would have done it that way if we had added bridge
support first. (Note that there's no slave-specific keyfile section /
NMSetting subclass for bonds, because bond slaves have no slave-specific
properties.)

> 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.

As mentioned above, for bond slaves, there is no [bond-slave] section,
so this could only be inferred by looking up the connection pointed to
by "master", which is not always convenient.

(However, see also https://bugzilla.gnome.org/show_bug.cgi?id=682052)

> interface-name
> ---------------------
>
> I don't understand why many of the sections have an interface-name key
> in addition to connection.

The connection interface-name property is new in 0.9.10. The
bond/bridge/vlan/team-specific interface-name properties are now deprecated.

If they're still required in keyfiles in git master, then file a bug
please. They shouldn't be.

-- Dan