[openstack-dev] Quantum dhcp code questions
mark.mcclain at dreamhost.com
Thu Jan 3 19:40:09 UTC 2013
On Jan 3, 2013, at 4:11 AM, Wojciech Dec <wdec.ietf at gmail.com> wrote:
> Hi All,
> I wonder if someone could help out with a few newbie questions regarding the Quantum code, specifically the dhcp agent parts thereof as in: https://github.com/openstack/quantum/blob/master/quantum/agent/linux/dhcp.py
> 1. In general who instantiates/uses the DhcpBase class (a trawl through the Quantum and base openstack code didn't find any references past the test suite, but it clearly is needed to get things going)?
The DHCP agent looks in the dhcp_agent.ini file and instantiates the class that is declared in the dhcp_driver configuration option. Currently, there is only a version for dnsmasq. (There are incomplete implementations for ISC DHCP floating around the web).
> Then, a couple of questions on the some of the remaining code in dhcp.py: A number of functions (eg spawn_process() ) use the following pattern to decide what/if to configure something:
> for i, subnet in enumerate(self.network.subnets):
> 2. Am I correct in reading that network.subnets above is effectively out of the dict type as defined in RESOURCE_ATTRIBUTE_MAP in https://github.com/openstack/quantum/blob/master/quantum/api/v2/attributes.py ?
> Side note: If so then, I must admit that the use of the "dot notation" for dict access is something that caught me out, as at least to me it does not appear to be widely known python feature.
It's not a feature of python. The DHCP agent uses an internal wrapper that takes the unserialized json dictionaries and wraps them to provide attribute access to the keys.
> 3. In this type of function, where/how are the "subnets" getter and setter defined for the dhcp paramaters (ie where do the actual values come in from the config file that, say, is being used when configuring the dhcp component)?
The DHCP agent runs a separate process and gathers the network, subnet, and port information from Quantum server via RPC and/or notifications and then passes that information onto the DHCP driver to configure and manage the DHCP server for the network.
> 4. In terms of design, what if any were the reasons why the dhcp component not been designed more like a plugin?
It was designed to be very pluggable. All you need is another Python implementation that supports the interface defined in the DhcpBase class and change the dhcp_driver in the dhcp_agent.ini file to point to it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev