The nova.network.linux_net module that is responsible for a number of networking aspects of Nova is quite large and not very flexible in terms of code maintainance and portability, so it could have a refactor.
In addition to this, improving flexibility of the linux_net.py module will be a huge step forward towards FreeBSD host support, see the mailing list discussion for details .
Currently, nova.network.linux_net is responsible for a number of different things:
Network interface management (the code to manipulate bridges, adding/removing interfaces etc)
The linux_net.py file is almost 2k lines long, that’s not critically large, but could be smaller.
Some parts of it is flexible and allows overriding classes, for example linuxnet_interface_driver. Some parts are not, for example IptablesManager. Even for classes that allow overriding, there are consumers that use it directly, for example virt.libvirt.vif uses LinuxBridgeInterfaceDriver directly.
Also, there are some relatively similar blocks that do the same thing and could be grouped into functions, for example, LinuxBridgeInterfaceDriver and NeutronLinuxBridgeInterfaceDriver use almost identical code for bridge creation.
It would be good to improve code maintainability, readability and portability by refactoring the linux_net.py module.
The only type of audience that would benefit from this change is developers who work with linux_net.py and ones who are looking into extending Nova with new mechanisms for interface management, firewalling and related.
The proposed appoach would be:
Currently the usage of linux_net in libvirt.vif looks this way:
The following methods are used: - create_tap_dev() - create_ovs_vif_port() - create_ivs_vif_port() - device_exists() - delete_net_dev()
Usage of linux_net.LinuxBridgeInterfaceDriver methods: - ensure_vlan_bridge() - ensure_bridge()
One could notice this interface is pretty complex and actually it is responsible for two things at the same time:
Providing a Nova network API logic
Providing helpers for OS-level network device management
In order to make it more portable the proposal is to split out the OS-level helpers into its own entity and allow custom implementations for specific platform.
For example, it would look this way:
""" nova.network.netdev module """ def get_driver(): "Method returning platfrom specific implementation" if our_os == "Linux": return LinuxNetDevDriver else # not implemented # network device helpers def create_bridge(brname): return get_driver().create_bridge(brname) # other methods go here """ nova.network.netdev.driver """ class NetDevDriver(object): """A class that defines an interface for OS-level network device manipulation""" def create_bridge(self, brname): raise NotImplementedError # other methods go here """ nova.netowrk.netdev.linux """ class LinuxNetDevDriver(NetDevDriver): """A class that implements NetDevDriver interface for Linux""" def create_bridge(self, brname): # Linux impl goes here # other methods
The plan is:
Move out helper functions from linux_net to netdev
Convert consumers of these helper functions from linux_net to use the new netdev helpers
Drop the old implementation of helpers from linux_net
Move out Iptables related classes to its own module firewall and allow to override with actual class to be used so it was possible to use other firewall packages
Move out dnsmasq related code to its own module dhcp
Data model impact¶
REST API impact¶
Other end user impact¶
Other deployer impact¶
As the new option will be introduced that allows to specify the firewall class to use, deployers will be able to integrate third party firewalling packages. As this option will default to IptablesManager, there would be no changes to current deployments.
Developers will have a more readable, maintainable and extendible linux_net.py
- Primary assignee:
Refactor the interface management code
Split out the firewalling code
Split out the dnsmasq management code
Unit tests will be updated accordingly.