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