<div dir="ltr"><div style><span style="font-family:arial,sans-serif;font-size:13px">Salvatore, </span></div><div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><i><span style="font-family:arial,sans-serif;font-size:13px">> </span><span style="font-size:13px;font-family:arial,sans-serif">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.</span></i></div>
<div style><span style="font-size:13px;font-family:arial,sans-serif">Currently core plugins have their plugin-specific logic in their subdirs and only main DB plugin which is common, resides in DB. </span></div><div style>
<span style="font-size:13px;font-family:arial,sans-serif">I think the same logic applies for LB: it's common DB stuff is in services/loadbalancer directory.</span></div><div><br></div><div><span style="font-size:13px;font-family:arial,sans-serif"><i>> 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!</i></span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px">Well, I was just tired scrolling up and down from one LB file to another, and same for unit tests.</span></div><div style><br></div><div style><i>> <span style="font-family:arial,sans-serif;font-size:13px">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.</span></i></div>
<div style><font face="arial, sans-serif">Good idea. May be we should do it especially while there is not too much in services.</font></div><div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">Thanks,</font></div>
<div style><font face="arial, sans-serif">Eugene.</font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 3, 2013 at 7:59 PM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Replies inline.<div>Salvatore<br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">
On 3 May 2013 07:11, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I've filed bug/1175745 to perform the following file tree change in quantum/lbaas:</div>
<div>1) quantum/db/loadbalancer/loadbalancer_db.py -> quantum/plugins/services/agent_loadbalancer/loadbalancer_db.py</div>
<div>2) quantum/tests/unit/db/loadbalancer/test_db_loadbalancer.py -> quantum/tests/unit/services/agent_loadbalancer/test_db_loadbalancer.py<br></div><div>3) quantum/tests/unit/test_loadbalancer_plugin.py -> quantum/tests/unit/services/agent_loadbalancer/test_loadbalancer_extension.py<br>
</div><div><br></div><div>__init__.py left in db/loadbalancer and tests/unit/db/loadbalancer/ are removed.</div><div>Loadbalancer extension remains in extensions directory</div></div></blockquote><div><br></div></div><div>
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.</div><div>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!</div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>
<br></div><div>As a second step, which will be separate bug, I suggest the following name changes in services:</div><div>quantum/plugins/services/agent_loadbalancer -> quantum/plugins/services/loadbalancer</div>
<div>and corresponding renaming of unit tests subdir<br></div></div></blockquote><div><br></div></div><div>Nothing to object here.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div></div><div><br></div><div>The intent of this renaming is to show that this implementation is in fact multivendor. </div><div>It's not at this moment, but multivendor support will be implemented using current plugin, so</div>
<div>I'd also rename agent->agents and driver->drivers.</div><div>Under agents I would move current files under namespace_agent subdir. </div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>Under drivers I'd move current files under haproxy_on_host (or something similar)</div></div></blockquote><div><br></div></div><div>I think this makes sense.</div><div>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.</div>
<div>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. </div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div><br></div><div>All these changes target the following file tree pattern for services:</div><div>plugins</div><div> services</div><div> service_type (loadbalancer, fw)</div><div>
agents</div><div> vendor_specific_agent (vendor or implementation-specific)</div><div> drivers</div><div> vendor_specific_agent</div><div> this_service_type_db_plugin.py</div>
<div> alt_service_type_implementation</div><div> whatever (including possible alternative DB plugin)</div></div></blockquote><div><br></div></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><div dir="ltr"><div><br></div><div>I'd suggest the same pattern for the unit tests.</div>
<div><br></div><div>Thanks,</div><div>Eugene.</div></div>
<br></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></blockquote></div><br></div></div></div>
<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></blockquote></div><br></div>