I've also submitted a similar fix in the nova-compute branch that aims to avoid service restarts [1]. Your fix would still result in calls to set_or_update() for every rabbit servce unit expected in the loop. With the changes I've proposed to track config changes, would result in unnecessary service restarts. My proposed fix instead iterates through all hosts before setting rabbit_host accordingly.
I'm not sure either are ideal, though. In the case that we have multiple nodes but not clustered, looping through all services like this will result in quantum.conf pointing to a different rabbit_host than nova.conf (which is set from a amqp-relation-changed triggered from the rabbit leader). I wonder if we should just set quantum.conf's rabbit settings to what is currently set in nova.conf instead of inspecting existing relations?
James-
I've also submitted a similar fix in the nova-compute branch that aims to avoid service restarts [1]. Your fix would still result in calls to set_or_update() for every rabbit servce unit expected in the loop. With the changes I've proposed to track config changes, would result in unnecessary service restarts. My proposed fix instead iterates through all hosts before setting rabbit_host accordingly.
I'm not sure either are ideal, though. In the case that we have multiple nodes but not clustered, looping through all services like this will result in quantum.conf pointing to a different rabbit_host than nova.conf (which is set from a amqp-relation- changed triggered from the rabbit leader). I wonder if we should just set quantum.conf's rabbit settings to what is currently set in nova.conf instead of inspecting existing relations?
[1] https:/ /code.launchpad .net/~gandelman -a/charms/ precise/ nova-compute/ avoid_restarts/ +merge/ 157483