[Openstack] Making the RPC backend a required configuration parameter

Sean Dague sdague at linux.vnet.ibm.com
Wed Aug 8 21:52:01 UTC 2012


On 08/08/2012 05:00 PM, Andrew Clay Shafer wrote:
> On Wed, Aug 8, 2012 at 4:35 PM, Eric Windisch <eric at cloudscaling.com
> <mailto:eric at cloudscaling.com>> wrote:
>
>     I believe that the RPC backend should no longer have any default
>
>     Historically, it seems that the Kombu driver is default only because
>     it existed before all others and before there was an abstraction.
>     With multiple implementations now available, it may be time for a
>     change.
>
>     Why?
>     * A default skews the attitudes and subsequent architectures toward
>     a specific implementation
>
>
>     * A default skews the practical testing scenarios, ensuring maturity
>     of one driver over others.
>     * The kombu driver does not work "out of the box", so it is no more
>     reasonable as a default than impl_fake.
>     * The RPC code is now in openstack-common, so addressing this later
>     will only create additional technical debt.
>
>     My proposal is that for Folsom, we introduce a "future_required"
>     flag on the configuration option, "rpc_backend". This will trigger a
>     WARNING message if the rpc_backend configuration value is not set.
>       In Grizzly, we would make the rpc_backend variable mandatory in
>     the configuration.

Regardless of the actual default in openstack-common, the devstack 
default is going to skew all of this as well (if not more so), and 
devstack does need a default. Much like db backend.

I would also assume that Packagers are going to need to set a default in 
their packages.

While I have no objection to this change, I'm not sure it accomplishes 
the goal if it just means the default is set elsewhere, and 90% of 
people are all running with the same implementation anyway.

	-Sean

-- 
Sean Dague
IBM Linux Technology Center
email: sdague at linux.vnet.ibm.com
alt-email: sldague at us.ibm.com





More information about the Openstack mailing list