0

We're deploying OpenStack Kilo using Mirantis Fuel 7.0 and so far the system seems to be working. We've added the ceilometer component and heat to make it possible for our users to upscale or downscale automatically some LoadBalancer servers we use on our stacks.

The automatic up and downscaling seem to be working well. The only problem is when we go to check the resources in the Orchestration tab, the generated WebHook points to the Management URL (192.168.0.2:8000) instead of pointing to the same string with the public URL or (preferibly) the server name.

What should look something like this:

 https://<serverPublicIP>:8000/v1/[...]

Looks like this:

 https://192.168.0.2:8000/v1/[...]

I've checked the port (8000) and it's open and listening on the public endpoint, so the problem is not with the service but with the component that generates the info. In fact, if I manually copy the address and edit the right IP, it works from outside the environment using a Restful client or simply a web browser.

But we need the generated webhook to automatically use the public URL so our customers can make calls from external applications (not from our OpenStack/horizon installation only) to modify the stack state.

I've checked heat config under /etc/heat/heat.conf and can find some suspicious settings like:

heat_metadata_server_url=http://192.168.0.2:8000
heat_waitcondition_server_url=http://192.168.0.2:8000/v1/waitcondition
heat_watch_server_url=http://192.168.0.2:8003
auth_uri = http://192.168.0.2:5000/v2.0
auth_host = 192.168.0.2

Not sure which one of these parameters may be the one it's used to generate the webhook.

I've tryied modifying them using the public IP and the name of the server itself, doesn't seems to make any difference. The webhooks on the user interface still point to the controller internal IP in the management network.

animaletdesequia
  • 35
  • 8

1 Answers1

1

That's the configuration for autoscaling alarm webhook url and it should have worked. Just wanted to know

  1. Did you restarted the HEAT engine once after re-configuring with the public IP
  2. After reconfiguration, have you tried out with a new stack instead of existing one ? Because existing stack & its corresponding scaling alarm created in ceilometer won't be modified with this config change.
Jayaprakash
  • 703
  • 6
  • 15
  • I tried exactly that, restarting heat services (all of them, just in case) and creating a new Stack from a local file. We're having some problems with configs not being applied when there should be (and we've modified quite a few .conf, including heat) so I'll try again rebooting the whole controller node this time. Thanks! – animaletdesequia May 06 '16 at 06:28