<div dir="ltr">Hi Sumit,<div><br></div><div><i>> <span style="font-family:arial,sans-serif;font-size:13px"> </span><span style="font-family:arial,sans-serif;font-size:13px">If we indeed decided to move it out of that directory, I</span></i></div>
<i><span style="font-family:arial,sans-serif;font-size:13px">would think, it would be much more intuitive to have a</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">services/loadbalancer/db hierarchy</span></i><div style>
<span style="font-family:arial,sans-serif;font-size:13px">That might be a choice as well, but db plugin has a 'db' in it's name and also it seems to be the only file to be such directory, so may be storing it in </span><span style="font-family:arial,sans-serif;font-size:13px">services/loadbalancer/ is enough.</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><i><span style="font-family:arial,sans-serif;font-size:13px">> </span><span style="font-family:arial,sans-serif;font-size:13px">In general, if we are moving some</span></i></div>
<i><span style="font-family:arial,sans-serif;font-size:13px">service related code artifacts, we should probably consider moving all</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">of them such that you can find everything related to that service</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">under it's top level directory.</span></i><div style><font face="arial, sans-serif">That's what I'm trying to achieve!</font></div><div style><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Thanks,</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Eugene.</span></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, May 6, 2013 at 12:52 AM, Sumit Naiksatam <span dir="ltr"><<a href="mailto:sumitnaiksatam@gmail.com" target="_blank">sumitnaiksatam@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi, What is the consensus on moving the LB-specific DB out of<br>
quantum/db? If we indeed decided to move it out of that directory, I<br>
would think, it would be much more intuitive to have a<br>
services/loadbalancer/db hierarchy. In general, if we are moving some<br>
service related code artifacts, we should probably consider moving all<br>
of them such that you can find everything related to that service<br>
under it's top level directory.<br>
<br>
Thanks,<br>
~Sumit.<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, May 3, 2013 at 9:53 AM, Eugene Nikanorov<br>
<<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>> wrote:<br>
> Salvatore,<br>
><br>
>> I am not very keen in moving the db logic out of the db package. Users<br>
>> will have to scrape through several levels of directories to find that<br>
>> module.<br>
> Currently core plugins have their plugin-specific logic in their subdirs and<br>
> only main DB plugin which is common, resides in DB.<br>
> I think the same logic applies for LB: it's common DB stuff is in<br>
> services/loadbalancer directory.<br>
><br>
>> So I don't think this simplifies the data structure. Unless, of course,<br>
>> you're doing this move as preparation for taking all the LB stuff out of<br>
>> quantum!<br>
> Well, I was just tired scrolling up and down from one LB file to another,<br>
> and same for unit tests.<br>
><br>
>> I have half a thought of taking this whole tree out of plugins - which<br>
>> will contain only the core plugins, and have all the service under a<br>
>> service_plugins directory.<br>
> Good idea. May be we should do it especially while there is not too much in<br>
> services.<br>
><br>
> Thanks,<br>
> Eugene.<br>
><br>
><br>
> On Fri, May 3, 2013 at 7:59 PM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>><br>
> wrote:<br>
>><br>
>> Replies inline.<br>
>> Salvatore<br>
>><br>
>><br>
>> On 3 May 2013 07:11, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> I've filed bug/1175745 to perform the following file tree change in<br>
>>> quantum/lbaas:<br>
>>> 1) quantum/db/loadbalancer/loadbalancer_db.py -><br>
>>> quantum/plugins/services/agent_loadbalancer/loadbalancer_db.py<br>
>>> 2) quantum/tests/unit/db/loadbalancer/test_db_loadbalancer.py -><br>
>>> quantum/tests/unit/services/agent_loadbalancer/test_db_loadbalancer.py<br>
>>> 3) quantum/tests/unit/test_loadbalancer_plugin.py -><br>
>>> quantum/tests/unit/services/agent_loadbalancer/test_loadbalancer_extension.py<br>
>>><br>
>>> __init__.py left in db/loadbalancer and tests/unit/db/loadbalancer/ are<br>
>>> removed.<br>
>>> Loadbalancer extension remains in extensions directory<br>
>><br>
>><br>
>> I am not very keen in moving the db logic out of the db package. Users<br>
>> will have to scrape through several levels of directories to find that<br>
>> module.<br>
>> So I don't think this simplifies the data structure. Unless, of course,<br>
>> you're doing this move as preparation for taking all the LB stuff out of<br>
>> quantum!<br>
>><br>
>>><br>
>>><br>
>>> As a second step, which will be separate bug, I suggest the following<br>
>>> name changes in services:<br>
>>> quantum/plugins/services/agent_loadbalancer -><br>
>>> quantum/plugins/services/loadbalancer<br>
>>> and corresponding renaming of unit tests subdir<br>
>><br>
>><br>
>> Nothing to object here.<br>
>><br>
>>><br>
>>><br>
>>> The intent of this renaming is to show that this implementation is in<br>
>>> fact multivendor.<br>
>>> It's not at this moment, but multivendor support will be implemented<br>
>>> using current plugin, so<br>
>>> I'd also rename agent->agents and driver->drivers.<br>
>>> Under agents I would move current files under namespace_agent subdir.<br>
>>><br>
>>> Under drivers I'd move current files under haproxy_on_host (or something<br>
>>> similar)<br>
>><br>
>><br>
>> I think this makes sense.<br>
>> I am just thinking aloud here - so forgive me if this is nonsense: it<br>
>> seems a single solution for the LB plugin migth have a driver only, a driver<br>
>> and an agent, or perhaps only an agent.<br>
>> So, unless we're thinking fo re-using drivers and agents for different<br>
>> solutions (like 2 distinct solutions with the same HAproxy driver), perhaps<br>
>> we might have a directory for each 'solution' which will contain the agent<br>
>> and the driver.<br>
>><br>
>>><br>
>>><br>
>>> All these changes target the following file tree pattern for services:<br>
>>> plugins<br>
>>>   services<br>
>>>      service_type (loadbalancer, fw)<br>
>>>         agents<br>
>>>             vendor_specific_agent (vendor or implementation-specific)<br>
>>>         drivers<br>
>>>             vendor_specific_agent<br>
>>>         this_service_type_db_plugin.py<br>
>>>         alt_service_type_implementation<br>
>>>             whatever (including possible alternative DB plugin)<br>
>><br>
>><br>
>> I have half a thought of taking this whole tree out of plugins - which<br>
>> will contain only the core plugins, and have all the service under a<br>
>> service_plugins directory.<br>
>><br>
>>><br>
>>><br>
>>> I'd suggest the same pattern for the unit tests.<br>
>>><br>
>>> Thanks,<br>
>>> Eugene.<br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>