This page sets out the procedure to update an installation with major release version 4.2 to major release version 5.0.
You may wish to use our professional services department to carry out this upgrade.
Note the following:
- FCO version 5.0 contains a completely new user interface, codenamed 'Skyline'. This replaces the old user interface (codenamed 'Amber'). When upgrading, user-interface settings will not be carried across. This means that branding, UI customisations, and view settings will need to be recreated. You may wish to use our professional services department to help you with this if you have made extensive customisations.
- In FCO version 5.0 the admin control panel is now part of the main control panel, and uses the same URL as the main control panel. You should therefore change your bookmarks for the admin control panel, and ensure your resellers do the same.
- In FCO version 5.0, the recommended API endpoints have changed; the API endpoint now forms part of the control panel URL and will benefit from any load-balancing you have in place. The old endpoints are still supported.
- If you are using any plugins, please check the version of the plugin you are running is compatible with FCO v5.0. For plugins produced by Flexiant, our customer operations department will be able to help you do this.
If you are using any language packs, please note that these will need to be reapplied with FCO v5.0. Language packs for v4.2 will not work with v5.0. Therefore please ensure the appropriate language packs are available prior to an upgrade.
As the control panel sites are accessed over a secure connection using the
httpsprotocol, they need an SSL certificate to function correctly. Flexiant Cloud Orchestrator will generate a 'self-signed' certificate if no certificate exists. These self-signed certificates are not signed by a trusted certification authority, and thus will produce security warnings on browsers. The certificate public and private keys are held in
/etc/extility/skyline/ssl/private(for the public and private components of the certificate respectively). They will be named with file names similar to
extility-skyline-26562fbd-19ac-4644-a265-5e86269a5973.crt, the filename indicating the UUID of the billing entity. You can replace these with your own certificate. We strongly recommend you keep a master copy of the certificate somewhere other than on the machine in question. After changing SSL certificates, you will need to run the command
build-config -ato apply the changes. In some cases it may also be necessary to use the
service apache2 reloadcommand.
Do not commence this upgrade procedure until you have read through the entire procedure, and are confident that you have the appropriate skills to carry it out.
A. Preparatory work
Ensure you are running the latest 4.2 release. If you are running an earlier minor release of 4.2, follow procedure to update between minor releases. If you are running a major release earlier than 4.2, you must upgrade to the 4.2 major release first.
Upgrades from versions prior to 4.2.6 will not work
Ensure you update all your nodes and cluster controllers (if separate) as well as the main management stack.
- Ensure you have a complete system backup prior to the upgrade.
- Your system management stack will not run during the upgrade process; ensure you provide an appropriate maintenance window.
/etc/extility/local.cfgand all branding files are backed up prior to upgrade.
- Ensure all system backups are up to date.
B. Upgrading the Operating System of each management stack
FCO v4.2 uses Ubuntu Precise 12.04 LTS. FCO v5.0 requires Ubuntu Trusty 14.04 LTS. Therefore as a preliminary step, you must upgrade the operating system on each management stack.
Stop all FCO services
Ensure you are logged in via
sshor at the console to perform the above operation. VARs with remote-support access to their clients should not use the above command.
- Follow Ubuntu's procedure to upgrade the from Precise to Trusty. You can either read the procedure here (remembering you have a server not a desktop install) or follow the abbreviated procedure set out below:
Ensure your OS has an up-to-date version of Precise before starting
update-manager-coreif it is not already installed:
/etc/update-manager/release-upgradesand ensure it contains the line
Start the upgrade manager:
Follow the on-screen prompts, carefully noting down the instructions given about upgrading Postgres. Unless you created a non-root user to administer the server answer 'no' when prompted to disable root logins over ssh. Remove all packages it suggests removing. Answer the default (no) to all questions to keep the current versions of the files. Allow it to remove the obsolete packages.
The final stage of the operating system upgrade will reboot the management stack.
Upgrading the operating system will install
postgres-9.3. This will by default install a blank cluster (the postgres term for a database). It is thus necessary for you to upgrade your Postgres cluster after the upgrade to bring the original data back. You should follow the instructions you noted above. Use these in preference to what is set out below. If for some reason you have lost them, the normal route is:
C. Upgrading the installation on each management stack
To upgrade the installed FCO software, use the following procedure:
- Ensure that the appropriate packages are installed
For a cluster and control plane server.
For a control plane server.
For a cluster.
Rebuild the configuration:
Ensure services are restarted
- Check all services are running correctly.
- You may wish to reboot the management stack to ensure all services start after a reboot. This step is optional.
D. Upgrading each node
FCO v4.2 uses node images running Ubuntu Precise 12.04 LTS. FCO v5.0 requires Ubuntu Trusty 14.04 LTS, and the kernel that goes with it. Therefore you must reboot each node. This can be done without disruption to running virtual machines by using the procedure set out below for each node:
- Put the node into maintenance mode using the Nodes widget on the admin page.
- Go to each node in turn and run
do-node-update. This will put all nodes into the position where they are running FCO v5.0 software.
- Put all nodes back into running state. This is because they need to be in running state to receive VMs.
- For each node in turn:
- Put the node into maintenance state.
- Migrate VMs off the node to another node. If there is sufficient capacity on a node that has already been upgraded, choose such a node in preference.
- Reboot the node.
- Check the node returns to maintenance state.
- Put the node into running state.
- During the process of (5) above, eventually a point will be reached where there are enough upgraded nodes that the remainder of the un-upgraded nodes can be put into maintenance state. This will allow the use of 'Auto' node on migrate, as only the upgraded nodes will be in running state.