On Wed, Jun 27, 2012 at 9:47 PM, Mark McClain <mark.mccl...@dreamhost.com>wrote:
> All- > > I've had the same conversation with several you about the DHCP agent and > the use of the client lib. I'd thought I move the discussion over here. > > > The current method It is definitely not my preferred way to solve this > problem long term. For F3, I want to add RPC support to Quantum. > Messaging would help improve the various agents we now have in the > codebase. Specifically, it will help the dhcp agent because it can be more > efficient (i.e. won't have to constantly poll for changes or use the client > lib to create a port for itself).the network. > > The implementation posted today requires the client lib. It's how the DHCP > server gets a port for itself and it's why jenkins fails (there isn't a way > to specify a client lib that's not in pypi). > Sorry, looks like this email was stuck in my drafts folder.... Hey Mark, I think there are (at least) two high-level ways of thinking about how to implement DHCP with Quantum: 1) External Service: Build a standalone service that uses only public web service interfaces to implement DHCP in a way that is completely agnostic to the plugin (i.e., no direct database access). Doing this would probably require the completion of the quantum notifications blueprint ( https://blueprints.launchpad.net/quantum/+spec/quantum-notifications) so there is a standard public interface to learn about the creation of new ports. This type of notification infrastructure will also be needed for other type of services, such as ceiliometer. 2) Library used by Plugin: Build library code that makes it really easy for a plugin agent to implement DHCP capability. This would include libraries for configuring and invoking a DHCP back-end like dnsmasq, which would be integrated into the plugin. Thus, the plugin could use internal mechanisms (e.g., direct database access) for learning about the creation of new ports, or even to create those new ports. I think #1 is the ideal approach long-term, as it decouples the DHCP from the plugin itself. Its technically possible now (your code could use an admin user to query all ports on a regular interval via the webservice API), but something like a notifications API seems necessary to make it efficient. Taking this approach requires that the quantumclient code is a dependency. I actually think that this will be fairly common as Quantum grows to include more higher level network services that conceptually "plug" into port on Quantum networks. In terms of testing, it definitely is possible to reference a git repo within the tools/pip-requires. You should just be able to add a line like: -e git+ https://github.com/openstack/python-quantumclient.git#egg=python-quantumclient Dan > Thoughts? > > mark > > > -- > Mailing list: https://launchpad.net/~netstack > Post to : netstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~netstack > More help : https://help.launchpad.net/ListHelp > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
