[openstack-dev] [Trove] Pluggable conductor manager

Craig Vyvial cp16net at gmail.com
Tue Jun 3 03:30:08 UTC 2014


Sent that a little too quickly...

This is to be more inline with the other services we have ie. taskmanager
[1] that you can override if you see fit. We decided this was an oversight
from the original creation and should be added.

[1]
https://github.com/openstack/trove/blob/master/trove/cmd/taskmanager.py#L26

-Craig


On Mon, Jun 2, 2014 at 10:27 PM, Craig Vyvial <cp16net at gmail.com> wrote:

> This is to be more inline with the other services we have ie. taskmanager
> [1] that you can override if you see fit.
>
>
>
> On Mon, Jun 2, 2014 at 3:55 PM, Russell Bryant <rbryant at redhat.com> wrote:
>
>> On 06/02/2014 09:23 AM, boden wrote:
>> > On 4/28/2014 2:58 PM, Dan Smith wrote:
>> >>> I'd like to propose the ability to support a pluggable trove conductor
>> >>> manager. Currently the trove conductor manager is hard-coded [1][2]
>> and
>> >>> thus is always 'trove.conductor.manager.Manager'. I'd like to see this
>> >>> conductor manager class be pluggable like nova does [3].
>> >>
>> >> Note that most of us don't like this and we're generally trying to get
>> >> rid of these sorts of things. I actually didn't realize that
>> >> conductor.manager was exposed in the CONF, and was probably just done
>> to
>> >> mirror other similar settings.
>> >>
>> >> Making arbitrary classes pluggable like this without a structured and
>> >> stable API is really just asking for trouble when people think it's a
>> >> pluggable interface.
>> >>
>> >> So, you might not want to use "because nova does it" as a reason to add
>> >> it to trove like this :)
>> >>
>> >> --Dan
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >>
>> >>
>> >
>> > Thanks for the input Dan.
>> >
>> > Is the real concern here that the conductor API(s) and manager are
>> > coupled based on version?
>>
>> FWIW, I really don't like this either.
>>
>> I snipped some implementation detail proposals here.  I missed why you
>> want to do this in the first place.  This seems far from an obvious plug
>> point to me.
>>
>> --
>> Russell Bryant
>>
>> _______________________________________________
>> 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/20140602/894cbec8/attachment-0001.html>


More information about the OpenStack-dev mailing list