Standalone network node class

Registered by Dileep Devireddy

In the N1KV solution, running DHCP Agent/Service only on controller node will limit the scalability of the solution. Need the ability to run multiple instances DHCP service outside controller node. To avoid resource conflicts, we should have the option to dedicate the compute node only for non-VM services like DHCP.
This option is in addition to the ability to run DHCP service on the controller node.

Blueprint information

Needs approval
Mark T. Voelker
Series goal:
Accepted for grizzly
Milestone target:
milestone icon g.2
Started by
Mark T. Voelker
Completed by
Mark T. Voelker

Related branches



This blueprint is similar to but different in the respect that this blueprint basically asks that nova-compute not be deployed on the nodes to which a dhcp agent is deployed. Essentially, it asks for dedicated network nodes that run only quantum services (though in this case we aren't looking for an L3 agent, just a DHCP agent...though I suspect the former would be useful to a lot of people as well).

Currently StackForge's puppet-openstack module doesn't have a high-level class definition for a dedicated network node, so that's probably the issue we want to tackle here. In the interim it may be possible to hack up a definition in site.pp that calls on the lower-level quantum classes in order to let the N1k team test.

Update: Yes, we do need the ability to run L3 agent till CSR is available.

[11-Aug-2013] I've worked up a standalone network node class to add to puppet-openstack that provides enough functionality to set up L3, DHCP, and OVS agents. I've sent the patch upstream as "work in progress" to begin gathering feedback from the community. To be accepted I expect I'll need to propose it against both master and stable/grizzly, and it'll probably need to have some tests added. There may also be some debate as to whether a network node class is necessary give thatn it really only requires calling lower-level quantum classes (as of now). However, what I've uploaded contains all the necessary functionality that we need today and can be used immediately if we need to make some forward progress in testing.

There is an accompanying changes to core.pp and site.pp have been added to this branch:

These have been tested and successfully bring up DHCP, L3, and OVS agents that are listed in the output of "quantum agent-list" on the control node.

I've also done an implementation that does not require upstream changes which can be found in the following branch:

I've done a separate branch because we need to discuss with upstream whether it's appropriate to have top-level classes for node types that can be built entirely with one of the lower-level classes or not. While it's logical that puppet-openstack have classes for common node types that make common use cases as easy to deploy as possible, it may be more overhead than it's worth to maintain node types that simply remove some of the complexity from underlying lower-level classes. We can review and potentially merge the bp/multi-dhcp-agent-squash branch immediately while that discussion happens upstream. A pull request has been issued here:


Work Items

Work items:
Investigate feasibility of calling lower-level quantum classes directly in site.pp as a short-term workaround: DONE
Add network node class to puppet-openstack with parameters for L3 and DHCP agents: INPROGRESS
Add support for new class to core.pp: INPROGRESS
Create sample network node definition in site.pp.example: INPROGRESS

This blueprint contains Public information 
Everyone can see this information.


No subscribers.