Open Stack

On Wed, 2012-08-08 at 16:35 -0400, Eric Windisch 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

That is true. That, presumably, is why we didn't have a default for
connection_type and don't have one now for compute_driver.

We also default to sqlite when clearly we expect real deployments to
chose MySQL or Postgres.

> * A default skews the practical testing scenarios, ensuring maturity
> of one driver over others.

The default is more likely to be tested, yet.

> * The kombu driver does not work "out of the box", so it is no more
> reasonable as a default than impl_fake.

The fake driver does not "work" out of the box either, except maybe in
the case of nova-all.

I'd actually prefer no default rather than fake.

> * The RPC code is now in openstack-common, so addressing this later
> will only create additional technical debt.

It will be harder to change after we release this code as the
oslo-messaging library, yes.

> 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.

Russell makes a very valid point about backwards compat. Configuration
files where the user hasn't specified rpc_backend will no longer work.
That's something we want to avoid doing without good reason.

I'm a fan of sane defaults. Rabbit isn't a sane default for anyone who
has rabbitmq-server running, Qpid is a sane default for anyone with
qpidd running and I guess ZeroMQ is sane for anyone with zeromq
installed. Can we just do the right thing if rpc_backend isn't set?

Similarly, I'd love to try and have a sane default for compute driver -
e.g. detect if there's a local libvirtd running or whatever.

Also, in the cases of compute driver, database and messaging we have
multiple implementations that we consider equally well supported. Dan
Prince has helped make sure all of those options are tested using
Smokestack, but we still have a greater emphasis on particular
implementations because of what devstack-gate uses.

</waffle>

On the whole, I think I'm persuaded. Having no default is better than
defaulting to rabbit. The compute driver default and the fact we default
to sqlite sets a precedent that makes sense to follow here. A
deprecation period helps with the backwards compat concerns.

We should handle the deprecation issue by making nova warn if
rpc_backend isn't set. It probably makes sense to just make it required
right away for e.g. Cinder, Quantum and Glance though.

Cheers,
Mark.