Difference between revisions of "Neutron/ServiceDirectoryStructure"
< Neutron
m (ThierryCarrez moved page Quantum/ServiceDirectoryStructure to Neutron/ServiceDirectoryStructure) |
|||
| (7 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
This page describes possible source code tree structure for advanced services. | 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 | + | Note that there could be 2 major approaches to writing service implementation of a certain kind: |
* 1 generic plugin extended by drivers | * 1 generic plugin extended by drivers | ||
* several separate plugins | * 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 | The first proposed layout is for (1) which we're going to adopt for the loadbalancer service | ||
| Line 24: | Line 24: | ||
plugin.py (generic loadbalancer plugin based on loadbalancer_db.py and using plugin_drivers to allow vendor-specific architectures) | 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.<br /> | ||
| + | To make it more generic, the following 2-step changes are proposed:<br /> | ||
| + | * Move loadbalancer_db.py out of quantum/db/loadbalancer/ to quantum/plugin/services/agent_loadbalancer/db/<br /> | ||
| + | * 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.<br /> | ||
| + | <br /> | ||
Options to consider:<br /> | Options to consider:<br /> | ||
1) move whole services tree up 1 level out of plugins<br /> | 1) move whole services tree up 1 level out of plugins<br /> | ||
| − | ==== | + | ==== Several separate plugins ==== |
/plugins | /plugins | ||
/services | /services | ||
| Line 45: | 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) | ||
| + | plugin.py (generic loadbalancer plugin based on loadbalancer_db.py and using plugin_drivers to allow vendor-specific architectures) | ||
Latest revision as of 15:54, 21 June 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)
plugin.py (generic loadbalancer plugin based on loadbalancer_db.py and using plugin_drivers to allow vendor-specific architectures)
