<div dir="ltr">Sumit, I'm okay with that. <div style><br></div><div style>Thanks,</div><div style>Eugene.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 6, 2013 at 11:06 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 Eugene, Thanks. I agree, we could potentially have a<br>
services/loadbalancer/impl_name/db structure. I still think we should<br>
probably have services/loadbalancer/db/loadbalancer_db.py (assuming we<br>
decide to move loadbalancer_db.py out of it's current place).<br>
<br>
Thanks,<br>
~Sumit.<br>
<br>
On Sun, May 5, 2013 at 11:50 PM, Eugene Nikanorov<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>> wrote:<br>
> Sumit,<br>
><br>
> I think in that case their db-augments will be stored in<br>
> services/loadbalancer/impl_name (if it's really different plugin) or<br>
> services/loadbalancer/drivers/vendor/<br>
> What you're proposing is something like:<br>
> services<br>
> loadbalancer<br>
> db<br>
> loadbalancer_db.py<br>
> vendor1_db_plugin.py<br>
> vendor2_db_plugin.py<br>
> Am I correct?<br>
><br>
> Thanks,<br>
> Eugene.<br>
><br>
><br>
><br>
> On Mon, May 6, 2013 at 9:13 AM, Sumit Naiksatam <<a href="mailto:sumitnaiksatam@gmail.com">sumitnaiksatam@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Inline...<br>
>><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<br>
>> > and<br>
>> > also it seems to be the only file to be such directory, so may be<br>
>> > storing it<br>
>> > in services/loadbalancer/ is enough.<br>
>><br>
>> 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>
>><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<br>
>> > <<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.<br>
>> >> >> Users<br>
>> >> >> will have to scrape through several levels of directories to find<br>
>> >> >> that<br>
>> >> >> module.<br>
>> >> > Currently core plugins have their plugin-specific logic in their<br>
>> >> > 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<br>
>> >> >> course,<br>
>> >> >> you're doing this move as preparation for taking all the LB stuff<br>
>> >> >> 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 -<br>
>> >> >> 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<br>
>> >> > much<br>
>> >> > in<br>
>> >> > services.<br>
>> >> ><br>
>> >> > Thanks,<br>
>> >> > Eugene.<br>
>> >> ><br>
>> >> ><br>
>> >> > On Fri, May 3, 2013 at 7:59 PM, Salvatore Orlando<br>
>> >> > <<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>><br>
>> >> >> 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>
>> >> >>><br>
>> >> >>> quantum/tests/unit/services/agent_loadbalancer/test_db_loadbalancer.py<br>
>> >> >>> 3) quantum/tests/unit/test_loadbalancer_plugin.py -><br>
>> >> >>><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.<br>
>> >> >> Users<br>
>> >> >> will have to scrape through several levels of directories to find<br>
>> >> >> that<br>
>> >> >> module.<br>
>> >> >> So I don't think this simplifies the data structure. Unless, of<br>
>> >> >> course,<br>
>> >> >> you're doing this move as preparation for taking all the LB stuff<br>
>> >> >> out<br>
>> >> >> of<br>
>> >> >> quantum!<br>
>> >> >><br>
>> >> >>><br>
>> >> >>><br>
>> >> >>> As a second step, which will be separate bug, I suggest the<br>
>> >> >>> 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<br>
>> >> >>> in<br>
>> >> >>> fact multivendor.<br>
>> >> >>> It's not at this moment, but multivendor support will be<br>
>> >> >>> 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<br>
>> >> >>> 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:<br>
>> >> >> it<br>
>> >> >> seems a single solution for the LB plugin migth have a driver only,<br>
>> >> >> 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<br>
>> >> >> 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<br>
>> >> >>> services:<br>
>> >> >>> plugins<br>
>> >> >>> services<br>
>> >> >>> service_type (loadbalancer, fw)<br>
>> >> >>> agents<br>
>> >> >>> vendor_specific_agent (vendor or<br>
>> >> >>> 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 -<br>
>> >> >> 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>
><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>