<div dir="ltr">Sumit,<div><br></div><div>I think in that case their db-augments will be stored in services/loadbalancer/impl_name (if it's really different plugin) or services/loadbalancer/drivers/vendor/</div><div style>
What you're proposing is something like:</div><div style>services</div><div style> loadbalancer</div><div style> db</div><div style> loadbalancer_db.py</div><div style> vendor1_db_plugin.py</div>
<div style> vendor2_db_plugin.py</div><div style>
Am I correct?</div><div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 6, 2013 at 9:13 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">Inline...<br>
<div class="im"><br>
On Sun, May 5, 2013 at 8:27 PM, Eugene Nikanorov<br>
<<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>> wrote:<br>
> Hi Sumit,<br>
><br>
>> 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<br>
> That might be a choice as well, but db plugin has a 'db' in it's name and<br>
> also it seems to be the only file to be such directory, so may be storing it<br>
> in services/loadbalancer/ is enough.<br>
<br>
</div>Sumit: How about the case when a particular loadbalancer plugin and/or<br>
driver want to create their own or augment the db model?<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
>> 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>
> That's what I'm trying to achieve!<br>
><br>
> Thanks,<br>
> Eugene.<br>
><br>
><br>
> On Mon, May 6, 2013 at 12:52 AM, Sumit Naiksatam <<a href="mailto:sumitnaiksatam@gmail.com">sumitnaiksatam@gmail.com</a>><br>
> wrote:<br>
>><br>
>> 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>
>><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<br>
>> > 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<br>
>> >> of<br>
>> >> quantum!<br>
>> > Well, I was just tired scrolling up and down from one LB file to<br>
>> > 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<br>
>> > 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>
>> >>><br>
>> >>> quantum/tests/unit/services/agent_loadbalancer/test_loadbalancer_extension.py<br>
>> >>><br>
>> >>> __init__.py left in db/loadbalancer and tests/unit/db/loadbalancer/<br>
>> >>> 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<br>
>> >> 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<br>
>> >>> 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<br>
>> >> 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),<br>
>> >> perhaps<br>
>> >> we might have a directory for each 'solution' which will contain the<br>
>> >> 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>
><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>