We used to have an 'error-prone' approach of making Docker upgrades,
and in really rare cases we had an old container in 'running' state
instead of new one.
Here's the steps when issue occurs:
* One container isn't running due to some reason (for instance, it
failed). The supervisor scheduled to start it again soon.
* The fuel_upgrade script stops supervisor's processes. They will be
stopped and won't be started again by supervisor (even if they have
autostart=true setting).
* The container, which wasn't run by the time we was stopping them,
is untouched. It's still scheduled to be running soon.
* The fuel_upgrade script stops Docker containers, but one of them
will be starting again and again because of that working supervisor
process.
In order to avoid this situation, we have to do the following things:
* Point supervisor to new config folder (which is empty by now).
* Restart supervisor, so it forget old configs and will use no of them.
* Upload images and create new containers.
* Generate new supervisor configs and restart supervisor in order to
apply them (supervisor's processes will be attached automatically
to running docker containers).
Signed-off-by: Igor Kalnitsky <igor@kalnitsky.org>
Change-Id: Ibc133b4471878efeffeb232192b4540d26401fae
Closes-Bug: #1441693
de04ee015c