delete non-existent alarm return incorrect faultstring

[ZhiQiang Fan]

trigger http conflict for alarm-create then delete a non-existent alarm will return incorroct faultstring

version info:
os=sles-11-sp3
ceilometer=2013.2.2.dev13.g9149861-2.1
ceilometerclient=1.0.6-4.2

reproduce steps:

# ceilometer --debug alarm-create --name ac --meter-name instance --threshold 1
# ceilometer --debug alarm-create --name ac --meter-name instance --threshold 1
{"error_message": {"debuginfo": null, "faultcode": "Client", "faultstring": "Alarm with that name exists"}}
HTTPBadRequest (HTTP 400)

# ceilometer --debug alarm-delete -a alarm-does-not-exist
{"error_message": {"debuginfo": null, "faultcode": "Server", "faultstring": "Alarm with that name exists"}}
Alarm not found: alarm-does-not-exist

the rest api return http response with body which has incorrect faultstring

[ZhiQiang Fan (aji-zqfan)]

I added some log in the calling stack to trace the problem, and found that ceilometer returns proper dict which will be formatted to http response, the last log I captured is in wsmeext.pecan.wsexpose, it showes that when an EntityNotFount(Exception) is captured, it will return the dict which I expected, in that dict, faultstring is correct. However, the next process is not logged and the final http response's body has been modified to the incorrect faultstring.

It is verified that no matter the specific error, just a wsme.exc.ClientSideError raised in alarm_create will trigger this problem, for i.e. type=combination and the depended alarm does not exist. Once this problem is triggered, the faultstring will spin in it and no longer correct.

This is also found in Ubuntu 12.04 Ceilometer 2013.2.1

Any help?

[ZhiQiang Fan (aji-zqfan)]

check with devstack stable/havana branch, this problem is still there

[ZhiQiang Fan (aji-zqfan)]

this problem is not found in 2014.1 in devstack environment, and I noticed that wsme and pecan is updated to higher version in master branch