summaryrefslogtreecommitdiffstats
path: root/puppet/major_upgrade_steps.j2.yaml
AgeCommit message (Collapse)AuthorFilesLines
2017-07-21Make Deploy/UpdateIdentifier definition semi-consistentBen Nemec1-0/+1
It seems UpdateIdentifier is an overloaded parameter - it is used both to trigger package updates in the minor update case as well as to trigger the upgrade steps during a major upgrade. I'm not sure it's appropriate to change either of the descriptions as a result, so for the moment that is added to the exclusion list. Change-Id: Ied36cf259f6a6e5c8cfa7a01722fb7fda6900976 Partial-Bug: 1700664
2017-06-28Add ctlplane_service_ips param to upgrade stepsJiri Stransky1-1/+3
Upgrades were broken because of this missing parameter. Change-Id: Ia88a9833ab8aa26ccc40ee235b8554c9a7fbd22d Closes-Bug: #1700923
2017-06-27Allow stack_name into major_upgrade_steps.yamlGiulio Fidente1-1/+4
On upgrade we map PostDeploySteps to a different implementation which we missed to update in I36a642fbc2076ad9e4a10ffc56d6d16f3ed6f27a Change-Id: Ia619ab935c66081769e69c53d1ca41925d86abbb Closes-Bug: #1700755
2017-06-05Merge "Remove nova placement config for compute service node on upgrade"Jenkins1-18/+0
2017-05-19Update the template_version alias for all the templates to pike.Carlos Camacho1-1/+1
Master is now the development branch for pike changing the release alias name. Change-Id: I938e4a983e361aefcaa0bd9a4226c296c5823127
2017-05-09Make upgrade steps unconditional to fix broken dependenciesJiri Stransky1-19/+0
Change I5c8b0c4abfc0607f42fd3f2da9f5ef2702b1bbe1 introduced conditions to optimize upgrade times and fix related bugs. Unfortunately the conditional inclusion would have to be paired with support in depends_on to work as we need. Currently we can hit this bug if the batch upgrade steps are undefined for some role, but upgrade steps are definied: The specified reference "ControllerUpgradeBatch_Step2" (in ControllerUpgradeConfig_Step0) is incorrect. To fix this we have to make the steps unconditional. This isn't fully reverting the original change because that change also addressed ordering issues. Change-Id: I369591f4757c10142f5b455e64aa778e1a9a5611 Closes-Bug: #1689553
2017-05-04Remove nova placement config for compute service node on upgrademarios1-18/+0
This was necessary during the newton to ocata upgrade Change-Id: Iee248b6605e6c9cd82ce7cb733e220c6318c1764
2017-05-03Add back Heat conditions in upgrade workflowGiulio Fidente1-28/+50
By adding back the conditions we avoid the deployment of unneded software configs on nodes where we don't have any upgrade task to run, speeding up the upgrade process. Related-Bug: #1679486 Related-Bug: #1678101 Change-Id: I5c8b0c4abfc0607f42fd3f2da9f5ef2702b1bbe1
2017-04-19N->O upgrade, fix wrong parameters to nova placement.Sofer Athlan-Guyot1-1/+2
According to [1] we need os_region_name, not region_name. Furthermore the os_interface is configured as well. The hard check on this parameter was introduced in ocata[2], explaining why the newton version did not chock on it. [1] https://docs.openstack.org/ocata/config-reference/compute/config-options.html [2] https://github.com/openstack/nova/commit/d486315e0 Closes-Bug: #1684058 Change-Id: If6118bf03e832fe3fa5ea4fcb1b436afd2adf80a
2017-04-04Enforce upgrade_batch_tasks before upgrade_tasks ordermarios1-19/+12
If we really want upgrade_batch_tasks before the upgrade_tasks as described in the README then we should enforce the ordering Noticed this working on bug 1671504 upgrade tasks were being executed before batch upgrade tasks. Closes-Bug: 1678101 Change-Id: Iaa1bce960a37c072b5f8441132705a6bb6eb6ede
2017-04-04Ensure upgrade step orchestration accross roles.Sofer Athlan-Guyot1-8/+6
Currently we don't enforce step ordering across role, only within role. With custom role, we can reach a step5 on one role while the cluster is still at step3, breaking the contract announced in the README[1] where each step has a guarantied cluster state. We have to remove the conditional here as well as jinja has no way to access this information, but we need jinja to iterate over all enabled role to create the orchestration. This deals only with Upgrade tasks, there is another review to deal with UpgradeBatch tasks. [1] https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/README.rst Closes-Bug: #1679486 Change-Id: Ibc6b64424cde56419fe82f984d3cc3620f7eb028
2017-03-24N->O Upgrade, make sure all nova placement parameter properly set.Sofer Athlan-Guyot1-3/+6
The restart of openstack-nova-compute takes place before crudini set the password, user_domain and project_name get set. Change-Id: I57b54d5f59d5803d7ad4e399d598f699785a5825 Closes-Bug: #1675739 Co-Authored-By: Oliver Walsh <owalsh@redhat.com>
2017-02-15Apply puppet in non-controller script in step.Sofer Athlan-Guyot1-0/+1
We want to apply a puppet manifest for the non-controller role, but we need to apply it in stages. By loading the proper hieradata we get the needed step configuration. Change-Id: I07bfeee7b7d9a9b8c2c20e5d5c9ed735d0bfc842 Closes-Bug: #1664304
2017-02-10Dump and run puppet for role which are disable_upgrade_deployment trueMathieu Bultel1-0/+28
We wants to run puppet on each role which has the flag disable_upgrade_deployment to true. It will run after the upgrade of the role and before running the whole converge step. Change-Id: Ia85be688d070dfb5b8337e8ef3c4bc439fb6052e
2017-02-10Delivers upgrade scripts where upgrade steps are disabledmarios1-1/+62
This delivers a /root/tripleo_upgrade_node.sh to those nodes that have the disable_upgrade_deployment flag set to true. They will later be upgraded manually by the operator who will invoke the script delivered here using upgrade-non-controller.sh We can also deliver any service specific upgrade configuration, such as configuring nova-compute to use the placement API as this is required in order for placement to be configured and installed during the subsequent upgrade steps for controller services. This removes the compute and swift specific upgrade scripts as they are now merged into the common tripleo_upgrade_node.sh - removing any hard coded reference to a particular role name (compute/objectstorage) and only relying on the disable_upgrade_deployment is roles_data.yaml Change-Id: I4531a4038b78087ef4a1a62c35f1328822427817 Co-Authored-By: Mathieu Bultel <mbultel@redhat.com>
2017-02-10Make UpgradeBatch resource depends on BatchConfig step0Mathieu Bultel1-26/+18
Make UpgradeBatch depends on BatchConfig, for step0 avoid creation of the UpgradeBatchConfig_stepX prior to UpgradeBatchConfig step0 and add condition Change-Id: I852beee65590270422cfbc9abe02111d88442f2e
2017-02-03Disable batch upgrade deployments for disabled rolesSteven Hardy1-43/+44
Currently we don't correctly disable the batch_upgrade_tasks, so rework the loops to ensure we only create the batch deployments for roles which enabled upgrades. Note this modifies some loop whitespace too which cleans up the rendered output and makes it a bit more readable/compact. Change-Id: I1c257dcc351e99efa54f9cae4b3009287908756e Partially-Renders: blueprint overcloud-upgrades-per-service
2017-02-03Reduce number of steps for upgradesSteven Hardy1-4/+5
We don't need all the steps currently enabled for either batched or concurrent updates, so decrease them. In future we can perhaps introspect the task tags during plan creation and set these dynamically. Change-Id: I0358886a332dfbecd03bc4a67086b08d25756c22 Partially-Implements: blueprint overcloud-upgrades-per-service
2017-02-03Simplify/fix config enabled conditions for upgradesSteven Hardy1-12/+6
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
2017-02-03Disable puppet on upgrade for roles not upgradingSteven Hardy1-0/+14
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
2017-01-25Skip upgrade steps where no tasks are definedSteven Hardy1-0/+21
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
2017-01-25Add support for batched upgrades to composable upgradesSteven Hardy1-3/+56
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
2017-01-24Merge "Add disable_upgrade_deployment flag to roles_data.yaml"Jenkins1-1/+6
2017-01-20Add disable_upgrade_deployment flag to roles_data.yamlmarios1-1/+6
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
2017-01-13Adds a step0 for pre upgrade-init checksmarios1-3/+3
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
2016-12-23Bump template version for all templates to "ocata"Steven Hardy1-1/+1
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
2016-12-19Move UpgradeInitCommand to role templatesSteven Hardy1-31/+1
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
2016-12-01Initial support for composable upgrades with Heat+AnsibleSteven Hardy1-0/+98
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