Difference between revisions of "Neutron/ServiceDirectoryStructure"
< Neutron
Line 41: | Line 41: | ||
/vendorB_loadbalancer | /vendorB_loadbalancer | ||
... | ... | ||
+ | |||
+ | <br /> | ||
+ | |||
+ | Similar rules apply to unit test files, basically all service-related files are moved under tests/unit/services/service_category/ |
Revision as of 08:41, 7 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 king:
- 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)
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/