Juju Charms Collection
nova-compute package

Merge lp://staging/~james-page/charms/precise/nova-compute/quantum-mq-config into lp://staging/~openstack-charmers/charms/precise/nova-compute/ha-support

Proposed by James Page on 2013-04-09

Status:	Merged
Merge reported by:	James Page
Merged at revision:	not available
Proposed branch:	lp://staging/~james-page/charms/precise/nova-compute/quantum-mq-config
Merge into:	lp://staging/~openstack-charmers/charms/precise/nova-compute/ha-support
Diff against target:	25 lines (+8/-0) 1 file modified hooks/nova-compute-relations (+8/-0)
To merge this branch:	bzr merge lp://staging/~james-page/charms/precise/nova-compute/quantum-mq-config
Related bugs:	Link a bug report

Reviewer	Review Type	Date Requested	Status
Adam Gandelman (community)		2013-04-09	Needs Fixing on 2013-04-09
Review via email: mp+157863@code.staging.launchpad.net

Description of the change

Ensure clustered VIP is used if found on amqp relation.

Revision history for this message

Adam Gandelman (gandelman-a) wrote on 2013-04-09:

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