OS::Heat::ScalingPolicy alarm_url validate failed

Bug #1329270 reported by Hoang Do
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Heat
Invalid
Undecided
Unassigned

Bug Description

Hello guys,

I wonder is it a bug. I started a stack and get the alarm_url output of ScalingPolicy:

  ScaleUpURL:
    description: url to scale up
    value: { get_attr : [web_server_scaleup_policy, alarm_url] }

This is the output url:

http://176.31.105.64:8000/signal/arn:openstack:heat::704a532a5260484ba56b069b7219d3ff:stacks/wordpress3/5ce9fe67-3643-4ca0-9b95-e58c953098da/resources/web_server_scaleup_policy?Timestamp=2014-06-12T07:48:43Z&SignatureMethod=HmacSHA256&AWSAccessKeyId=6fadfed3020f4156be194824da3a3f8b&SignatureVersion=2&Signature=JWtPkySatWeJ7Wv7Jgm4PtA4tz4wwy6plkD7Yz+eIyE=

They I tried to trigged it by sending POST request, and got 404 error. I checked the heat-api-cfn.log and found out that a middleware tried to check the version of this link, and it failed:

2014-06-12 12:01:57.972 2690 DEBUG heat.api.middleware.version_negotiation [-] Processing request: POST /signal/arn:openstack:heat::704a532a5260484ba56b069b7219d3ff:stacks/wordpress3/5ce9fe67-3643-4ca0-9b95-e58c953098da/resources/web_server_scaleup_policy/v1.0 Accept: */* process_request /usr/lib/python2.7/dist-packages/heat/api/middleware/version_negotiation.py:53
2014-06-12 12:01:57.973 2690 DEBUG heat.api.middleware.version_negotiation [-] Unknown accept header: */*...returning HTTP not found. process_request /usr/lib/python2.7/dist-packages/heat/api/middleware/version_negotiation.py:104

I don't know if the URL is wrong or not. Then I tried to manually add version v1.0 to the link:

http://176.31.105.64:8000/v1.0/signal/arn:openstack:heat::704a532a5260484ba56b069b7219d3ff:stacks/wordpress3/5ce9fe67-3643-4ca0-9b95-e58c953098da/resources/web_server_scaleup_policy?Timestamp=2014-06-12T07:48:43Z&SignatureMethod=HmacSHA256&AWSAccessKeyId=6fadfed3020f4156be194824da3a3f8b&SignatureVersion=2&Signature=JWtPkySatWeJ7Wv7Jgm4PtA4tz4wwy6plkD7Yz+eIyE=

It passed the version check, then failed at AWS credential check:

2014-06-12 12:06:35.234 2690 INFO heat.api.aws.ec2token [-] Checking AWS credentials..
2014-06-12 12:06:35.234 2690 INFO heat.api.aws.ec2token [-] No AWS Signature found.
2014-06-12 12:06:35.235 2690 DEBUG root [-] XML response : <ErrorResponse><Error><Message>The request signature does not conform to AWS standards</Message><Code>IncompleteSignature</Code><Type>Sender</Type></Error></ErrorResponse> to_xml /usr/lib/python2.7/dist-packages/heat/common/wsgi.py:619

I don't use anything related to AWS, why there is an AWS check here?

Hoang Do (dohuyhoang88)
description: updated
description: updated
Revision history for this message
Steven Hardy (shardy) wrote :

I believe this is a misconfiguration in your heat.conf. Please check this setting:

heat_waitcondition_server_url = http://127.0.0.1:8000/v1/waitcondition

That's how I have heat configured (single node devstack environment) and curl -X POST to the alarm URL works fine.

So in your case this should probably be:

heat_waitcondition_server_url = http://176.31.105.64:8000/v1/waitcondition

The reason you see an AWS authentication failure is the pre-signed URL uses the ec2tokens authentication middleware, and you're accessing the Cloudformation-compatible API, which supports AWS style authentication.

FWIW, we should probably look at making the *url heat.conf options optional and by default using the keystone catalog entries instead, which would probably avoid these sort of misconfiguration problems in many cases.

Changed in heat:
status: New → Incomplete
Revision history for this message
Hoang Do (dohuyhoang88) wrote :

Thanks Steven,
Indeed I forgot to put "v1" to heat_waitcondition_server_url. After I put "v1" to the URL. The alarm link now have "v1" inside.
http://176.31.105.64:8000/v1/waitcondition

But that's just solve the first part of the problem. The second path is still the same, it failed at AWS check, do you have any idea why?

2014-06-13 10:30:15.120 15913 INFO heat.api.aws.ec2token [-] Checking AWS credentials..
2014-06-13 10:30:15.120 15913 INFO heat.api.aws.ec2token [-] No AWS Signature found.
2014-06-13 10:30:15.121 15913 DEBUG root [-] XML response : <ErrorResponse><Error><Message>The request signature does not conform to AWS standards</Message><Code>IncompleteSignature</Code><Type>Sender</Type></Error></ErrorResponse> to_xml /usr/lib/python2.7/dist-packages/heat/common/wsgi.py:619

Sorry for turning this into config supporting. Please help me delete this bug report.

Revision history for this message
Hoang Do (dohuyhoang88) wrote :

Sorry I missed the second part of your question.
I tried to bypass the ec2 check by removing ec2authtoken in pipeline:heat-api-cfn

#pipeline = cfnversionnegotiation ec2authtoken authtoken context apicfnv1app
pipeline = cfnversionnegotiation authtoken context apicfnv1app

I got stuck in keystone authen, perhaps due to the URL is generated for EC2 only. How can I config to generate URL supporting keystone token. I can't find any document for Heat config. Can you post all of your heat config as example.

Revision history for this message
Hoang Do (dohuyhoang88) wrote :

I managed to do it by request keystone for a token first, then call POST to the link by using:

curl -d '{tenantName": "name", "passwordCredentials": {"username": "xxx", "password": "xxx"}}}' -H "Content-type: application/json" http://keystoneURL:35357/v2.0/tokens

curl -H "X-Auth-Token:token" -X POST url

Thanks a lot Steven. Anyway, I hove we have signed URL like EC2 in Keystone to avoid making token request.

Revision history for this message
Steven Hardy (shardy) wrote :

> 2014-06-13 10:30:15.120 15913 INFO heat.api.aws.ec2token [-] No AWS Signature found.

This means either you're not using the full signed url from the alarm URL, or you need to quote it (to avoid the shell interpreting special characters like "&")

Revision history for this message
Steven Hardy (shardy) wrote :

Hi, you should not need the token request - the pre-signed URL is all you need, just like with EC2.

You should be able to do a request like:

curl -X POST "http://127.0.0.1:8000/v1/signal/arn%3Aopenstack%3Aheat%3A%3A39522d06854447359cf7c377a62b776d%3Astacks%2Fas1%2F7f74d0ca-972d-46df-a5f7-31893d066ea8%2Fresources%2Fsp?Timestamp=2014-06-12T16%3A53%3A30Z&SignatureMethod=HmacSHA256&AWSAccessKeyId=1cc9d2b1e9cd48ef9ae54b0b020b2fe1&SignatureVersion=2&Signature=51a8a3s8UtTFNUXC78bGbfBPrmYexltx9kc8Fja%2FYtQ%3D"

Note that the URL here is correctly encoded - Zane correctly pointed out that your example in the initial report is not, so please check if there is some problem with your local environment which could be causing that.

Revision history for this message
Hoang Do (dohuyhoang88) wrote :

Yes, you're right. My dummy mistake. I tried to decode the URL before POST, that's why it had authentication fail.
Thank you very much Steven.

Revision history for this message
Steven Hardy (shardy) wrote :

Ok, closing this invalid as per comment #7

Changed in heat:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.