| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
We should enable each kind of upgrade per role, not per step
so rework the conditions, and also only apply it to the deployment
(to save the round-trip to the nodes applying an empty config)
but don't disable the *Config resources as the overhead of these
is small, and we reference the Step1 config in the outputs, even
if it's empty.
Change-Id: Iee2f1fb5b1d8b0b6001c6ab0f2a4ef2858cef281
Partially-Implements: blueprint overcloud-upgrades-per-service
|
|
Where the role has disabled upgrades, we need to skip both the ansible and
puppet steps. To do this we refactor the post.j2.yaml so that it can be
included in the upgrade template with an adjusted list of roles.
Note this requires https://review.openstack.org/#/c/425220/ - this
change will be required for local testing of this patch
(run mistral-db-mange populate after updating tripleo-common
and restart the mistral services, or update your repos and re-run
openstack undercloud install).
Partially-Implements: blueprint overcloud-upgrades-per-service
Change-Id: Ie7d0fa6fef3528bd93e6cde076b964ea8de3185a
|
|
Use heat conditions to skip resources (conditionally create them)
when there are no tasks to deploy.
This requires the heat fix Iefae1fcea720bee4ed69ad1a5fe403d52d54433c
Partially-Implements: blueprint overcloud-upgrades-per-service
Change-Id: I2f43fb922d122ffade20e35738f0ba3bb56a4492
|
|
Some services (e.g ceph mon) require upgrading in batches (the old
upgrade architecture did the ceph mon upgrade one controller at a
time). This interface enables doing the same, and over time we
can probably move more services into this interface (e.g when
services support rolling upgrades) to reduce downtime.
Change-Id: If581f301a5493ef33ac1386bdc22f9fca4f2544e
Partially-Implements: blueprint overcloud-upgrades-per-service
|
|
|
|
As part of the composable upgrades current plan is to disable
the composable upgrades steps running on a particular role
(e.g. all compute nodes) in favor of a later operator driven
upgrades process as has previously been the case
This adds the disable_upgrade_deployment flag to roles_data as
a first step. Thanks to shardy for his help with this.
Change-Id: Ice845742a043b34917e61f662885786c73e955fd
|
|
Adds a step0 for any pre-upgrade checks. This migrates
some of the checks we have at the top of
extraconfig/tasks/major_upgrade_controller_pacemaker_1.sh
Checks for other services (and for the cluster) will follow
in separate commits.
Partially-Implements: blueprint overcloud-upgrades-per-service
Change-Id: I607f1fed68d7f11773484c3d7cb3e5af67465d57
|
|
Heat now supports release name aliases, so we can replace
the inconsistent mix of date related versions with one consistent
version that aligns with the supported version of heat for this
t-h-t branch.
This should also help new users who sometimes copy/paste old templates
and discover intrinsic functions in the t-h-t docs don't work because
their template version is too old.
Change-Id: Ib415e7290fea27447460baa280291492df197e54
|
|
We can't run this during the upgrade steps, because there are things
which need to happen before any role configuration happens, e.g
installing the new hiera heat-config hook, which must be done before
e.g "ControllerDeployment" runs or the stack update hangs.
Partially-Implements: blueprint overcloud-upgrades-per-service
Change-Id: I365b57513590662c3f78a33dc625747f457c48c5
|
|
This shows how we could wire in the upgrade steps using Ansible
as was previously proposed e.g in https://review.openstack.org/#/c/321416/
but it's more closely integrated with the new composable services
architecture.
It's also very similar to the approach taken by SpinalStack where
ansible snippets per-service were combined then run in a series of
steps using Ansible tags.
This patch just enables upgrade of keystone - we'll add support for
other patches in subsequent patches.
Partially-Implements: blueprint overcloud-upgrades-per-service
Change-Id: I39f5426cb9da0b40bec4a7a3a4a353f69319bdf9
|
Steven Hardy
Jenkins
marios