Hi, 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 task.
"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 parameter 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 problems: - 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. best, Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part