Guys,
I have a few small features / enhancements I'd like to suggest. I'm
willing to contribute the code / unit tests myself, but am looking for a
consensus from the group before I invest the time.
There are a few enhancements on my list -- I will send details each in a
separate email to keep the communication clearer.
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].
I'm thinking the same approach nova took:
(a) Add a conductor section to the trove-conductor.conf with a property
to specify the conductor manager class... e.g.
[conductor]
manager = package.of.conductor.manager.Manager
(b) Default trove's CONF value for conductor.manager to the existing
manager trove.conductor.manager.Manager which ensures backwards compat.
(c) In trove.cmd.conductor.py create the RpcService using the conf
value. e.g.
server = rpc_service.RpcService(manager=CONF.conductor.manager, topic=topic)
The above will allow consumers to extend / plug into the conductor
manager without upstream changes.
Any disagreement / comments on this enhancement? Again -- I can
contribute the code, unless someone is bored and wants to run with it
short-term.
Thanks
[1]
https://github.com/openstack/trove/blob/master/trove/cmd/conductor.py#L40
[2]
https://github.com/openstack/trove/blob/master/trove/cmd/conductor.py#L42
[3] https://github.com/openstack/nova/blob/master/nova/cmd/conductor.py#L43
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
