Difference between revisions of "Neutron/ServiceDirectoryStructure"
< Neutron
(→1 generic plugin extended by drivers) |
|||
Line 50: | Line 50: | ||
Similar rules apply to unit test files, basically all service-related files are moved under tests/unit/services/service_category/ | Similar rules apply to unit test files, basically all service-related files are moved under tests/unit/services/service_category/ | ||
+ | <br /> | ||
+ | <br /> | ||
+ | |||
+ | ==== Final directory layout ==== | ||
+ | Example of loadbalancer naming and layout: | ||
+ | /db/ | ||
+ | /loadbalancer | ||
+ | loadbalancer_db.py | ||
+ | /common | ||
+ | plugin_constants.py (service types, constants shared between core and service plugins) | ||
+ | /services | ||
+ | /loadbalancer | ||
+ | /agents | ||
+ | /vendorA | ||
+ | vendorA_agent.py | ||
+ | /vendorB | ||
+ | vendorB_agent.py | ||
+ | /drivers | ||
+ | /vendorA | ||
+ | plugin_driver.py (plugin-side driver, could contain additional DB logic) | ||
+ | device_driver.py (driver to access a device, usually utilized by corresponding agent) | ||
+ | /db | ||
+ | loadbalancer_db.py | ||
+ | plugin.py (generic loadbalancer plugin based on loadbalancer_db.py and using plugin_drivers to allow vendor-specific architectures) |
Revision as of 11:19, 14 May 2013
This page describes possible source code tree structure for advanced services. Note that there could be 2 major approaches to writing service implementation of a certain kind:
- 1 generic plugin extended by drivers
- several separate plugins
1 generic plugin extended by drivers
The first proposed layout is for (1) which we're going to adopt for the loadbalancer service
/plugins /services /loadbalancer /agents /vendorA vendorA_agent.py /vendorB vendorB_agent.py /drivers /vendorA plugin_driver.py (plugin-side driver, could contain additional DB logic) device_driver.py (driver to access a device, usually utilized by corresponding agent) /db loadbalancer_db.py plugin.py (generic loadbalancer plugin based on loadbalancer_db.py and using plugin_drivers to allow vendor-specific architectures)
Note that currently loadbalancer directory is named agent_loadbalancer which points to a particular implementation.
To make it more generic, the following 2-step changes are proposed:
- Move loadbalancer_db.py out of quantum/db/loadbalancer/ to quantum/plugin/services/agent_loadbalancer/db/
- Rename agent_loadbalancer directory to loadbalancer. That would require changing many imports and also affects devstack hence it might be better to do it in separate step.
Options to consider:
1) move whole services tree up 1 level out of plugins
Several separate plugins
/plugins /services /vendorA_loadbalancer /agents vendorA_agent.py /drivers device_driver.py (driver to access a device, usually utilized by corresponding agent) /db vendorA_loadbalancer_db.py vendorA_plugin.py /vendorB_loadbalancer ...
Similar rules apply to unit test files, basically all service-related files are moved under tests/unit/services/service_category/
Final directory layout
Example of loadbalancer naming and layout:
/db/ /loadbalancer loadbalancer_db.py /common plugin_constants.py (service types, constants shared between core and service plugins) /services /loadbalancer /agents /vendorA vendorA_agent.py /vendorB vendorB_agent.py /drivers /vendorA plugin_driver.py (plugin-side driver, could contain additional DB logic) device_driver.py (driver to access a device, usually utilized by corresponding agent) /db loadbalancer_db.py plugin.py (generic loadbalancer plugin based on loadbalancer_db.py and using plugin_drivers to allow vendor-specific architectures)