Warning: This document describes an old release. Check here for the current version.
Upgrading from Nimbus 2.5 to 2.10
As of 2.6, Nimbus includes the ./scripts/install-from program which aids in the migration from a previous Nimbus installation.
Instead of installing with the normal method (./install <target_dir>), you will give the installer an initial configuration basis to work from.
Before using ./scripts/install-from you must have zero VM instances deployed. This can be accomplished in a friendly way to your users by temporarily moving the vmm-pools files to a safe location and replacing them with a blank file. Restart the service and it will allow the current VMs to continue as usual but have zero VMM space to use for new leases.
OK, so you have no VMs deployed and the services and Cumulus are stopped?
Time to run the 2.6 installation with ./scripts/install-from. After downloading and expanding the 2.6 services tarball, run:
./scripts/install-from /home/nimbus/2.5 /home/nimbus/2.6
... where /home/nimbus/2.5 is the NIMBUS_HOME of your previous installation and /home/nimbus/2.6 is where you want to put the new one.
The script will install Nimbus 2.6 as normal but take into account configurations that were made in your previous installation.
When it is done running, there are still three tasks ahead of you:
The first thing to do is look over all of the "Configuring installed services" messages for any warnings about absolute paths. If you are using non-standard configurations for things in the nimbus-setup.conf file, these will be left alone and not copied into the new Nimbus install.
A diff command will be printed at the end of the install-from process which will allow you to look for any customizations you made to some of the service configurations.
The install-from process will pick up most of the configurations, but not every last customization. This diff command will assist you in the final touch-ups with the move.
Importing the VMM nodes that were configured. Nimbus 2.6 introduces a new, more powerful way of configuring VMMs using a tool called nimbus-nodes. This requires the service to be running, though, so it cannot be used during the install-from process.
The exact command to use (once you've started the service) is printed at the end of the install-from process.If you are migrating from any version greater than 2.5 the process for converting worker nodes requires the manual use of the program nimbus-nodes. Fortunately this program is easy to script around. An example python program for this can be found here
Here is an example of what should be different.
Last but not least, notice that this is only a process that helps you with the services node. If you want to get the latest changes in workspace-control, you will need to replace it.
With a 2.5 to 2.6 transition, you can use the 2.5 workspace-control with the 2.6 service if you do not want to activate the new LANTorrent feature. If you do want to activate LANTorrent, you will need to use the 2.6 workspace-control package.
NOTE: the Cumulus image and user database is migrated from the previous NIMBUS_HOME to the new one. However, this database points to objects (files) that are being stored by absolute path. The migration process does not move all the Cumulus data objects, only the metadata.
This has two ramifications.
As the default location of the data is under NIMBUS_HOME (in 'cumulus/posixdata'), take care not to 'rm -rf' the entire old NIMBUS_HOME once the new installation is working!
New uploads can be configured to continue to be sent to that directory but the default configuration is to put new data objects into the new NIMBUS_HOME's 'cumulus/posixdata' directory.
As you can see with the diff command, this process is not foolproof yet, it is however something that gets you most of the way. If you have questions, as always do not hesitate to contact the help list.