[pve-devel] proxmox 2018 : add support for "virtual" network and network plugins ?

[Fabian Grünbichler]

On Sat, Dec 30, 2017 at 04:15:29PM +0100, Alexandre DERUMIER wrote:
> Hi everybody,
> 
> First, merry X-mas and happy new year to all proxmox team. 
> (You have made a great job in 2017, a lot of polish and cleanup to current proxmox code !).
> 
> 
> I looking for 2018, to add support for network plugins (like for storage), and "virtual networks".
> 
> 
> By virtual network, I mean, to be able to define new kind of sdn networks or abstract of "vmbr+vlan"
> for exapple
> 
> "customerA network"  -> which could be "vmbrX + vlan"
> "customerB network"  -> which could be "ovs vmbrX + vxlan"
> "customerC network"  -> which could be "ovs+dpdk"
> "customerD network"  -> which could be "another kind of network (opencontrail vrouter, vpp, snabswitch, midonet ..."
> 
> also be able to defined network range, that user could use by network.
> 
> and a Custom Plugin directory , like for storage, where users could defined they own plugins.
> 
> 
> 
> Something like /etc/pve/networks.cfg (like storage.cfg, with network-plugins-options)
> 
> 
> What do you think about it ?

sounds like a good idea in general IMHO, but needs to be well-prepared
and thought through. some initial brain storming results below..

maybe a first step might be to refactor the existing OVS and ifupdown
support into two basic plugins for (local) network management, and then
extend it to support systemd-networkd with a third plugin (since the
feature set and scope is very similar, this should be easy enough).
a fourth (or rather, first) base plugin implementing all the stuff that
falls into "here is a kernel netdev, do operation FOO" where the
underlying stack is not important is probably a good idea to reduce code
duplication ;)

a next step would then be to think about whether extending this API to
software defined non-local networks make sense, or whether we need a
more high-level split between local and cluster-wide network management
plugins (potentially with implementations of both for a single
technology?).

from the top of my head, the following functionality would be needed:
- link/device setup
-- physical devices
-- bridges
-- bonds
[ -- tunnels ? ]
- address and prefix assignment to devices
- route management
- guest device plug/unplug
- QoS/shaping

the following might be possible, but not sure whether we really want to
do them (now/soon):
- integration of SDN firewall functionality
- integration of custom or SDN DHCP server functionality

before writing actual code, it would probably be a good idea to discuss
scope and use cases with a bit more detail, and then define a plugin
interface (or interfaces if we split the APIs).

there is also the question of whether a cluster-wide networks.cfg makes
sense for the non-SDN config. I think auto-detecting existing
/etc/network/interfaces and systemd-networkd configurations is all that
is needed for the local config, and we only need a cluster-wide file for
the SDNs. OVS is a bit special in this regard, as we already have some
support for local OVS in /e/n/interfaces, so user might need to convert
this when switching to full blown OVS on a cluster level? we could
differentiate those two by generating interfaces.d files for OVS
networks defined via /etc/pve/networks.cfg or some mechanism like that?
the interfaces.d folder is currently not used at all by our
parser/writer..