Minimal install diff from F16 to F19 (TC6)

Glen Turner gdt at gdt.id.au
Mon Jun 24 17:09:01 UTC 2013


On 24/06/2013, at 9:00 PM, Chris Adams wrote:

> Once upon a time, Glen Turner said:
>> What we don't want is a scenario where configuring these protocols on servers has to be done by network engineers. We want them configured from a GUI and supervised by a master daemon. Let's call that "NetworkManager".
> 
> You think hundreds of servers (with untold numbers of VMs), or any
> complicated networking setups, are going to each have their network
> configuration managed by a GUI?

In that case I think the sysadmin will do what they do now. Run the GUI on their development box, look at the underlying NetworkManager configuration files it created, generalise them, and then farm them out using puppet.

What I am arguing against is the current situation where a server administrator has to configure each element of a network configuration, in one configuration file per protocol. It's bad enough as it is now, without data centre networking exploding the number of protocols seen by a VM host. The router experience has been that per-protocol configuration is a dead end. The lesson appears to be that it is better to deploy software which directly addresses use-cases (thus explaining some of the hype around OpenFlow). I see NetworkManager as the best tool to do that job on Linux.

To deploy a new network service you deploy the NetworkManager plugin, its dependencies, and a lightweight configuration file written by the NM GUI. I'd hope for a plugin ecosystem, since the number of use cases, and the variations on those, is pretty large.

With a use-case approach rather than a protocol configuration approach junior sysadmins don't also need to be network engineers in order to deploy networking features -- ranging from a protocol nightmare like MPLS-based data centre networking; to anycast networking for DNS; to IPVS and HA failover. This sort of mechanism also gives the opportunity to promote good practices which aren't done because they are too hard: such as placing management traffic in a preferenced tc class which will allow device management connectivity during a DoS, or running LLDP on physical interfaces to allow simple discovery of cabling mistakes; from the sysadmins point of view they just enable those plugins. Note that these are runtime plugins -- not configuration-time "wizards" -- if you have multiple plugins requiring the services of the BGP protocol then they should both succeed.

-glen

-- 
  Glen Turner <http://www.gdt.id.au/~gdt/>


More information about the devel mailing list