GNOME Bugzilla – Bug 682052
settings: support for an "any" NMSettingConnection:slave-type
Last modified: 2020-11-12 14:28:57 UTC
I'm assuming that a slave connection must always have a master (set in the 'master' setting). The master's connection type implies the value of 'slave-type' and makes it redundant. If my assumption is correct, the simplest backwards compatible way to fix this is to deprecate 'slave-type'. It could be even simply ignored.
Patch available in 'pavlix/next' branch.
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=826dfdbf bridging/bonding: make 'slave-type' setting optional (bgo #682052) When 'master' is set, the 'slave-type' can be easily determined from the master. But sometimes you don't have access to the list of connections. Eg, NMSettingConnection's verify function checks if slave-type is "bond", and ensures that there's no IPv4 configuration in that case. It wouldn't be able to do that if it had only "master".
(In reply to comment #2) > http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=826dfdbf > > bridging/bonding: make 'slave-type' setting optional (bgo #682052) > > When 'master' is set, the 'slave-type' can be easily determined > from the master. > > But sometimes you don't have access to the list of connections. Eg, > NMSettingConnection's verify function checks if slave-type is "bond", and > ensures that there's no IPv4 configuration in that case. I fail to see the difference between bridges and bonds with regards to IP configuration. Either way, I believe that a slave connection should only be activated when it's matched to the master connection and then you know the type.
Yes, it's probably a bug that that code only applies to bonds. But anyway, this isn't about activation, it's about validating the configuration (eg, when reading in an ifcfg file, or trying to save a new connection in nm-connection-editor). In particular, in the ifcfg case, it may not have read in the master yet when it reads the slave, so in order to verify it correctly, it would have to be rewritten to read all of the files first and then verify them all afterwards. (And we'd need new versions of nm_connection_verify() and nm_setting_verify() that took a list of all connections, or something.) I'm not saying this renders the bug completely invalid, just that there *are* places that currently make use of the slave-type property in ways that are not completely trivial to rewrite.
I think the easiest solution would be to just treating missing 'slave-type' as *any* type of the master device. And if there are any master-type-specific options, they should imply a specific 'slave-type'. That doesn't seem to require any serious rewrite, AFAIK we just need to allow a master-type-free slave configuration to accomplish that.
AFAIK the code base is now different and there's a verification/normalization code for connections that can be used to easily normalize and verify a connection read from any of the settings plugins.
dropping from 0.9.10 tracker; at best, for 0.9.10, we could make slave-type unnecessary *in keyfiles* but still required in NMSettingConnection. But that's covered by bug 696936.
This BZ asks for a "match-all" slave-type. Obviously, such a slave-type can not contain a NM_SETTING_BRIDGE_PORT/NM_SETTING_TEAM_PORT, because the presence of such a setting determines the slave-type too. Such a connection would wait until having a master device at hand to decide on the type. The good thing is, we can do this later without breaking compatibility, because it actually relaxes the requirements for a connection. I argue however, that this is not overly useful. However it adds considerably complexity because it leaves a connection ambiguous and that has to be accounted for at various places. I vote for closing as "WONTFIX".
(In reply to comment #8) > I argue however, that this is not overly useful. However it adds considerably > complexity because it leaves a connection ambiguous and that has to be > accounted for at various places. I vote for closing as "WONTFIX". I still think it is useful to avoid redundant settings whenever possible. I don't plan to work on this, so if you think the complexity is not justified, feel free to close.
Bug 696939 talks about redundant keyfile settings. If the attached branch will be accepted and merged, the following is a valid, minimal keyfile: [connection] type=802-3-ethernet master=br0 slave-type=bridge Note, that the branch of bug 696939 extends nm_connection_normalize(), so it not only applies to keyfile, but settings in general. normalize() will add the corresponding type and slave-type settings, so that the above is actually equal to: [connection] type=802-3-ethernet master=br0 slave-type=bridge [802-3-ethernet] [bridge-port] Note that in this case [connection].master tells us that we have ~some~ kind of slave. But [connection].slave-type tells us *which* kind. So, slave-type is not redundant, it really adds information. This BZ asks is to support a "any" slave-type where the actual slave kind is left unspecified: [connection] type=802-3-ethernet master=br0 You might argue, that if there exists a bridge-master 'br0' so that the slave-type is ~somewhat~ redundant. But you can no longer look at the slave-connection alone and know which slave-type it is. The slave-type only gets determined later when seeing a matching 'br0' device. In such a configuration you cannot specify any non-default slave-port-settings because a [bridge-port] setting would again make the slave-type explicit. I do see some use for this. Adding it would not even break backward compatibility, because we would *add* a new slave-type ("any") and it would relax verify() to allow for slave-type missing. Ok, lets keep this open. I think it could be done relatively easy after finishing bug 696939. If we agree that this is useful and worth the effort. I updated the bug subject too.
(In reply to comment #10) > Bug 696939 talks about redundant keyfile settings. If the attached branch will > be accepted and merged, the following is a valid, minimal keyfile: Sorry, mixed up bug numbers. It is not bug 696939 but bug 696936.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).