Open Stack

Sumit,

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/
What you're proposing is something like:
services
    loadbalancer
        db
           loadbalancer_db.py
           vendor1_db_plugin.py
           vendor2_db_plugin.py
Am I correct?

Thanks,
Eugene.



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

> Inline...
>
> On Sun, May 5, 2013 at 8:27 PM, Eugene Nikanorov
> <enikanorov at mirantis.com> wrote:
> > 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.
>
> Sumit: How about the case when a particular loadbalancer plugin and/or
> driver want to create their own or augment the db model?
>
> >
> >> 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
> >
> >
> >
> > _______________________________________________
> > 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/bb7b0e43/attachment.html>