alarm urls created by Heat are ec2-signed, so changing them after they have been created is not an option as this invalidates them.
Instead (see [0]) we should pick the right combination of options in heat.conf and keystone catalog entries to make sure the url created by Heat can be accessed by aodh
It would seem, that picking the right options might involve some trade-offs still. E.g. we could force Heat to create alarm urls on private API endpoints, but then waitconditions will most probably not work (as there is no routing from tenant's network to control plane network) and by doing so we effectively would prohibit manual scaling from outside of the cloud. I remember I had some round-off of trade-offs somewhere prepped some time ago, will try to find it.
alarm urls created by Heat are ec2-signed, so changing them after they have been created is not an option as this invalidates them.
Instead (see [0]) we should pick the right combination of options in heat.conf and keystone catalog entries to make sure the url created by Heat can be accessed by aodh
It would seem, that picking the right options might involve some trade-offs still. E.g. we could force Heat to create alarm urls on private API endpoints, but then waitconditions will most probably not work (as there is no routing from tenant's network to control plane network) and by doing so we effectively would prohibit manual scaling from outside of the cloud. I remember I had some round-off of trade-offs somewhere prepped some time ago, will try to find it.
[0] https:/ /github. com/openstack/ heat/blob/ master/ heat/engine/ resources/ signal_ responder. py#L146- L152