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/>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Reply via email to