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 <cp16...@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 <rbry...@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@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 >> > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev