Allow to move routers during upgrade
This patch adds functionality that allows to move legacy routers
from one agent to another during upgrade.
Also it adds waiter to check for availability of agents.
Change-Id: I6df53d99348a8a635f5712f5144be331d4188a4c
diff --git a/README.rst b/README.rst
index 2c12678..4cc9fc1 100644
--- a/README.rst
+++ b/README.rst
@@ -1400,6 +1400,65 @@
level: 'DEBUG'
......
+Upgrades
+========
+
+Each openstack formula provide set of phases (logical bloks) that will help to
+build flexible upgrade orchestration logic for particular components. The list
+of phases might and theirs descriptions are listed in table below:
+
++-------------------------------+------------------------------------------------------+
+| State | Description |
++===============================+======================================================+
+| <app>.upgrade.service_running | Ensure that all services for particular application |
+| | are enabled for autostart and running |
++-------------------------------+------------------------------------------------------+
+| <app>.upgrade.service_stopped | Ensure that all services for particular application |
+| | disabled for autostart and dead |
++-------------------------------+------------------------------------------------------+
+| <app>.upgrade.pkg_latest | Ensure that packages used by particular application |
+| | are installed to latest available version. |
+| | This will not upgrade data plane packages like qemu |
+| | and openvswitch as usually minimal required version |
+| | in openstack services is really old. The data plane |
+| | packages should be upgraded separately by `apt-get |
+| | upgrade` or `apt-get dist-upgrade` |
+| | Applying this state will not autostart service. |
++-------------------------------+------------------------------------------------------+
+| <app>.upgrade.render_config | Ensure configuration is rendered actual version. +
++-------------------------------+------------------------------------------------------+
+| <app>.upgrade.pre | We assume this state is applied on all nodes in the |
+| | cloud before running upgrade. |
+| | Only non destructive actions will be applied during |
+| | this phase. Perform service built in service check |
+| | like (keystone-manage doctor and nova-status upgrade)|
++-------------------------------+------------------------------------------------------+
+| <app>.upgrade.upgrade.pre | Mostly applicable for data plane nodes. During this |
+| | phase resources will be gracefully removed from |
+| | current node if it is allowed. Services for upgraded |
+| | application will be set to admin disabled state to |
+| | make sure node will not participate in resources |
+| | scheduling. For example on gtw nodes this will set |
+| | all agents to admin disable state and will move all |
+| | routers to other agents. |
++-------------------------------+------------------------------------------------------+
+| <app>.upgrade.upgrade | This state will basically upgrade application on |
+| | particular target. Stop services, render |
+| | configuration, install new packages, run offline |
+| | dbsync (for ctl), start services. Data plane should |
+| | not be affected, only OpenStack python services. |
++-------------------------------+------------------------------------------------------+
+| <app>.upgrade.upgrade.post | Add services back to scheduling. |
++-------------------------------+------------------------------------------------------+
+| <app>.upgrade.post | This phase should be launched only when upgrade of |
+| | the cloud is completed. |
++-------------------------------+------------------------------------------------------+
+| <app>.upgrade.verify | Here we will do basic health checks (API CRUD |
+| | operations, verify do not have dead network |
+| | agents/compute services) |
++-------------------------------+------------------------------------------------------+
+
+
Documentation and Bugs
======================