nova.network.linux_net refactor

https://blueprints.launchpad.net/nova/+spec/linux-net-refactor

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 [1].

Problem description

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)

  • Firewall/Iptables management

  • dnsmasq management

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.

Use Cases

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.

Project Priority

None

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:

"""
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

Alternatives

None

Data model impact

None

REST API impact

None

Security impact

None

Notifications impact

None

Other end user impact

None

Performance Impact

None

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 linux_net.py

Implementation

Assignee(s)

Primary assignee:

novel

Work Items

  • Refactor the interface management code

  • Split out the firewalling code

  • Split out the dnsmasq management code

Dependencies

None

Testing

Unit tests will be updated accordingly.

Documentation Impact

None

References

[1]: http://lists.openstack.org/pipermail/openstack-dev/2015-June/066342.html

History

Revisions

Release Name

Description

Liberty

Introduced