Difference between revisions of "Neutron/ServiceDirectoryStructure"

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/