[openstack-dev] [Trove] Pluggable conductor manager

boden boden at linux.vnet.ibm.com
Mon Jun 2 13:23:49 UTC 2014


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?

If so what if we took a versioned factory approach? For example:
(a) In conf specify the version to use (by default) and a mapping from 
version to conductor factory:

conductor_version = 1.1
conductor_factory = 1.0:trove.conductor.v1.factory.Factory, 
1.1:trove.conductor.v1_1.factory.Factory


(b) Define an abstract base factory which can create manager(s) and 
api(s) for a specific version:

class AbstractFactory(object):

     @staticmethod
     def manager_classname(manager_id=None):
         raise NotImplementedError()

     @staticmethod
     def api_classname(api_id=None):
         raise NotImplementedError()

     @staticmethod
     def version():
         raise NotImplementedError()


(c) For each version, define a concrete factory. For example in trove 
for version 1.0:

class Factory(AbstractFactory):

     @staticmethod
     def manager_classname(manager_id=None):
         return 'trove.conductor.manager.Manager'

     @staticmethod
     def api_classname(api_id=None):
         return 'trove.conductor.api.API'

     @staticmethod
     def version():
         return '1.0'


(d) Impl a simple interface to the factories so consumers can get a 
factory instance to work with. e.g.:

factory = Factories.factory() # get factory based on conductor_version
conductor_mgr = factory.manager_classname() # 1.1 manager
conductor_api = factory.api_classname() # 1.1 API

# use std import utils to load objects...


Would such an approach mitigate some of your concerns? If not please 
elaborate your desired means. Also please keep in mind I'm proposing the 
above for trove conductor (at least initially).

Thanks





More information about the OpenStack-dev mailing list