228c9d63e5
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. Blueprint: linux-net-refactor Change-Id: I3c98445349bc82f63913bff90d2baf868c3f7007
243 lines
5.5 KiB
ReStructuredText
243 lines
5.5 KiB
ReStructuredText
..
|
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
|
License.
|
|
|
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
|
|
|
==========================================
|
|
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
|
|
=======
|
|
|
|
.. list-table:: Revisions
|
|
:header-rows: 1
|
|
|
|
* - Release Name
|
|
- Description
|
|
* - Liberty
|
|
- Introduced
|