glance sync master #1


This charm is the master source of glance images that will be synced to other openstack installations.
It provides the image files as well as an accompanying metadata file containing any glance tags etc.
Slaves can register their public ssh keys with the master to be allowed rsync over ssh access.


The glance_sync_master charm provides a master source to sync glance images to other openstack installations.

It does this by syncing images and metadata from glance to disk from where they can be rsync-pulled from an glance_sync_slave unit.

The master has a list of command-limited authorized keys (juju config option) where slaves can be authorized.

Slave units regularly pull images from the master unit using rsync, the metadata that is rsynced as a separate json file contains the md5 checksum which the slave verifies before importing into their local glance store.

Image IDs are preserved across locations, this means no glance images should be created in a slave location to avoid ID conflicts.

One thing to note is that glance (by default) does not delete images. If you glance image-delete it will be removed from an image-list but not actually deleted from the database. A subsequent image-create with the same ID will lead to a conflict.

If an image is deleted from the masters glance instance, it will also be deleted from the local rsync directory which will propagate out to the slaves filesystem. But the slaves are currently not deleting images from their local glance stores.

Should a glance image accidentally get deleted from the master glance instance and subsequently from the slave, there would be no way to add the image back (with the same image ID) without manual DB surgery on both the slave and the master. We avoid this by not deleting images from slave glance instances as mentioned.

Glance credentials:

Both the glance-sync-master and glance-sync-slave units can pull admin credentials from their local glance instances through a keystone-admin relation. This can be overridden with custom novarc that can be set through a base64-encoded juju config setting. If a pre-existing custom novarc is removed the charm will fall back to using the relation and will display an error in juju status if neither are available.


juju deploy glance-sync-master

after the deploy, make sure to create an authorized_keys file for any slaves you want to authorize to sync.

example authorized_keys file:

command="rsync --server --sender -az . /srv/glance_sync_master/data/",no-X11-forwarding,no-port-forwarding,no-pty,no-agent-forwarding
command="rsync --server --sender -az . /srv/glance_sync_master/data/",no-X11-forwarding,no-port-forwarding,no-pty,no-agent-forwarding

juju set glance-sync-master authorized_keys=$(base64 -w 0 )

Then enable the sync which enables a sync cronjob on the master unit (in /etc/cron.d)

juju set glance-sync-master sync_enabled=True


(string) base64 encoded command limited authorized ssh keys file to authorize slave rsync calls
(string) directory to store image and metadata files
(string) base64 encoded novarc file
(string) Used by the nrpe-external-master subordinate charm. A string that will be prepended to instance name to set the host name in nagios. So for instance the hostname would be something like: juju-postgresql-0 If you're running multiple environments with the same services in them this allows you to differentiate between them.
(boolean) switch to enable or disable sync from master glance to disk
(string) directory to store scripts
(string) directory to store sync logfiles
(string) cron frequency for sync script
10 */3 * * *
(string) email address for notifications
(string) directory to store configuration like novarc
(string) base64 encoded SSL ca cert to use for OpenStack API client connections.