Merge ~jamesh5979/bootstack-specs:glance-sync-slave-layer into bootstack-specs:master

[James Hilling]

[James Hilling] Glance Sync Slave charm spec

Created Glance Sync Slave charm spec.

Unmerged commits

41f83eb... by James Hilling on 2018-11-19

[James Hilling] Final version of 'glance-sync-slave-layer' spec, ready for review

05671d2... by James Hilling on 2018-11-19

[James Hilling] Third draft of 'glance-sync-slave-layer' spec

57796b7... by James Hilling on 2018-11-16

[James Hilling] Second draft of 'glance-sync-slave-layer' spec

5b82c4a... by James Hilling on 2018-11-14

[James Hilling] First draft of 'glance-sync-slave-layer' spec

diff --git a/backlog/glance-sync-slave-layer.rst b/backlog/glance-sync-slave-layer.rst
new file mode 100644
index 0000000..2fcf431
--- /dev/null
+++ b/backlog/glance-sync-slave-layer.rst
@@ -0,0 +1,174 @@
+..
+  Copyright 2018 Canonical
+
+  This work is licensed under a Creative Commons Attribution 3.0
+  Unported License.
+  http://creativecommons.org/licenses/by/3.0/legalcode
+
+..
+  This template should be in ReSTructured text. Please do not delete
+  any of the sections in this template.  If you have nothing to say
+  for a whole section, just write: "None". For help with syntax, see
+  http://sphinx-doc.org/rest.html To test out your formatting, see
+  http://www.tele3.cz/jbar/rest/rest.html
+
+===============================
+Glance Sync Slave Layer
+===============================
+
+This spec is intended for the creation of a charm that can sync glance images
+from a master OpenStack installation to a local OpenStack installation. This
+will utilize two charms to transfer the images, which will act in a
+Master/Slave dynamic, (i.e. Host/Client).
+
+Problem Description
+===================
+
+Customers sometimes have workflows that require their glance images to be
+replicated across different OpenStack installations. An application is
+therefore required that is capable of pulling glance images from one site, and
+replicating them across to another site. Finally, the images need to get
+imported into the glance application on the local site.
+
+Proposed Change
+===============
+
+We want to create a charm that will act as the 'slave' component within a
+glance image sync, that can be deployed across multiple OpenStack
+installations. The name of this charm will be referred to as the Glance Sync
+Slave, or GSS for short. The GSS must allow OpenStack installations to pull
+and import glance images across sites, to fulfil a glance image replication.
+
+The GSS will pull the images from a 'master' OpenStack installation, using the
+Glance Sync Master charm, or the GSM for short.
+
+The GSM will create a local rsync directory on the master OpenStack
+installation, where the images can be pulled by the GSS units, using rsync
+over SSH, that forms the connection between the various OpenStacks to the
+master OpenStack installation, where the GSM is deployed.
+
+The GSS/GSM units will initiate the rsync at regular intervals, by the means of
+cronjobs. The metadata for the glance images will also need to be rsynced,
+which will be in the form of a separate json file. The file should contain the
+md5 checksums for the images that the GSS will use to verify after image
+transfer, before the image gets importing into the local glance store.
+
+The images that get rsynced between OpenStacks must have the same UUIDs
+between all copies of the image, that is it should be the same across all
+client and master OpenStack glance instances.
+
+The images imported by the GSS application should also reflect any changes
+made to the images on the master OpenStack installation, (including image
+deletions). To handle this, if an image deletion occurs on the master
+OpenStack installation, the GSM should delete the same image from its local
+rsync directory, which ideally should propagate the changes to the file-system
+on the GSS, where the images are stored on a local disk. Unfortunately, this
+will introduce a problem, whereby if there was ever an occasion where an image
+got accidentally deleted from the master glance instance, and subsequently
+from the slave, that is after image deletion propagation, then there would be
+no way to re-add the image back into glance with the same image UUID, without
+manual database surgery, on both the local and master OpenStack installations.
+To avoid this, image deletions should not get performed by GSS units.
+
+Alternatives
+------------
+
+* One charm could instead be used, acting as both the Glance Sync Master and
+  the Glance Sync Slave, where a `juju config` parameter could be set to
+  distinguish what 'mode' the charm should operate in, that is be it master or
+  slave mode. This will involve a rewrite of the two charms into a single
+  charm, and as there is currently already work done towards a Master/Slave
+  implementation of the charm, this method is currently only an alternative.
+
+* A bidirectional sync application could be implemented, which could instead
+  be used to sync images in either direction. You can think of it as each
+  charm both acting as a master and a slave, simultaneously. This would
+  require significantly more work to implement, as we already have a lot of
+  code written for the current Master/Slave charm implementation.
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+* Primary assignee:
+
+  * <woutervb>
+  * <j.hilling>
+
+Gerrit Topic
+------------
+
+* None
+
+Work Items
+----------
+
+* Creation of additional functional tests.
+
+* Possible merging of both the Glance Sync Master layer and the Glance
+  Sync Slave layer into a single charm layer that uses `juju config`
+  parameters to determine whether the charm is going to function as either a
+  'master' or a 'slave'.
+
+Repositories
+------------
+
+* Two repositories already exist for the Glance Sync application:
+
+  * Glance Sync Master: https://launchpad.net/glance-sync-master-layer
+  * Glance Sync Slave: https://launchpad.net/glance-sync-slave-layer
+
+* A new launchpad repository will need to be created if the charms for the
+  Glance Sync Master and the Glance Sync Slave are to be merged into a single
+  universal Glance Sync charm.
+
+Documentation
+-------------
+
+* There is currently limited documentation available for this charm outside of
+  the README.md files, located within the Glance Sync Master/Slave layer
+  project repositories respectively.
+
+  If this charm is to make it to the charm store, it will require some form of
+  additional online documentation.
+
+* Wiki documentation is also desirable.
+
+* Glance Sync charmers launchpad page:
+
+  * Glance Sync Charmers page: https://launchpad.net/~glance-sync-charmers
+
+Security
+--------
+
+* The connection between the Glance Sync Master and the Slave units will
+  utilize an SSH connection, where the Glance Sync Master will host the SSH
+  server, and the Glance Sync Slave will make up the SSH clients.
+
+* For security purposes, the SSH connection should be purposely
+  command-limited, where the Glance Sync Slaves are authorised via a
+  `juju config` parameter on the Glance Sync Master.
+
+* The Glance Sync Master and Glance Sync Slave applications should also be
+  deployed into LXD containers, which should add an additional layer of
+  security via the principles of compartmentalisation.
+
+Testing
+-------
+
+* Unit tests.
+
+* Integration tests.
+
+* Functional tests.
+
+* Charmlab deployment.
+
+Dependencies
+============
+
+* Glance Sync Master charm.
+
+* Customer dependency.