[openstack-dev] [Quantum][LBaaS] Loadbalancer files organisation
Salvatore Orlando
sorlando at nicira.com
Fri May 3 15:59:24 UTC 2013
Replies inline.
Salvatore
On 3 May 2013 07:11, Eugene Nikanorov <enikanorov at mirantis.com> wrote:
> Hi,
>
> I've filed bug/1175745 to perform the following file tree change in
> quantum/lbaas:
> 1) quantum/db/loadbalancer/loadbalancer_db.py ->
> quantum/plugins/services/agent_loadbalancer/loadbalancer_db.py
> 2) quantum/tests/unit/db/loadbalancer/test_db_loadbalancer.py ->
> quantum/tests/unit/services/agent_loadbalancer/test_db_loadbalancer.py
> 3) quantum/tests/unit/test_loadbalancer_plugin.py ->
> quantum/tests/unit/services/agent_loadbalancer/test_loadbalancer_extension.py
>
> __init__.py left in db/loadbalancer and tests/unit/db/loadbalancer/ are
> removed.
> Loadbalancer extension remains in extensions directory
>
I am not very keen in moving the db logic out of the db package. Users will
have to scrape through several levels of directories to find that module.
So I don't think this simplifies the data structure. Unless, of course,
you're doing this move as preparation for taking all the LB stuff out of
quantum!
>
> As a second step, which will be separate bug, I suggest the following name
> changes in services:
> quantum/plugins/services/agent_loadbalancer ->
> quantum/plugins/services/loadbalancer
> and corresponding renaming of unit tests subdir
>
Nothing to object here.
>
> The intent of this renaming is to show that this implementation is in fact
> multivendor.
> It's not at this moment, but multivendor support will be implemented using
> current plugin, so
> I'd also rename agent->agents and driver->drivers.
> Under agents I would move current files under namespace_agent subdir.
>
Under drivers I'd move current files under haproxy_on_host (or something
> similar)
>
I think this makes sense.
I am just thinking aloud here - so forgive me if this is nonsense: it seems
a single solution for the LB plugin migth have a driver only, a driver and
an agent, or perhaps only an agent.
So, unless we're thinking fo re-using drivers and agents for different
solutions (like 2 distinct solutions with the same HAproxy driver), perhaps
we might have a directory for each 'solution' which will contain the agent
and the driver.
>
> All these changes target the following file tree pattern for services:
> plugins
> services
> service_type (loadbalancer, fw)
> agents
> vendor_specific_agent (vendor or implementation-specific)
> drivers
> vendor_specific_agent
> this_service_type_db_plugin.py
> alt_service_type_implementation
> whatever (including possible alternative DB plugin)
>
I have half a thought of taking this whole tree out of plugins - which will
contain only the core plugins, and have all the service under a
service_plugins directory.
>
> I'd suggest the same pattern for the unit tests.
>
> Thanks,
> Eugene.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130503/4f06144d/attachment.html>
More information about the OpenStack-dev
mailing list