Open Stack

Salvatore,

*> 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.*
Currently core plugins have their plugin-specific logic in their subdirs
and only main DB plugin which is common, resides in DB.
I think the same logic applies for LB: it's common DB stuff is in
services/loadbalancer directory.

*> 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!*
Well, I was just tired scrolling up and down from one LB file to another,
and same for unit tests.

*> 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.*
Good idea. May be we should do it especially while there is not too much in
services.

Thanks,
Eugene.


On Fri, May 3, 2013 at 7:59 PM, Salvatore Orlando <sorlando at nicira.com>wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/aa9c58c3/attachment.html>