Launchpad Entry: https://code.launchpad.net/~midokura/nova/network-refactoring
Created: 15-6-2011
Network Refactoring
Ryu Ishimoto <ryu@midokura.jp>
Abstract
To allow external network services to be easily integrated into Nova, heavy refactoring work has to be done in the Nova networking code. The refactoring is broken down into two separate tasks: L2 service integration and L3 service integration. In the first step, we will refactor Nova such that external L2 services such as Quantum can be plugged in. This will be followed by L3 refactoring which will allow integration of L3 services like Melange to manage IP addresses. It is also imperative that the refactoring is done in such a way that it would have minimum effect on the current Nova users wishing to use the existing Nova networking services(Flat/FlatDHCP/Vlan). The purpose of this blueprint is to identify the challenges involved in achieving this goal, and to propose possible solutions to overcome these challenges.
The L2 refactoring is being worked on in the following branch:
https://code.launchpad.net/~midokura/nova/network-refactoring-l2
The rest of this document will concentrate on the L2 refactoring.
Contents
Database Changes
The refactoring will not modify the existing Nova database tables. The existing network-related tables will remain the same, and will be ignored by the services outside of Nova.
A new table to represent VIF has to be created:
+ id (PK) + vif_id + mac_address + instance_id + deleted, created_at, deleted_at, ...
Multi-NIC project already has a table called 'virtual_interfaces'. The plan is to use this table as the VIF table with Quantum. This table has a 'network_id' column with foreign key constraint to the Networks table of Nova. We will make this column nullable so that it can be used outside of Nova.
OpenStack REST API Changes
All the new OpenStack APIs will be implemented as extensions.
VIF list
A new extension API must be introduced to get a list of VIFs attached to an instance. The response should be a list of globally unique VIF IDs. The format of these IDs has not been decided. There has been a suggestion to use URL that includes the service end-point DNS name to guarantee uniqueness. The detail of this API is still under discussion.
VIF creation
The API to create a new instance should take in a number of VIFs to create for that instance. This will cause conflicts when merging with multi-NICs as its logic is to create VIFs for every Nova Network records that a project is associated with, and does not allow flexibility to specify the number of VIFs to create.
VIF network connectivity at VM launch
To allow connectivity at the time of instance launch, the API to create an instance must accept virtual port IDs as its parameter. These IDs represent the virtual ports that the VIFs plug into.
The new server create API parameters are:
vif_num: Number of VIFs to create for the instance.
port_ids: A list of port IDs plug the VIFs into at the time of launch.
The API should create the VIF records for the instance, and send the newly created vif_ids and port_ids to the Quantum API to indicate the logical binding.
Second proposal: Separation of instance definition and launch
Possibly a cleaner approach, though requiring more work, is to separate the instance definitions and the instance launching. A flag parameter would be added to the REST API call that indicates whether the API should launch the instance after the instance definitions are saved in the database. A new REST API called 'launch' would be added, and given instance_id, it simply asks the scheduler to find a host to launch the instance.
Virt Layer Changes
libvirt
Currently, Nova's libvirt driver only supports Linux bridge interface type. When integrating with external network services, Nova must be able to support other interface types. To achieve this, we adopt a VIF driver model proposed by Sumit Naiksatam here:
openstack-vif-configuration-SumitNaiksatam-v2.pdf
Each VIF driver is responsible for generating the interface configurations for libvirt, allowing flexibility and support for various interface types.
VIF driver
In the current implementation of Nova, the network setup on the compute host for each VIF is done in the setup_compute_network method of Network Manager classes. We feel that the setup should be done in the virt layer, and more specifically by the VIF drivers. In this refactoring, we move the responsibilities of network setup from Network Manager classes to VIF driver classes.
Network Managers
Nova's network managers will remain untouched other than the removal of setup_compute_network method. Network manager classes, however, do perform L2 networking setup on the network node. If a network service needs a different type of networking setup on the network node, it must extend the manager and override the method that does the setup.