Difference between revisions of "Neutron/ServiceDirectoryStructure"

Revision as of 12:50, 9 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/

@@ Line 4: / Line 4: @@
 * several separate plugins
- ==== 1 generic plugin extended by drivers ====
+==== 1 generic plugin extended by drivers ====
 The first proposed layout is for (1) which we're going to adopt for the loadbalancer service