Standalone network node class
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
- Status:
- Complete
- Approver:
- None
- Priority:
- High
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- Mark T. Voelker
- Definition:
- Approved
- Series goal:
- Accepted for grizzly
- Implementation:
-
Implemented
- Milestone target:
-
g.2
- Started by
- Mark T. Voelker
- Completed by
- Mark T. Voelker
Related branches
Related bugs
Sprints
Whiteboard
This blueprint is similar to https:/
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.
https:/
There is an accompanying changes to core.pp and site.pp have been added to this branch:
https:/
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: https:/
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-
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
