>>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).
dhcp/firewall/ (and others possible sdn services (balancer, vrouters,...) can be managed by external sdn controllers (ovs/ovn , opencontrail, openflow/opendaylight). So maybe this need like for storages, some kind of integration through api >> 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.. for ovs, I think ovn project in the right way to manage it at cluster level http://openvswitch.org/support/slides/OVN-Vancouver.pdf we could still manage the ovs switch locally, and the ovn controller manage the vxlan, routing, flow, ... I think we have 2 kind of setup: - basic local vswitch (bridge, ovs, snabwitch,....) : can be easily setup with systemd-network + some tap/eth plug/unplug scripts. - bigger sdn setup, with external controllers. (which could manage networks across multiple proxmox clusters too) ----- Mail original ----- De: "Fabian Grünbichler" <f.gruenbich...@proxmox.com> À: "pve-devel" <pve-devel@pve.proxmox.com> Envoyé: Mardi 2 Janvier 2018 11:55:05 Objet: Re: [pve-devel] proxmox 2018 : add support for "virtual" network and network plugins ? 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.. _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
