Neutron/dhcp-flexi-model

Scope

The current implementation of the dhcp agent works so that dhcp services are provided by the same node where the dhcp agent is deployed and running on. An inspection to code reveals that the agent relies on the following elements:

• DHCP Driver: this is the component in charge of controlling DHCP for a tenant network. It is used to enable/disable DHCP and to check the status of the service on a network. The only currently available implementation is based on dnsmasq; dhcp services are thus provided by a dnsmasq daemon that gets spawned by the dhcp agent whenever there is a new network that requires DHCP services.
• RPC Plugin: this is the component in charge of the communication with the Neutron Server. It is used to retrieve the configuration for a specific network (e.g. CIDR, DHCP options, gateway, etc) and to reflect the mapping of the dhcp services with the neutron resources (e.g. logical ports).
• Device Manager: this is the component in charge of implementing (i.e. creating/destroying and (un)plugging) the physical resources needed for conveying DHCP messages to/from tenant VM's and the dnsmasq daemon.
• Lease Relay: this is the component in charge of conveying lease updates from the dhcp agent to the Neutron server (which might be removed soon due to this review).
• Network Cache: this is a component introduced for performance reasons and it is in charge of storing an in-memory mapping of all networks that are being managed by the dhcp agent.

Overall the agent main's task is to ensure that the view of the dhcp services needed by the Neutron infrastructure (pertaining the agent) is in sync with what the agent is implementing at a specific moment in time. The aim of this blueprint is to improve the dhcp agent structure to support a proxy-based model where DHCP services to tenant VM's are provided by an external service. In this new model the agent requires only the collaboration with the driver, the rcp plugin, the lease relay and the cache components. There is no real need for the agent to interact with the device manager, which can be seen as an implementation detail that is leaked out of the dhcp driver. As the code shows, there is nearly no interaction between the agent and the device manager, and the proposal of this blueprint is to encapsulate the use of the device manager within the DHCP driver so that if when a DHCP agent is configured to use a different DHCP driver, the administrator does not need to artificially set the device manager's interface driver config option to NullDriver. Other minor refactoring will be done to implement a higher degree of data encapsulation and separation of concerns.

Use Cases

To support the ability to use different dhcp drivers without the need to configure the device manager as well.