This article is being updated. Please be aware the content herein, not limited to version numbers and slight syntax changes, may not match the output from the most recent versions of Bright. This notation will be removed when the content has been updated.
It is important to distinguish between updates and upgrades.
Updates
Package updates are provided through Bright’s YUM/Zypper repositories. It is recommended to check for new updates on a regular basis (e.g. once a week). Updating packages on the head nodes and regular nodes can fix some bugs and provide updates for newer hardware. Updates are done simply via a yum/zypper update.
Upgrades
Upgrades involve going from one version of Bright Cluster Manager to a newer version (e.g. 5.0 -> 5.1).
Upgrading to a new version of Bright is generally not recommended if there is no specific need to move to a new version (e.g. new functionality). Older versions of Bright will continue to be supported and maintained while support contracts are in place. If despite this an upgrade is needed, then Bright Computing can be contacted for details on the upgrade procedure.
A short overview of the upgrade procedure follows:
Upgrading from one version to another requires following a procedure which includes creating a full backup and being prepared to restore the backup in the event that something goes wrong in the process. Upgrades must be performed as follows:
- One version at a time for versions 5.0 to 5.2. Ie: 5.0 -> 5.1 -> 5.2. Contact Bright for detailed instructions.
- Upgrades from 5.2 -> 6.0 will require a full re-install as an in-place upgrade procedure is not available.
- Upgrades from 6.0 onwards, to 7.1, follow the procedure described here. (replace 7.2 with 7.1)
- Upgrades from 6.0 onwards, to 7.2, follow the procedure described here.
The upgrade procedure does not require a change in license files from 5.0->5.1->5.2. Upgrading (actually re-installing) from 5.2 to 6.0 does require a license files change.
Upgrading from 6.x to 7.x does not require changes to license files.
Currently (2016), Bright licenses are almost always subscription licenses, and issued for a particular cluster. This means that the cluster manager will run while the subscription is active. If the subscription license is destroyed — for example, if the head node goes up in flames — then an administrator can request Bright Computing for a transfer and activation of the existing license to a replacement head node.