oslo.messaging

531 Commits

15 Branches

18 Tags

34 MiB

Tree: 5be1b6a6a9

Commit Graph

Author	SHA1	Message	Date
Christian Berendt	5be1b6a6a9	Enabled hacking checks H305 and H307 * H305 imports not grouped correctly * H307 like imports should be grouped together Change-Id: I08dafc4fa150d2213b2bb002da7c9ee0ee517fac	8 years ago
Doug Hellmann	7b13bc1888	Update ExpectedException handling Catch expected exceptions in a way that supports subclasses also being seen as "expected." Log a little more detail about unexpected exceptions in the ExecutorBase so it is easier to add them to the list of expected exceptions. Change-Id: I1bdd628eba717308f0afe1a889efd8711bad6296 Closes-bug: #1276163	8 years ago
Mark McLoughlin	f6df32d943	Add API for expected endpoint exceptions Review I4e7b19dc730342091fd70a717065741d56da4555 gives a lot of the background here, but the idea is that some exceptions raised by an RPC endpoint method do not indicate any sort of failure and should not be logged by the server as an error. The classic example of this is conductor's instance_get() method raising InstanceNotFound. This is perfectly normal and should not be considered an error. The new API is a decorator which you can use with RPC endpoints methods to indicate which exceptions are expected: @messaging.expected_exceptions(InstanceNotFound) def instance_get(self, context, instance_id): ... but we also need to expose the ExpectedException type itself so that direct "local" users of the endpoint class know what type will be used to wrap expected exceptions. For example, Nova has an ExceptionHelper class which unwraps the original exception from an ExpectedException and re-raises it. I've changed from client_exceptions() and ClientException to make it more clear it's intent. I felt that the "client" naming gave the impression it was intended for use on the client side. Change-Id: Ieec4600bd6b70cf31ac7925a98a517b84acada4d	9 years ago

Author

SHA1

Message

Date

Christian Berendt

5be1b6a6a9

Enabled hacking checks H305 and H307

* H305  imports not grouped correctly
* H307  like imports should be grouped together

Change-Id: I08dafc4fa150d2213b2bb002da7c9ee0ee517fac

8 years ago

Doug Hellmann

7b13bc1888

Update ExpectedException handling

Catch expected exceptions in a way that supports subclasses also being
seen as "expected."

Log a little more detail about unexpected exceptions in the ExecutorBase
so it is easier to add them to the list of expected exceptions.

Change-Id: I1bdd628eba717308f0afe1a889efd8711bad6296
Closes-bug: #1276163

8 years ago

Mark McLoughlin

f6df32d943

Add API for expected endpoint exceptions

Review I4e7b19dc730342091fd70a717065741d56da4555 gives a lot of the
background here, but the idea is that some exceptions raised by an RPC
endpoint method do not indicate any sort of failure and should not be
logged by the server as an error.

The classic example of this is conductor's instance_get() method raising
InstanceNotFound. This is perfectly normal and should not be considered
an error.

The new API is a decorator which you can use with RPC endpoints methods
to indicate which exceptions are expected:

    @messaging.expected_exceptions(InstanceNotFound)
    def instance_get(self, context, instance_id):
        ...

but we also need to expose the ExpectedException type itself so that
direct "local" users of the endpoint class know what type will be used
to wrap expected exceptions. For example, Nova has an ExceptionHelper
class which unwraps the original exception from an ExpectedException and
re-raises it.

I've changed from client_exceptions() and ClientException to make it
more clear it's intent. I felt that the "client" naming gave the
impression it was intended for use on the client side.

Change-Id: Ieec4600bd6b70cf31ac7925a98a517b84acada4d

9 years ago

3 Commits (5be1b6a6a93e2be1fd6adef109a016f49ed98b0a)