rpc-api-review: behaviour of remote exceptions

[Mark McLoughlin]

Looking at this:

  https://review.openstack.org/#/c/25640/1/nova/exception.py

we see Nova making assumptions about how the rpc layer propagates remote exceptions:

  def format_message(self):
      if self.__class__.__name__.endswith('_Remote'):
          return self.args[0]
      else:
          return unicode(self)

Is this something we can handle better? It seems like pretty obscure semantics for us to make a commitment to retaining compatibility for

[Nikola Đipanov (ndipanov)]

Couple of points from me since I introduced the change in question:

The remote exception has to do 2 things (in addition to being an exception):
1. It has to carry information about the orriginal exception including type and trace
2. It has to make it clear to all involved that it is in fact a remote exception

There are a couple of aproaches to accomplishing this and all the usuall susupects are lined up here - RemoteExcetpion base class, special attriburtes for the stack trace and additional metadata, and finally - dinamically creating a type that ends with _Remote and raising it.

I personally see no advantages of one over the other at the moment - all would would mean that we have to couple Nova exceptions to Oslo superclass/attrbute/ending. The solution I opted for was least risky under the circumstances and, I felt, less evil.

Andrew Laski suggested on the original review that we should have an overreaching Exception type in Oslo that other projects will use as base, and will hide these details. This is good but also not ideal, as it wil introduce an esoteric and non standard exception interface which is imho an unecessary excercise.

A cleaner option imho is having a RemoteException that is internal to Oslo and known about all the other OpenStack components, and is raised when remote errors happen... but then I wonder how far away this is from .endswith('_Remote')

[Mark McLoughlin (markmc)]

Ok, we're sticking with this behaviour but committing to it as a stable part of the API

See http://docs.openstack.org/developer/oslo.messaging/rpcclient.html

  The semantics of how any errors raised by the remote RPC endpoint method
  are handled are quite subtle.

  Firstly, if the remote exception is contained in one of the modules listed in the
  allow_remote_exmods messaging.get_transport() parameter, then it this exception
  will be re-raised by call(). However, such locally re-raised remote exceptions are
  distinguishable from the same exception type raised locally becayse re-raised
  remote exceptions are modified such that their class name ends with the ‘_Remote’
  suffix so you may do:

      if ex.__class__.__name__.endswith('_Remote'):
          # Some special case for locally re-raised remote exceptions

  Secondly, if a remote exception is not from a module listed in the
  allowed_remote_exmods list, then a messaging.RemoteError exception is raised
  with all details of the remote exception.