[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