Merge "Only mount selinux sysfs in nova_libvirt container" into stable/pike

[apex-tripleo-heat-templates.git] / docker / services / README.rst

diff --git a/docker/services/README.rst b/docker/services/README.rst
index 219f35e..a843efc 100644 (file)
--- a/docker/services/README.rst
+++ b/docker/services/README.rst
@@ -23,7 +23,7 @@ puppet (our configuration tool of choice) into the Kolla base images. The
 undercloud nova-scheduler also requires openstack-tripleo-common to
 provide custom filters.
 
-To build Kolla images for TripleO adjust your kolla config to build your
+To build Kolla images for TripleO adjust your kolla config [*]_ to build your
 centos base image with puppet using the example below:
 
 .. code-block::
@@ -37,6 +37,10 @@ kolla-build --base centos --template-override template-overrides.j2
 
 ..
 
+.. [*] See the
+   `override file <https://github.com/openstack/tripleo-common/blob/master/contrib/tripleo_kolla_template_overrides.j2>`_
+   which can be used to build Kolla packages that work with TripleO, and an
+   `example build script <https://github.com/dprince/undercloud_containers/blob/master/build_kolla.sh>_.
 
 Docker settings
 ---------------
@@ -70,7 +74,7 @@ are re-asserted when applying latter ones.
      * puppet_tags: Puppet resource tag names that are used to generate config
        files with puppet. Only the named config resources are used to generate
        a config file. Any service that specifies tags will have the default
-       tags of 'file,concat,file_line' appended to the setting.
+       tags of 'file,concat,file_line,augeas,cron' appended to the setting.
        Example: keystone_config
 
      * config_volume: The name of the volume (directory) where config files
@@ -120,3 +124,24 @@ Steps correlate to the following:
    5) Service activation (Pacemaker)
      a) step 5 baremetal
      b) step 5 containers
+
+Update steps:
+-------------
+
+All services have an associated update_tasks output that is an ansible
+snippet that will be run during update in an rolling update that is
+expected to run in a rolling update fashion (one node at a time)
+
+For Controller (where pacemaker is running) we have the following states:
+ 1. Step=1: stop the cluster on the updated node;
+ 2. Step=2: Pull the latest image and retag the it pcmklatest
+ 3. Step=3: yum upgrade happens on the host.
+ 4. Step=4: Restart the cluster on the node
+ 5. Step=5: Verification:
+    Currently we test that the pacemaker services are running.
+
+Then the usual deploy steps are run which pull in the latest image for
+all containerized services and the updated configuration if any.
+
+Note: as pacemaker is not containerized, the points 1 and 4 happen in
+puppet/services/pacemaker.yaml.