The 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 module will be a huge step forward towards FreeBSD host support, see the mailing list discussion for details [1].

Problem description

Currently, is responsible for a number of different things:

  • Network interface management (the code to manipulate bridges, adding/removing interfaces etc)

  • Firewall/Iptables management

  • dnsmasq management

The 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 module.

Use Cases

The only type of audience that would benefit from this change is developers who work with and ones who are looking into extending Nova with new mechanisms for interface management, firewalling and related.

Project Priority


Proposed change

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:

""" module

def get_driver():
    "Method returning platfrom specific implementation"
    if our_os == "Linux":
        return LinuxNetDevDriver
        # not implemented

# network device helpers
def create_bridge(brname):
    return get_driver().create_bridge(brname)

# other methods go here


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


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


Security impact


Notifications impact


Other end user impact


Performance 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.

Developer impact

Developers will have a more readable, maintainable and extendible



Primary assignee:


Work Items

  • Refactor the interface management code

  • Split out the firewalling code

  • Split out the dnsmasq management code




Unit tests will be updated accordingly.

Documentation Impact






Release Name