Everyware™ Software Framework
· Overview
The ESF software update mechanism uses the Configuration Manager (CM) as the basis to receive updates. However, it can also be called directly by another bundle to kick off an update. Software updates can be complex in how they are transferred to a unit, how they get deployed, and how they are validated. While ESF can’t do all of this since there are so many variables, this is a tool that can eliminate the need to write an update tool from scratch.
The CM is very pervasive throughout ESF. It also has many adapters for receiving Objects. Since a File is an Object it made sense to use the CM for the update mechanism as well. The only difference is the ‘configuration’ is really a File that contains a software update.
Updates need to be carefully considered on a project by project basis. This document will not cover all of the considerations that need to be made there. We will simply cover what the com.esf.core.updater project does and how it works.
The com.esf.core.updater.EsfUpdater implements the com.esf.core.configuration.service.IConfigurableComponentService. In doing so it can receive updates from the Cloud, the CM HTTP Servlet, the local filesystem, or any other yet to be conceived CM configuration provider. This gives the Updater a lot of flexibility without having to write any code with regard to how this is done.
An update must be well formatted. While the receiveConfig method receives a File Object it must be a very specific File Object. It must be a .zip file that contains one or more ‘star’ files and a ‘version_multi.txt’. A star file is a ‘self-extracting tar file’. This is essentially a script with binary data that when executed knows how to extract the contents of the file. However, it also gives flexibility in that a pre and post script can be built into a single file. The star file updates should be named
company_product_update-version.star
For example:
eurotech_helios_denali_update-1.0.1.star
This version number is then pulled out and compared with the current product version held in the /etc/esf/release.xml file. The version should always be in the form MAJOR.MINOR.SUBMINOR.
If the version is newer the update can be copied to the local filesystem and then executed. At this point, the star file is in full control of the system. If it needs to, it can kill the VM, reboot the box, or do whatever it likes. A lot of care must be taken in not deploying updates that can damage the box.
The version_multi.txt contains some metadata about the update. This is an example file:
1.0.1 867b9069ff0188d629c827165bbcc0b6 2511 eurotech_helios_denali_update-1.0.1.star
1.1.0 ab35012fcd058123950fcd23abaa1345 3503 eurotech_helios_denali_update-1.1.0.star
The version_multi.txt file contains the version numbers, the md5sums, the filesizes, and the filenames of the updates. The reason for this construct is that updates can be incremental and it gives the updater a baseline to validate the star files against before applying them. It is important to note that this does not force incremental updates. You can have ‘monolithic’ updates that include all of the previous updates in a single star file. However, this is not recommended in that rolling back becomes more complicated and the updates can grow very large in size over time.
As noted previously this document doesn’t cover how to put the updates together. Although, it should be noted that Eurotech can be contacted for tools to help with the details of constructing .star files. Below are a few recommendations about creating updates.
Copyright © 2010 Eurotech Inc. All rights reserved.