Open Stack

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
>