Manager

warning

Always read the release notes first to learn what has changed and what adjustments are necessary. Read the release notes even if you are only updating from e.g. 7.0.2 to 7.0.5.

The update of a manager service with a stable release of OSISM is described here. In the example, OSISM release 7.0.5 is used.

Which update path applies to you

Step 3 below drives the osism.manager.manager playbook against the manager over SSH. The same playbook is used in every case; only how it is launched depends on how you deployed the cluster. Steps 1, 2 and 4 to 6 are the same for all of them.

Manager with a local Ansible venv (a self-bootstrapped manager): run osism update manager on the manager itself — this is the path described below.
Seed node still available (a separate workstation or VM that holds the configuration repository, as in the Seed deploy guide): update from the seed instead of the manager. After bumping manager_version (step 1) and syncing the configuration repository on the manager (step 2), re-run the manager playbook from the seed:
```
./run.sh manager
```
This reuses the same seed tooling as the initial bootstrap, so the manager itself needs no local Ansible installation.
Manager deployed with the seed container, seed discarded (the manager has no local Ansible venv and no seed node remains): run the update from the configuration repository on the manager itself. run.sh ships in the repository and is refreshed by make sync (step 1), so it does not depend on the manager's installed tooling. With a container engine present and no local venv it runs the playbook inside the osism/seed container automatically (SEED_CONTAINER=auto):
```
cd /opt/configuration/environments/manager
./run.sh manager
```
The vault password must be reachable — ship environments/.vault_pass in the configuration repository or export ANSIBLE_ASK_VAULT_PASS=true (see the vault note in step 3). Once the manager runs a release whose wrapper supports it, osism update manager (CONTAINER=auto) does the same thing and can be used instead.

Change the OSISM release in the configuration repository.
1. Set the new OSISM version in the configuration repository.
```
MANAGER_VERSION=7.0.5
sed -i -e "s/manager_version: .*/manager_version: ${MANAGER_VERSION}/g" environments/manager/configuration.yml
```
2. If openstack_version or ceph_version are set in environments/manager/configuration.yml (or anywhere else), they must be removed. If these are set, the stable release is not used for these components.
3. Sync the image versions and files in the configuration repository.
  - OSISM >= 7.0.0
  - OSISM < 7.0.0
  make sync
  If Gilt is not installed via the requirements.txt of the manager environment it is important to use a version smaller v2. The v2 of Gilt is not yet usable.
  gilt overlay # you have to do this 2x, this is not a copy & paste error gilt overlay
  Optionally, this is normally not necessary, it is possible to reference a specific tag of the osism/generics repository. To do this, first check which version of osism/generics is used in a particular release. The version is defined in generics_version in the base.yml file in the osism/release repository. For OSISM 6.0.0, for example, this is version v0.20230919.0. This version is then added to the file gilt.yml in the configuration repository instead of main at version. This change must be made again after each execution of gilt overlay as it is overwritten by the call of gilt overlay. This cannot be realized differently in the current implementation of Gilt.
4. Commit and push all changes in the configuration repository. Since everyone here has their own workflows for changes to the configuration repository, only a generic example for Git.
```
git commit -a -s -m "manager: use OSISM version 7.0.5"
git push
```
Update the configuration repository on the manager node.
```
osism apply configuration
```
Update the manager service on the manager node.
```
osism update manager
```
- If Ansible Vault was used to encrypt environments/manager/secrets.yml, append --ask-vault-pass (or set ANSIBLE_VAULT_PASSWORD_FILE to the vault password file). Unlike osism apply, osism update manager runs outside the OSISM workers — it recreates the manager containers and therefore cannot use the worker-side vault password set with osism set vault password. The password must be supplied directly whenever secrets.yml is encrypted; the OSISM >= 8.0.0 relief from --ask-vault-pass applies to osism apply, not to this command.
- If osism update manager does not work yet, use osism-update-manager instead.
Refresh the facts cache.
```
osism apply facts
```
If Traefik is used on the manager node (traefik_enable: true in environments/infrastructure/configuration.yml) then Traefik should also be upgraded.
```
osism apply traefik
```
Finally, the Ansible vault password must be made known again.
```
osism set vault password
```