Open Stack

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
>