Merge lp://qastaging/~gandelman-a/charms/precise/rabbitmq-server/cluster_fix into lp://qastaging/charms/rabbitmq-server

Hi Adam

I gave this a try; the changes generally look OK BUT I do hit issues when `relation-get private-address` returns an IP address instead of a hostname; this will happen when using the openstack and local providers so I think the charm needs to deal with this as well.

Cheers

James

Excerpts from James Page's message of 2012-12-07 10:03:27 UTC:
> Review: Needs Fixing
>
> Hi Adam
>
> I gave this a try; the changes generally look OK BUT I do hit issues when `relation-get private-address` returns an IP address instead of a hostname; this will happen when using the openstack and local providers so I think the charm needs to deal with this as well.
>

Smells like something for charm helper to do.

the sh/net.sh helper already has a 'ch_is_ip' that uses awk to test if the input is an ipv4 address.

Even better would be something like

ch_relation_get_private_ip

and

ch_unit_get_private_ip

Which would hide all the details of turning that into an IP.

I've reverted the charm's peer relations back to their previous behavior. Turns out, when clustering peers, rabbitmq needs to address its peers by the peers' node name, which is the local hostname of that system. Using anything else (IP, FQDN, CNAME) wont work. This is why the original hook passed output of `hostname` across the relation as the hostname and did not use anything from the provider. I've tested on both the EC2 and OSAPI provider and clustering works as expected.