<commit_before>---
title: UpgradeManager
authors: moti, ovedo
wiki_title: Home/Features/UpgradeManager
wiki_revision_count: 41
wiki_last_updated: 2015-06-02
feature_name: Upgrade Manager
feature_modules: engine,infra
feature_status: To be Released
---

# Upgrade Manager

### Summary

The process of upgrading cluster/hosts to a higher version is a manual process. When working with a small cluster of hosts that suffice. However, on large clusters it is very time-consuming to upgrade all the hosts manually. The purpose of this feature is to give administrators a set of tools to know when an upgrade is available (engine/hosts), upgrade separate hosts, and upgrade cluster as a whole, using rolling upgrade process.

### Owner

*   Name: [<NAME>](User:masayag)
*   Email: <<EMAIL>>
*   IRC: masayag at #ovirt (irc.oftc.net)

### Benefit to oVirt

Upgrade is a big pain point on large oVirt deployments. The existence of tools to ease the upgrade process will make it easier to adopt oVirt.

### Requirements

The set of tools that are in the scope of this feature are:

1.  Notify the user that an update for the engine is available
2.  Make it ease to know whether a host has an available update, and what cluster levels this update supports
3.  Allow the user to upgrade a specific host automatically
4.  Allow the user to do a rolling cluster upgrade, either to a higher cluster level, or to a new version that supports the current one

### User Experience

#### Notify the user that an update for the engine is available

After the administrator logs in to the Administrator Portal, he will get a dialog notifying on a new available update. He can choose whether to "dismiss" this notification or not. If he chooses to dismiss it, the only other way of knowing that an update is available is by going to the "About" dialog, and looking for the information there. If an update is available it will appear there. Whether there is an update or not will be checked periodically every X days. Open question here - do we need to support checking whether an update is available by demand?

#### Make it ease to know whether a host has an available update, and what cluster levels this update supports

Currently, for oVirt-node, it already shows you that there is an upgrade available, by an alert on the bottom of the general sub-tab. We can add a similar alert also for regular hosts, showing more details on the cluster level as well. Once the host is moved to maintenance, the option to "upgrade" will be shown and enabled in the host context menu.

#### Allow the user to upgrade a specific host automatically

If an update is available, and the host is moved to maintenance, the option to "upgrade" will be shown and enabled in the host context menu.

#### Allow the user to do a rolling cluster upgrade, either to a higher cluster level, or to a new version that supports the current one

For a cluster we should add the option to "check for available upgrade". This should go on all the operational hosts, and check whether there is a new version available, and what cluster levels it supports. If there is one, the minimal and maximal supported cluster level will be shown as well. Now, the user can upgrade to a higher cluster level, or to a higher version in the current one. Two flows here behind the scenes:
1. Same cluster level - host by host is moved to maintenance, upgraded, activated. At the end of the day the cluster itself as a whole was upgraded. There should be an easy way to see the status of this upgrade, and information for all the hosts, whether they were upgraded or not (Task list?). 2. Higher cluster level - same as #1, but upgrading the cluster levels once all hosts were upgraded.

### Implementation

### Open Issues/Questions<commit_msg>Allow the user to do a rolling cluster upgrade, either to a higher cluster level, or to a new version that supports the current one<commit_after>---
title: UpgradeManager
authors: moti, ovedo
wiki_title: Home/Features/UpgradeManager
wiki_revision_count: 41
wiki_last_updated: 2015-06-02
feature_name: Upgrade Manager
feature_modules: engine,infra
feature_status: To be Released
---

# Upgrade Manager

### Summary

The process of upgrading cluster/hosts to a higher version is a manual process. When working with a small cluster of hosts that suffice. However, on large clusters it is very time-consuming to upgrade all the hosts manually. The purpose of this feature is to give administrators a set of tools to know when an upgrade is available (engine/hosts), upgrade separate hosts, and upgrade cluster as a whole, using rolling upgrade process.

### Owner

*   Name: [<NAME>](User:masayag)
*   Email: <<EMAIL>>
*   IRC: masayag at #ovirt (irc.oftc.net)

### Benefit to oVirt

Upgrade is a big pain point on large oVirt deployments. The existence of tools to ease the upgrade process will make it easier to adopt oVirt.

### Requirements

The set of tools that are in the scope of this feature are:

1.  Notify the user that an update for the engine is available
2.  Make it ease to know whether a host has an available update, and what cluster levels this update supports
3.  Allow the user to upgrade a specific host automatically
4.  Allow the user to do a rolling cluster upgrade, either to a higher cluster level, or to a new version that supports the current one

### User Experience

#### Notify the user that an update for the engine is available

After the administrator logs in to the Administrator Portal, he will get a dialog notifying on a new available update. He can choose whether to "dismiss" this notification or not. If he chooses to dismiss it, the only other way of knowing that an update is available is by going to the "About" dialog, and looking for the information there. If an update is available it will appear there. Whether there is an update or not will be checked periodically every X days. Open question here - do we need to support checking whether an update is available by demand?

#### Make it ease to know whether a host has an available update, and what cluster levels this update supports

Currently, for oVirt-node, it already shows you that there is an upgrade available, by an alert on the bottom of the general sub-tab. We can add a similar alert also for regular hosts, showing more details on the cluster level as well. Once the host is moved to maintenance, the option to "upgrade" will be shown and enabled in the host context menu.

#### Allow the user to upgrade a specific host automatically

If an update is available, and the host is moved to maintenance, the option to "upgrade" will be shown and enabled in the host context menu.

#### Allow the user to do a rolling cluster upgrade, either to a higher cluster level, or to a new version that supports the current one

For a cluster we should add the option to "check for available upgrade". This should go on all the operational hosts, and check whether there is a new version available, and what cluster levels it supports. If there is one, the minimal and maximal supported cluster level will be shown as well. Now, the user can upgrade to a higher cluster level, or to a higher version in the current one.
Two flows here behind the scenes:
1. Same cluster level - host by host is moved to maintenance, upgraded, activated. At the end of the day the cluster itself as a whole was upgraded. There should be an easy way to see the status of this upgrade, and information for all the hosts, whether they were upgraded or not (Task list?).
2. Higher cluster level - same as #1, but upgrading the cluster levels once all hosts were upgraded.

### Implementation

### Open Issues/Questions
{'fraction_non_alphanumeric': 0.04460093896713615, 'fraction_numerical': 0.004434011476264998, 'mean_word_length': 4.23481228668942, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 9, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4212826', 'n_tokens_mistral': 1882, 'n_tokens_neox': 1798, 'n_words': 1265}