When a resource can't receive a signal, 500 error happened

[Haiwei Xu]

When trying to send a signal to a resource, I got this error:

$ heat resource-signal stack1 my_instance1
ERROR: Remote error: ResourceFailure Exception: Resource Server "my_instance1" [5920db4f-4f93-4e48-abfd-af464dafad61] Stack "stack1" [1ab862f4-97c4-44e7-877f-1450fdd6445b] is not able to receive a signal

The error log in h-api:

2014-07-22 19:20:55.535 TRACE root Traceback (most recent call last):
2014-07-22 19:20:55.535 TRACE root File "/opt/stack/heat/heat/common/wsgi.py", line 625, in __call__
2014-07-22 19:20:55.535 TRACE root request, **action_args)
2014-07-22 19:20:55.535 TRACE root File "/opt/stack/heat/heat/common/wsgi.py", line 699, in dispatch
2014-07-22 19:20:55.535 TRACE root return method(*args, **kwargs)
2014-07-22 19:20:55.535 TRACE root File "/opt/stack/heat/heat/api/openstack/v1/util.py", line 36, in handle_stack_method
2014-07-22 19:20:55.535 TRACE root return handler(controller, req, **kwargs)
2014-07-22 19:20:55.535 TRACE root File "/opt/stack/heat/heat/api/openstack/v1/util.py", line 52, in handle_stack_method
2014-07-22 19:20:55.535 TRACE root return handler(controller, req, dict(stack_identity), **kwargs)
2014-07-22 19:20:55.535 TRACE root File "/opt/stack/heat/heat/api/openstack/v1/resources.py", line 118, in signal
2014-07-22 19:20:55.535 TRACE root details=body)
2014-07-22 19:20:55.535 TRACE root File "/opt/stack/heat/heat/rpc/client.py", line 363, in resource_signal
2014-07-22 19:20:55.535 TRACE root details=details))
2014-07-22 19:20:55.535 TRACE root File "/opt/stack/heat/heat/rpc/client.py", line 50, in call
2014-07-22 19:20:55.535 TRACE root return client.call(ctxt, method, **kwargs)
2014-07-22 19:20:55.535 TRACE root File "/usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/client.py", line 389, in call
2014-07-22 19:20:55.535 TRACE root return self.prepare().call(ctxt, method, **kwargs)
2014-07-22 19:20:55.535 TRACE root File "/usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/client.py", line 152, in call
2014-07-22 19:20:55.535 TRACE root retry=self.retry)
2014-07-22 19:20:55.535 TRACE root File "/usr/local/lib/python2.7/dist-packages/oslo/messaging/transport.py", line 90, in _send
2014-07-22 19:20:55.535 TRACE root timeout=timeout, retry=retry)
2014-07-22 19:20:55.535 TRACE root File "/usr/local/lib/python2.7/dist-packages/oslo/messaging/_drivers/amqpdriver.py", line 404, in send
2014-07-22 19:20:55.535 TRACE root retry=retry)
2014-07-22 19:20:55.535 TRACE root File "/usr/local/lib/python2.7/dist-packages/oslo/messaging/_drivers/amqpdriver.py", line 395, in _send
2014-07-22 19:20:55.535 TRACE root raise result
2014-07-22 19:20:55.535 TRACE root RemoteError: Remote error: ResourceFailure Exception: Resource Server "my_instance1" [5920db4f-4f93-4e48-abfd-af464dafad61] Stack "stack1" [1ab862f4-97c4-44e7-877f-1450fdd6445b] is not able to receive a signal
2014-07-22 19:20:55.535 TRACE root [u'Traceback (most recent call last):\n', u' File "/opt/stack/heat/heat/engine/service.py", line 63, in wrapped\n return func(self, ctx, *args, **kwargs)\n', u' File "/opt/stack/heat/heat/engine/service.py", line 959, in resource_signal\n stack[resource_name].signal(details)\n', u' File "/opt/stack/heat/heat/engine/resource.py", line 901, in signal\n raise failure\n', u'ResourceFailure: Exception: Resource Server "my_instance1" [5920db4f-4f93-4e48-abfd-af464dafad61] Stack "stack1" [1ab862f4-97c4-44e7-877f-1450fdd6445b] is not able to receive a signal\n'].
2014-07-22 19:20:55.535 TRACE root

[Removed by request (removed3381998)]

If this bug is about getting an HTTP 500 response, then I don't see why it is a bug. The server has an issue and "is not able to receive a signal"

[Haiwei Xu (xu-haiwei)]

＠Amit Ugol

I think the RemoteError raised by oslo.messaging should be handled by heat-api, and raise an appropriate exception to the client, not 500.

[Steven Hardy (shardy)]

Agreed, 500 is never the right response, we should fix the exception mapping so the response code indicates it was a bad request.

[Clint Byrum (clint-fewbar)]

Excerpts from Steven Hardy's message of 2014-07-22 13:52:45 UTC:
> Agreed, 500 is never the right response, we should fix the exception
> mapping so the response code indicates it was a bad request.
>

I think 50x is appropriate. "Something awful happened". This was no
fault of the user. 503 would probably be the most accurate.

[Steven Hardy (shardy)]

> I think 50x is appropriate. "Something awful happened". This was no
fault of the user. 503 would probably be the most accurate.

FWIW I disagree - something awful didn't happen, someone sent a bad request, a signal to a resource which doesn't support signals, so it's user error.

The other option would be to silently discard the request, do nothing (because there's nothing to be done) and return 200 I guess?

Or, we return 501 and say "Not Implemented", but to me that indicates the server doesn't implement the thing at all, rather than the specific resource you're trying to access doesn't?

In any case 500 is not the right response, as heat didn't have any internal error.

[Steve Baker (steve-stevebaker)]

On 23/07/14 09:23, Steven Hardy wrote:
>> I think 50x is appropriate. "Something awful happened". This was no
> fault of the user. 503 would probably be the most accurate.
>
> FWIW I disagree - something awful didn't happen, someone sent a bad
> request, a signal to a resource which doesn't support signals, so it's
> user error.
>
> The other option would be to silently discard the request, do nothing
> (because there's nothing to be done) and return 200 I guess?
>
> Or, we return 501 and say "Not Implemented", but to me that indicates
> the server doesn't implement the thing at all, rather than the specific
> resource you're trying to access doesn't?
>
> In any case 500 is not the right response, as heat didn't have any
> internal error.
>
404 for a signal to a resource (or stack) which doesn't exist?
403 Forbidden, for signaling a resource which won't accept it?

[Clint Byrum (clint-fewbar)]

Excerpts from Steven Hardy's message of 2014-07-23 13:23:05 UTC:
> > I think 50x is appropriate. "Something awful happened". This was no
> fault of the user. 503 would probably be the most accurate.
>
> FWIW I disagree - something awful didn't happen, someone sent a bad
> request, a signal to a resource which doesn't support signals, so it's
> user error.
>
> The other option would be to silently discard the request, do nothing
> (because there's nothing to be done) and return 200 I guess?
>
> Or, we return 501 and say "Not Implemented", but to me that indicates
> the server doesn't implement the thing at all, rather than the specific
> resource you're trying to access doesn't?
>
> In any case 500 is not the right response, as heat didn't have any
> internal error.

OH! I was confused. I didn't realize that this was about sending signals
to resources that don't support signals. I thought "can't" meant a
general error.

404 is appropriate then.

[Steven Hardy (shardy)]

We already return 404 for a stack or resource which doesn't exist, this is only for when the resource does exist and doesn't support signals.

I think I'm going to go with 400, as that seems most appropriate - it's not 404 not found, and it's not 403 forbidden, it's just a request which is impossible to satisfy, thus matching the 400 definition from W3C, which says "The request had bad syntax or was inherently impossible to be satisfied."

Doing this results in (IMO) the most intuitive output from the client, which is:

heatclient.exc.HTTPBadRequest: ERROR: signal is not supported for resource.

This, to me at least, tells the user that their request was bad because the signal they tried to send is inappropriate for that particular resource.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/109096

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/109096
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=0909340b4ce49f25a8d858be9bb081fd163a4dab
Submitter: Jenkins
Branch: master

commit 0909340b4ce49f25a8d858be9bb081fd163a4dab
Author: Steven Hardy <email address hidden>
Date: Wed Jul 23 20:48:51 2014 +0100

    Appropriate exception for signal handling failure

    Raise an appropriate exception, mapped to a 400 error for signals
    to resources which cannot handle signals. In this case, the request
    is inherently impossible to satisfy, because the plugin doesn't
    support signals, so we should alert the user to this by saying it's
    a bad request (rather than the current response which is a 500 error)

    Change-Id: I8e47ee94e15309f378f62f2a9f6534a4eeddb389
    Closes-Bug: #1346849