Open Stack

Hi, What is the consensus on moving the LB-specific DB out of
quantum/db? If we indeed decided to move it out of that directory, I
would think, it would be much more intuitive to have a
services/loadbalancer/db hierarchy. In general, if we are moving some
service related code artifacts, we should probably consider moving all
of them such that you can find everything related to that service
under it's top level directory.

Thanks,
~Sumit.

On Fri, May 3, 2013 at 9:53 AM, Eugene Nikanorov
<enikanorov at mirantis.com> wrote:
> 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
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>