On Sun, Apr 9, 2017 at 2:56 PM, ~Stack~ <[log in to unmask]> wrote:
> On 04/08/2017 10:48 PM, Steven Haigh wrote:
>> On 09/04/17 12:59, Nico Kadel-Garcia wrote:
>>> In case it's unclear I am *not* happy with NetworkManager for servers
>>> or stable environments. Laptops that have to wander from environment
>>> to environment need multiple VPN's, yeah, OK, I can see having a more
>>> complex tool. But for a VM? Or a server?
>>
>> Yep - I've gone as far as removing NetworkManager completely from my
>> servers.
>>
>> A few months ago I drank the koolaid and set up nmcli with my Xen server
>> - and it was a pain in the backside. Finally got it working, but it
>> still decided to drop the bridging interfaces randomly (causing all VMs
>> to disconnect from the network) and wouldn't bring them back up.
>>
>> I ended up reverting to manually creating ifcfg-* config files and
>> scrapping all plans of migrating to anything NetworkManager.
>>
>> The down side is that you lose the network-online target for systemd -
>> which can cause its own problems - but its worth working around those
>> for a stable network config.
>>
>
> At a conference in 2015, I attended a couple of presentations by RH
> employees. On one day, a RH employee gave a talk I attended. In the
> Question time at the end, he made a tangent comment about how
> NetworkManager should never be disabled because RH was focused on making
> it an enterprise reliable networking tool. The VERY NEXT DAY he gave a
> talk regarding OpenStack & Kubernetes, and I kid you not, one of the
> first comments was "disable NetworkManager" and use the old networking
> tools!
>
> I right then called him out on it. He handled it very well. :-)
One of them actually gets work done. One of them..
> The short, he reiterated that RH is committed to NetworkManager first as
> a enterprise reliable networking tool. He admitted there were
> shortcomings and that there were known issues where it didn't work well
> (virtual networks with OpenStack for example), but that he fully
> expected many of the kinks to be worked out "soon". He hoped and was
> expectant that NetworkManager would be a full replacement before EL7
> stopped getting feature updates. He made the disclosure that he can't
> predict the future and speak completely for RH but that he was
> absolutely confident that EL8 would not have anything but NetworkManger.
>
> That isn't the first, nor the last time I've heard that. At
> Supercomputing 2016 in Salt Lake City, a RH employee made a similar
> comment as well (again not in official capacity ect ect).
Then I think they misunderstand how NetworkManager works. Take a look,
It *writes* the configuration information, which are what are actually
written and processed, in /etc/sysconfig/network-scripts/* . It makes
changes to the operating network by reading from those configuration
tools. If necessary, I can dig into the SRPM's for NetworkManager from
the Fedora rawhide release candidates to get a handle on where RHEL is
going with this.
> Assuming they are right, it looks like I am going to have it as a future
> tool. Add to it a current project in which the client is specifically
> asking for integration with it AND the potential for Infiniband (which
> NetworkManager is supposed to handle well), and I find myself needing to
> learn it now.
NetworkManager provides a management and reconfiguration toolkit on
top of the actual scripts, much like "yum" or the newer "dnf" provide
management of RPM deployment. But the availability of neither tool
blocks the use of direct RPM access to component management, and in
fact the *need* for hands-on localization to prevent the management
tool from making under-documented, unwanted, inappropriate, and
destabilizing assumptions for local setups.
As I said, it has its uses. It can do a useful job for frequently
changing or dynamic setups, like switching laptops to different VPN's
or localized option settings. And the use of it in anaconda, during
installation time, is understandable because your average installer
doesn't have the knowledge of the local network to hand-write config
files, so a GUI and some auto-discovery can be invaluable for simple
setup.
> At least one good thing has come from me studying this weekend. I
> discovered the reason behind one of the oddities in networking on our
> KVM server. So that was a plus! :-)
>
> Thanks!
> ~Stack~
>
|
