Merge lp://qastaging/~andreserl/charms/quantal/mysql/ceph-support into lp://qastaging/~openstack-charmers/charms/quantal/mysql/hacluster-support

1) ceph-relation-changed

Should figure out if mysql is already running on ceph rbd and not stop, start mysql.

Just checking for the device presence should be enough.

The rbd kernel module will pickup changes in /etc/ceph/ceph.conf automagically.

2) Upgrade

The charm needs to move /var/lib/juju/*.passwd /var/lib/mysql on upgrade.

3) drbd.py

Drop as no longer used.

4) /etc/mysql/debian.cnf

Also needs to be synched from master server as contains debian sys maintenance password for upgrades.

5) shared-db-relations

The is_clustered/eligible_leader check is to complicated - the eligible leader check should be dealing with the is_clustered bit anyway:

    if not utils.eligible_leader():
        utils.juju_log('INFO',
                       'MySQL service is peered, bailing shared-db relation')
        return

This should be enough - am I the leader whatever the context? no - OK bail!

6) config.yaml

    vip:
        type: string
        default: None
        description: "Virtual IP to use to front keystone in ha configuration"

This is inconsistent with the rest of the charms which define this; I'd prefer if you dropped the 'default: None' and just checked for the vip like this:

   if 'vip' in config:
      ...

7) block-storage config option

Still don't like this - it can be inferred by looking at the relations a service has.

i.e. I kept forgetting to set it and ended up with a broken cluster!

One suggestion I have is to add shared-db relation settings to signify the service's cluster status, similar to the hacluster's use of 'clustered=yes' in its relation to its principle. If the clustered status + VIP get passed to client services via the relation, the other side of the relation can do something similar to:

[[ "$(relation-get clustered)" == "True" ]] && db_host="$(relation-get vip)" || db_host="$(relation-get private-address)"
db_conn=mysql://$user:$passwd@$db_host/$database

Services should make use of private-address from the environment instead of hostnames / address provided via relation-settings wherever possible. We're totally bending the rules currently to support the floating IPs/hacluster scenario, and I imagine it is going to break in environments with split-horizon DNS or complex routing setups. I'd like to avoid using something like 'db_host' via relation unless its absolutely required (in a clustered deployment), and use the private-address from environment in all other instances.

Adam

Not sure I agree; surely its the difference between doing the check on the mysql side (once) or the same check on the other end of the relation (many times).

Still need to sort out the mysql restarts in ceph changed and the syncing of files.

Lets do that as a separate MP.