summaryrefslogtreecommitdiffstats
path: root/playbooks/byo/openshift-cluster/upgrades/v3_4
Commit message (Collapse)AuthorAgeFilesLines
* v3.4 Upgrade RefactorRussell Teague2017-05-024-298/+3
|
* Refactor initialize groups tasksRussell Teague2017-04-123-0/+6
| | | | | | | | | | | | Two tasks for initializing group names for the byo playbooks was located in the common folder in the std_include.yml file. Byo dependencies should not be in the common folder. The two tasks have been removed from common/openshift-cluster/std_include.yml to a new file byo/openshift-cluster/initialize_groups.yml. All references where these tasks were included from either std_include.yml or other various files have been updated to use the byo initialize_groups.yml. The methodology implemented follows the pattern of having groups set up in byo then calling out to playbooks in common, which are common to all deployments.
* - update excluders to latest, in non-upgrade scenarios do not updateJan Chaloupka2017-03-073-3/+3
| | | | | | - check both available excluder versions are at most of upgrade target version - get excluder status through status command - make excluders enablement configurable
* initialize oo_nodes_to_upgrade group when running control plane upgrade onlyJan Chaloupka2017-02-161-0/+3
|
* upgrades: fix path to disable_excluder.ymlJan Chaloupka2017-02-151-1/+1
|
* Move excluder disablement into control plane and node upgrade playbooksScott Dodson2017-02-063-0/+12
| | | | | So that excluder is disabled and reset within the scope of each of those in addition to the overall playbook
* Adding names to plays and standardizingRussell Teague2017-01-272-4/+4
|
* Cleaning repo cache earlierRussell Teague2017-01-191-2/+2
|
* Merge pull request #3093 from mtnbikenc/upgrade-fixScott Dodson2017-01-191-0/+2
|\ | | | | Correct consistency between upgrade playbooks
| * Correct consistency between upgrade playbooksRussell Teague2017-01-131-0/+2
| |
* | Validate system restart policy during pre-upgrade.Devan Goodwin2017-01-182-0/+8
|/ | | | | | | | | | This was done far into the process potentially leaving the user in a difficult situation if they had now considered they were running the upgrade playbook on a host that would be restarted. Instead check configuration and what host we're running on in pre-upgrade and allow the user to abort before making any substantial changes. This is a step towards merging master upgrade into one serial process.
* Add master config hook for 3.4 upgrade and fix facts ordering for config ↵Andrew Butcher2016-12-161-0/+2
| | | | hook run.
* YAML LintingRussell Teague2016-12-121-1/+0
| | | | | * Added checks to make ci for yaml linting * Modified y(a)ml files to pass lint checks
* Fix rare failure to deploy new registry/router after upgrade.Devan Goodwin2016-11-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Router/registry update and re-deploy was recently reordered to immediately follow control plane upgrade, right before we proceed to node upgrade. In some situations (small or single host clusters) it appears possible that the deployer pods are running when the node in question is evacuated for upgrade. When the deployer pod dies the deployment is failed and the router/registry continue running the old version, despite the deployment config being updated correctly. This change re-orderes the router/registry upgrade to follow node upgrade. However for separate control plane upgrade, the router/registry still occurs at the end. This is because router/registry seems like they should logically be included in a control plane upgrade, and presumably the user will not manually launch node upgrade so quickly as to trigger an evac on the node in question. Workaround for this problem when it does occur is simply to: oc deploy docker-registry --latest
* Add support for 3.4 upgrade.Devan Goodwin2016-10-255-0/+313
This is a direct copy of 3.3 upgrade playbooks, with 3.3 specific hooks removed and version numbers adjusted appropriately.
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-05 23:22:57 +0000