Upgrades, changed workflow for versions.yaml config file
Now we have the next worflow
* if user runs upgrade script first time,
we save current version.yaml file into
work directory
* if user for some reaons runs the script
second or third time, we use version.yaml
from work directory as the version which
we need to rollback to, we cannot use
config from /etc/fuel/version.yaml.
Because upgrade script could be
interrupted after symlink creation
Additional fixes
* config has version parameters which looks
like strings instead of dicts with hierarchy,
because we don't need all of the data from
version.yaml file
* removed before and post upgrade section
because they were useless, in fact we
can do this actions in upgrade method
* created before upgrade checker which is
activated only if the script was ran
with docker parameter, this checker
checks if ugprade make sense. For example
now impossible to run upgrade from version
5.0 to 5.0 and from 5.1 to 5.0.1
Reviewed: https:/ /review. openstack. org/104567 /git.openstack. org/cgit/ stackforge/ fuel-web/ commit/ ?id=d01b4efc0fc 4af9d0e316b9dfc 7974f16975f822
Committed: https:/
Submitter: Jenkins
Branch: stable/5.0
commit d01b4efc0fc4af9 d0e316b9dfc7974 f16975f822
Author: Evgeniy L <email address hidden>
Date: Wed Jul 2 21:09:53 2014 +0400
Upgrades, changed workflow for versions.yaml config file
Now we have the next worflow version. yaml.
* if user runs upgrade script first time,
we save current version.yaml file into
work directory
* if user for some reaons runs the script
second or third time, we use version.yaml
from work directory as the version which
we need to rollback to, we cannot use
config from /etc/fuel/
Because upgrade script could be
interrupted after symlink creation
Additional fixes
* config has version parameters which looks
like strings instead of dicts with hierarchy,
because we don't need all of the data from
version.yaml file
* removed before and post upgrade section
because they were useless, in fact we
can do this actions in upgrade method
* created before upgrade checker which is
activated only if the script was ran
with docker parameter, this checker
checks if ugprade make sense. For example
now impossible to run upgrade from version
5.0 to 5.0 and from 5.1 to 5.0.1
blueprint upgrade-to-5-0-1 d527ce5e9be2f03 acc234cf3b0
Closes-bug: #1331363
Closes-bug: #1333584
Change-Id: I719799db216260