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@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev