glance sync #4
Description
This charm will sync Glance images between OpenStack installations. In master mode, the charm will provide image files and an accompanying metadata file, containing any glance tags, etc. In slave mode, the charm can register its public SSH keys with the master, in order to be allowed rsync over SSH access, in order to sync the images.
- Tags:
- openstack ›
Overview
The Glance sync charm provides a cross-model/cross-cloud image sync, from a glance-sync 'master' application, to any number of client applications, referred to as glance-sync 'slaves'. The charm functions in either the following two modes:
Master mode
The charm will function as the master source within a glance image sync. The charm will perform a glance image and metadata sync from the local glance application, over to the local disk on the unit. The glance data is then accessible from the glance-sync-slave units on other models/clouds.
Slave mode
In this mode, the 'master_mode' juju config parameter is set to 'false', and the charm acts as a client to a master OpenstStack installation, with respect to glance images. The master OpenStack must have the glance-sync application deployed, with the parameter 'master_mode' set to 'true'. We refer to this configuration as the glance-sync-master, or 'master' for short.
The 'slave' unit will then sync up to the glance-sync-master, and look for any new glance images and metadata that may reside there, pulling them down using rsync over SSH. Finally, the slave will store the images and metadata to local disk, and import them into the local glance application.
Requirements
In order to let this charm work successfully, it is required that there is a network path between the deployments of the master and slaves. It should be possible to run multiple slaves, but this (multiple slaves) has not been tested with this version (yet). The slave instances also need to be able to reach the openstack api of the master and the glance instance of the master site.
Configuration
The configuration options are: m / s admin_email - This option is used to send notification to. m authorized_keys - base64 encoded file containing the slave keys / commands allowed to sync m / s config_dir - directory where the configuration files are stored m / s cron_frequency - defaults to `10 /3 * ", ie running 10 minutes past the hour, every 3 hours m / s data_dir - location where the images and metadata files are cached m / s log_dir - location where the logs are stored created by the command run in the crontab s master_creds - Openstack credentials needed to download images from the glance master m / s master_node - Is this instance running as master or as slave m / s nagios_context - used by the nrpe-external-master subordinate for proper signaling of issues m / s novarc - base64 encoded novarc, used to contact the local openstack api to retrieve the information of the images in glance. This file also should contain the information needed to access the mysql database. This is needed in order to be able to retrieve the images marked as 'community' which are not exposed by the glance api directly (while the api allows them to download) m / s script_dir - location where the scripts are installed m / s sync_enabled - is the sync running? s sync_source - rsync URL pointing to the master * m / s trusted_ssl_ca - the CA needed for secure authentication of the openstack API
Build
To deploy the charm, first build the charm from its respective charm layer.
Clone the repository for the glance-sync-layer, down to where you have your
local Juju environment, and install the charm
snap, if you do not already
have it installed on the system.
cd /path/to/glance-sync-layer/
make requirements
Now run the following command to build the charm for the 'xenial' series:
cd /path/to/glance-sync-layer/
make build
The charm also features a Makefile
in the root directory of the
repository, which can be used to automatically build the charm for you, as well
as provide other additional functionality.
The Makefile
also has the functionality to install package dependencies
for the build process, perform unit and/or functional tests, and also run the
built-in linter, providing you with the output from flake8
. Use make
help
for more details:
cd /path/to/glance-sync-layer/
make help
Master Installation
To deploy the charm in master-mode:
juju deploy --series=xenial --config master_mode=true ~/charms/glance-sync-layer/xenial/glance-sync gsm
To configure an already deployed charm to run in master-mode:
juju config <glance-sync-application> master_mode=true
WARNING: this will wipe ALL data that exists within the data
directory, which has its path defined by the data_dir
juju config parameter.
It is assumed that if you wish to keep a copy of the contents of the data
directory, that you have already made a backup of it, since performing a mode
change inherently changes the behaviour and the file structure of the deployed
unit.
Then add the relations to keystone and mysql:
juju add-relation keystone gsm
juju add-relation mysql gsm
Master Configuration
In order to allow the slave unit to run rsync against the glance data directory of the master unit, the public ssh key of the ubuntu user in the slave unit needs to be added to the authorized_keys file of the ubuntu user in the master unit. you need to add to the authorized_keys file of the "ubuntu" user of the master, the public keys of the ubuntu users on the slaves.
Get the slave public key:
juju scp gss/0:/home/ubuntu/.ssh/id_rsa.pub .
Configure on the master:
juju config gsm authorized_keys="$(base64 id_rsa.pub)"
Slave Installation
Assuming that you have the juju
package installed, along with a
controller/model added, then first switch to the model that you wish to deploy
the glance-sync charm on, and run:
juju deploy --series=xenial /path/to/glance-sync-layer/<series>/glance-sync gss
If you wish to reconfigure a deployed master unit to run as a slave, you should run:
juju config <glance-sync-application> master_mode=false
WARNING: this will wipe ALL data that exists within the data
directory, which has its path defined by the data_dir
juju config parameter.
It is assumed that if you wish to keep a copy of the contents of the data
directory, that you have already made a backup of it, since performing a mode
change inherently changes the behaviour and the file structure of the deployed
unit.
Then add the relation to keystone and mysql:
juju add-relation keystone gsm
juju add-relation mysql gsm
Slave Configuration
Next, Juju will ask you to set a 'sync_source' for the charm, (see juju status
output), and then run:
juju config gss sync_source='ubuntu@<master-hostname-or-ip>:/srv/glance_sync/data'
Which assumes that the parameter 'data_dir' has been left to its default value
'/srv/glance_sync/data'. Otherwise, correct the path for to the data
directory within the 'sync_source' parameter above.
Configure the OpenStack credentials of the master region on the master_creds parameter of the slave application (slave region).
Note: It is not recommended to use the admin user. A new user with limited privileges should be created.
juju config gss master_creds="username=$OS_MASTER_USERNAME, password=$OS_MASTER_PASSWORD, project=$OS_MASTER_PROJECT, region=$OS_MASTER_REGION, auth_url=$OS_AUTH_URL, domain=$OS_MASTER_DOMAIN"
Configuration
- admin_email
- (string) email address for notifications
- root@canonical.com
- (string) base64 encoded command limited authorized ssh keys file to authorize slave rsync calls. Affects master mode only
- config_dir
- (string) directory to store configuration like novarc
- /srv/glance_sync/config
- cron_frequency
- (string) cron frequency for sync script
- 10 */3 * * *
- data_dir
- (string) directory to store image and metadata files
- /srv/glance_sync/data
- extra_packages
- (string) Space separated list of extra deb packages to install.
- install_keys
- (string) List of signing keys for install_sources package sources, per charmhelpers standard format (a yaml list of strings encoded as a string). The keys should be the full ASCII armoured GPG public keys. While GPG key ids are also supported and looked up on a keyserver, operators should be aware that this mechanism is insecure. null can be used if a standard package signing key is used that will already be installed on the machine, and for PPA sources where the package signing key is securely retrieved from Launchpad.
- install_sources
- (string) List of extra apt sources, per charm-helpers standard format (a yaml list of strings encoded as a string). Each source may be either a line that can be added directly to sources.list(5), or in the form ppa:<user>/<ppa-name> for adding Personal Package Archives, or a distribution component to enable.
- log_dir
- (string) directory to store sync logfiles
- /srv/glance_sync/logs
- master_creds
- (string) Comma separated OpenStack credentials to be used to download images from the master region. Affects slave mode only. It is strongly recommended this be a user with a dedicated role, and not a full admin. Takes the format of username=foo, password=bar, project=baz, region=Region1, auth_url=https://127.0.0.1:35357/v3, domain=Default
- master_mode
- (boolean) enables the unit to function as the sync master
- nagios_context
- (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
- juju
- novarc
- (string) base64 encoded custom novarc file
- package_status
- (string) The status of service-affecting packages will be set to this value in the dpkg database. Valid values are "install" and "hold".
- install
- script_dir
- (string) directory to store scripts
- /srv/glance_sync/scripts
- sync_enabled
- (boolean) switch to enable or disable sync
- True
- sync_source
- (string) rsync URL of master to sync images from. Affects slave mode only. for example: ubuntu@172.16.109.180:/srv/glance_sync/data
- trusted_ssl_ca
- (string) base64 encoded SSL ca cert to use for OpenStack API client connections. This relies on the same CA being used for both the master and slave region