Hide Forgot
The quickstack manifests for configuring OpenStack controllers provides two boolean parameters to enable/disable the heat_cfn and heat_cloudwatch services. If set to true, the services are correctly started on the controller. If they then set back to false, the services are not stopped on the controller as they should. Another side-effect of toggling the heat_cfn boolean is that the heat::keystone::auth class is called with different parameters. Specifically, not setting the endpoint addresses for heat_cfn causes them to default to 127.0.0.1. Changing the value of the heat_cfn boolean is seen as a change to the endpoint address, and a new endpoint is created with the new address. This is arguably a problem with the keystone puppet module, but this can be mitigated but calling heat::keystone::auth class with same params regardless of heat_cfn boolean. Expected behavior is that toggling heat_cfn and/or heat_cloudwatch boolean parameters should enable/disable (and start/stop) the services accordingly. Also, toggling heat_cfn on/off should not cause a new endpoint to be created.
Created attachment 834442 [details] Fix enable/disable of heat_cfg and heat_cloudwatch This patch modifies the heat_controller.pp manifest such that the heat_cfn and heat_cloudwatch services are enabled/disabled per the heat_cfn and heat_cloudwatch boolean parameters. Previously, once either boolean had been set to true the services would be running on the controller, but reverting either parameter to false would not stop/disable the service. This patch also fixes the call to the heat::keystone::auth class such that the heat_cfn endpoints are always created with the correct IP addresses.
With heat_cfn and heat_cloudwatch parameters initially set to false in a controller hostgroup, the services should be stopped and disabled: # chkconfig --list openstack-heat-api-cfn openstack-heat-api-cfn 0:off 1:off 2:off 3:off 4:off 5:off 6:off # chkconfig --list openstack-heat-api-cloudwatch openstack-heat-api-cloudwatch 0:off 1:off 2:off 3:off 4:off 5:off 6:off # service openstack-heat-api-cfn status heat-api-cfn is stopped # service openstack-heat-api-cloudwatch status heat-api-cloudwatch is stopped Also check that a single endpoint exists for the cloudformation service and the URLs have the correct IP addresses: # keystone endpoint-get --service cloudformation --endpoint-type publicURL +--------------------------+-----------------------------+ | Property | Value | +--------------------------+-----------------------------+ | cloudformation.publicURL | http://10.15.85.144:8000/v1 | +--------------------------+-----------------------------+ # keystone endpoint-get --service cloudformation --endpoint-type internalURL +----------------------------+--------------------------------+ | Property | Value | +----------------------------+--------------------------------+ | cloudformation.internalURL | http://192.168.101.144:8000/v1 | +----------------------------+--------------------------------+ # keystone endpoint-get --service cloudformation --endpoint-type adminURL +-------------------------+--------------------------------+ | Property | Value | +-------------------------+--------------------------------+ | cloudformation.adminURL | http://192.168.101.144:8000/v1 | +-------------------------+--------------------------------+ Set both heat_cfn and heat_cloudwatch parameters to true and reapply. Both services should now be running and enabled: # chkconfig --list openstack-heat-api-cfn openstack-heat-api-cfn 0:off 1:off 2:on 3:on 4:on 5:on 6:off # chkconfig --list openstack-heat-api-cloudwatch openstack-heat-api-cloudwatch 0:off 1:off 2:on 3:on 4:on 5:on 6:off # service openstack-heat-api-cfn status heat-api-cfn (pid 10579) is running... # service openstack-heat-api-cloudwatch status heat-api-cloudwatch (pid 10692) is running... Also check that changing heat_cfn from false to true did not result in additional keystone enpoint: # keystone endpoint-get --service cloudformation +--------------------------+-----------------------------+ | Property | Value | +--------------------------+-----------------------------+ | cloudformation.publicURL | http://10.15.85.144:8000/v1 | +--------------------------+-----------------------------+ Set both heat_cfn and heat_cloudwatch parameters back to false and reapply. Both services should not be stopped and disabled: # chkconfig --list openstack-heat-api-cfn openstack-heat-api-cfn 0:off 1:off 2:off 3:off 4:off 5:off 6:off # chkconfig --list openstack-heat-api-cloudwatch openstack-heat-api-cloudwatch 0:off 1:off 2:off 3:off 4:off 5:off 6:off # service openstack-heat-api-cfn status heat-api-cfn is stopped # service openstack-heat-api-cloudwatch status heat-api-cloudwatch is stopped
Upstream pull request: https://github.com/redhat-openstack/astapor/pull/79
Merged, this should get into the next build
Test results are in comment #3.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2013-1859.html