<div dir="ltr">Sent that a little too quickly...<div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">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.</span><div class="" style="font-family:arial,sans-serif;font-size:13px">
</div></div><div><br></div><div>[1] <a href="https://github.com/openstack/trove/blob/master/trove/cmd/taskmanager.py#L26">https://github.com/openstack/trove/blob/master/trove/cmd/taskmanager.py#L26</a></div><div><br></div>
<div>-Craig</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 2, 2014 at 10:27 PM, Craig Vyvial <span dir="ltr"><<a href="mailto:cp16net@gmail.com" target="_blank">cp16net@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This is to be more inline with the other services we have ie. taskmanager [1] that you can override if you see fit. <div>
<br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 2, 2014 at 3:55 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 06/02/2014 09:23 AM, boden wrote:<br>
> On 4/28/2014 2:58 PM, Dan Smith wrote:<br>
>>> I'd like to propose the ability to support a pluggable trove conductor<br>
>>> manager. Currently the trove conductor manager is hard-coded [1][2] and<br>
>>> thus is always 'trove.conductor.manager.Manager'. I'd like to see this<br>
>>> conductor manager class be pluggable like nova does [3].<br>
>><br>
>> Note that most of us don't like this and we're generally trying to get<br>
>> rid of these sorts of things. I actually didn't realize that<br>
>> conductor.manager was exposed in the CONF, and was probably just done to<br>
>> mirror other similar settings.<br>
>><br>
>> Making arbitrary classes pluggable like this without a structured and<br>
>> stable API is really just asking for trouble when people think it's a<br>
>> pluggable interface.<br>
>><br>
>> So, you might not want to use "because nova does it" as a reason to add<br>
>> it to trove like this :)<br>
>><br>
>> --Dan<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
><br>
> Thanks for the input Dan.<br>
><br>
> Is the real concern here that the conductor API(s) and manager are<br>
> coupled based on version?<br>
<br>
</div>FWIW, I really don't like this either.<br>
<br>
I snipped some implementation detail proposals here.  I missed why you<br>
want to do this in the first place.  This seems far from an obvious plug<br>
point to me.<br>
<span><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span><div><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>