Open Stack

Sumit, I'm okay with that.

Thanks,
Eugene.


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

> Hi Eugene, Thanks. I agree, we could potentially have a
> services/loadbalancer/impl_name/db structure. I still think we should
> probably have services/loadbalancer/db/loadbalancer_db.py (assuming we
> decide to move loadbalancer_db.py out of it's current place).
>
> Thanks,
> ~Sumit.
>
> On Sun, May 5, 2013 at 11:50 PM, Eugene Nikanorov
> <enikanorov at mirantis.com> wrote:
> > 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
> >
> >
> >
> > _______________________________________________
> > 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/dc9fff46/attachment.html>