Open Stack

Hi Sumit,

*>  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*
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 services/loadbalancer/ is enough.

*> 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.*
That's what I'm trying to achieve!

Thanks,
Eugene.


On Mon, May 6, 2013 at 12:52 AM, Sumit Naiksatam
<sumitnaiksatam at gmail.com>wrote:

> 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
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130506/874c688b/attachment.html>