glance sync #2

Supports: focal bionic xenial
Add to new model

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.


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
authorized_keys
(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