Re: Extending nm with a new device/connection type


On Wed, 2020-04-15 at 22:11 +0300, Sergey Galas wrote:

we used systemd network service

That sounds like systemd-networkd, but just to be clear, I think you
mean "network.service" from network-scripts (initscripts) package.

to create the vhost0 interface for contrail vrouter.
in rhel8 the service is not anymore but we still need to perform that

"network.service" is provided by "network-scripts" package, which was
split out of "initscripts" package. "network-scripts" package (and
"network.service" still exists in RHEL8 and will exist for all time on
RHEL8. It is merely not installed and configured by default.

Yes, "network-scripts" is marked as "deprected" in RHEL8. That means,
that maybe (only maybe) it will be dropped in future RHEL, and it means
that it is maybe a bad idea to use it. On the other hand, if you know
better, you can ignore that advice.

Look at "network-scripts" package. That is a simple set of shell
scripts. Their simplicity is kinda beatiful, but they are also
limited(*), which is why we move away from it. If you feel that these
scripts work well for you, you can still use them, or provide similar
scripts that do what you want.

(*) of course, a shell script can do everything, so it's more powerful
than any mechanism that isn't a complete programming language. But what
network-scripts provide out of the box, and what you are reasonably
expect to use is limited. E.g. there is no hotplug because in the
common case there is no stateful service around to react to that. Of
course, you could hack that for example via udev and since you anyway
have all the power of executing arbitrary code, but nobody is seriously
implementing that in network-scripts. 

On RHEL/Fedora you will always be able to run shell scripts. Your
current solution is to run a shell script and you may continue to do so
(when I say "shell scripts", it can be any application of your choosing
that does something).

first it
was decided to extend nm in the way similar to ovs integration but
previous attempts 
were rejected mainly because the vrouter kernel module and other
tools employed in the
patch didn't meet the same requirements as the rest of the devices
already supported
by the project.

To be specific, the solution is not available as Opensource software in
common distributions. That is quite a problem for inclusion in
NetworkManager. If you convince a popular Linux distributions to
include it (as free software), and we are very interested for
supporting it in NetworkManager.

ow we look for an option to extend nm by modules outside of its
source tree. nm
uses a fixed list of settings/connections both inside the service and
in the 
cli application. both sides employ custom, sometimes sophisticated
marshallers for these objects.
what is the preferable way to make the meta-data plugable both inside
the service and
in cli from u pov or is there any other alternative approach u may
suggest to create 
and control a custom network device in rhel8 in the way similar to
systemd network service in rhel7?

1) connection profiles of type "generic" are supposed to be only the IP
configuration of a linux netdev device. I guess, that currently does
not work as well as it should. That should be improvied. But it would
allow you to create the netdev device outside of NetworkManager, and
use NetworkManager to configure IP addresses on it. I think that could
still be useful, because then at least the IP configuration part
integrates with NetworkManager (e.g. you can use nm tools for
configuring IP/DHCP/DNS).

1b) possibly generic profiles could be extended to support some
plugins, basically to all an ifup/ifdown script to create the netdev.
However, creating such Plugin API is a tremendous effort.

Problem: generic profiles only work for IP configuration currently. And
it would be larger effort to make a generic plugin API that also can
handle configuring layer 2.

2) there is already such a plugin API: VPN plugins. There are some

   - The "VPN plugins" naming sounds like it would only be useful for
VPNs. But it is really a generic plugin infrastructure for any kind of
external device types. That is ugly and confusing, if the UI calls this
"connect to VPN", when it isn't. That would require effort to fix the
"notion" of this.

   - the implementation of VPN plugins has some ugliness. For example,
currently, VPN plugins are treated very special in NetworkManager, when
they should behave more like regular devices. This should be fixed
anyway, but again: it's hard and much effort to get a plugin
infrastucture right. Most of these issues are internal to
NetworkManager, it wouldn't directly affect the implementation of the
VPN plugins. That means, we need to fix these issues entirely in
NetworkManager, without breaking current VPN plugins (or breaking the
current VPN plugin API).

  - one specific example of a problem is that "connection.autoconnect"
doesn't work for VPN profiles, and "connection.secondaries" only works
with VPN profiles. Both concepts make sense in general, and VPN plugins
shouldn't be treated special. This should be fixed too.

Problem: the naming is actually the biggest problem. The other parts
are something that anyway should be improved.

3) the current "device plugins" in NetworkManager exist for splitting
dependencies of the core package (like NetworkManager-wifi package).
They don't exist so that you can maintain a device plugin outside NM's
source tree. In other words, the device plugins don't have a stable
API/API, unlike VPN plugins which have a stable API. Again, it would be
a tremendous effort to make "device plugins" have a stable ABI so that
they can be maintained separate from NetworkManager.

Problem: device plugins are great, but only if the code is part of
NetworkManager core.

Long term, I think it would be best to

 - improve generic profiles to better handle Layer 3 config only

 - the implementation of VPN plugins should see improvement.

 - maybe generic profiles should also support "plugins" for configuring
layer 2. In that case, the plugin part would be pretty much identical
to VPN plugins, but nicer from a naming point of view.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]