Currently we have a allowed_rpc_exception_modules configuration variable
which we use to configure a per-project list of modules which we will
allow exceptions to be instantiated from when deserializing remote
errors.
It makes no sense for this to be user configurable, instead the list of
modules should be set when you create a transport.
Closes-Bug: #1031719
Change-Id: Ib40e92cb920996ec5e8f63d6f2cbd88fd01a90f2
If a remote endpoint raises an exception which the client is not allowed
to (or cannot) deserialize, then RPCClient.call() raises a RemoteError
exception instead.
Make this exception type part of the public API.
Change-Id: I70be0ab7d40af3224d93d6bd0522c1a82f6303c3
I typically avoided using e.g. assertIsNone() thinking we couldn't use
it on 2.7, but now that we use testtools.TestCast there are a bunch of
useful assertion methods we can use.
Change-Id: I7696dc4744cdfd2466773326f202bc08dcfcbf0f
These are pretty comprehensive tests for the exception serialization
code. The code itself code do with a bunch of refactoring, but that will
come later.
The main TODO item is that we need a way for users of the API to
register the list of modules that it wants to allow exceptions to be
deserialized from. There is no need for this to be an end-user
configuration option, but we do need each service to be able to specify
its own list.
Change-Id: Ib2fc3f1ca5da708b41bdc00e8ac6ce0c92399ce8
