Release Notes Monterey Version 3.2.0 (v3.2 GA) New Features ------------ This release mainly focuses on multi-cloud support. Key features include: 1. Multi-cloud. Monterey Networks can span multiple clouds. 2. GoGrid and VCloud support 3. Improved support for running on a fixed pool of existing machines. 4. Definitions of locations. The way to define locations has been significantly improved. The main area visible to the user is when defining the locations of private clouds. 5. Ability to inject custom behaviour during provisioning of network nodes. 6. It is now easier to configure https communication for the management node's web api. Upgrade Instructions -------------------- There is an update site available for installing and upgrading Monterey, e.g. into SpringSource Tool Suite or a vanilla Eclipse. If installing the stand-alone product, we recommend that you install this version in a different directory to any existing Cloudsoft software. Once you have confirmed your new version works, you can delete the old install. Backwards Compatibility ----------------------- The following affect backwards compatibility: 1. The way Cloud Environments and Cloud Accounts are stored has changed significantly. Any cloud environments created in previous versions will not be available in v3.2. 2. The annotation Java15Compatibility has been removed. Existing tutorial projects (or any projects based upon a tutorial) may show an error reporting that the class is missing. The lines containing the annotation can safely be deleted. 3. The location property of MontereyNetworkEndpointImpl has changed to the iso 3166 code. Old values must be updated (for example "London" is now "GB-LND"). Supported Versions ------------------ For the 3.2 release, Eclipse 3.6 and Java 6 are supported. Older versions, including Eclipse 3.5 and Java 5, are no longer supported. Deprecated Features ------------------- The following have been deprecated, and will be deleted in a future release: 1. The run configuration for "Monterey Simulator" is deprecated, and will be deleted in Monterey v4.0. This feature launched a Management Console with an embedded Monterey network in the same JVM. Instead, use the Clouds View to launch and manage your applications in Simulator. Known Limitations and Issues ---------------------------- Known limitations and issues are as follows: 1. When the clouds view is opened for the first time, you will be prompted to allow storage of your confidential information in your keychain. If you deny the operation the clouds view fails to open. STS/Monterey Studio then needs to be restarted in order bring the prompt up again. 2. For STS on Windows, when installing Groovy and Cloudsoft from the update site, then STS needs to be restarted with -clean. Otherwise, the newly intalled features will fail to initialize. 3. On the Mac platform, sometimes MontereyStudio does not detect a default installed JRE. To fix this, immediately after installing MontereyStudio, refer to the "Troubleshooting" appendix in the user guide and follow the instructions under the heading "On Mac OSX, Java compiler errors: ...only available if source level is 1.5" 4. On Windows, the Monterey clouds view usage of SSH will not work unless ssh.exe and scp.exe are available on the path. 5. A workaround is required to use the update site for the stand-alone Monterey Studio product. The old Eclipse update manager needs to be enabled (Preferences -> General -> Capabilities -> Enable "classic update"), and then the update site accessed via Help -> Software Updates -> Find and Install... 6. When the Management Console is started, any bots will be reconfigured to have a workrate of zero. This is because the bot view in the management console includes its own configuration, which is pushed out to all bots on startup. 7. It is only possible to shutdown nodes in a Monterey network while an application is deployed. To shutdown nodes after undeploying will required temporarily re-deploying an application. 8. For SSH Lab-mode (Enterprise Edition only): when running multiple nodes on a single machine, each node should have a different monterey-network-node directory. Otherwise, the multiple processes can interfere with each other when writing to the OSGi cache. 9. GoGrid provisioning sometimes fails when there are many consecutive calls to their web api. The GoGrid requests return "403 Forbidden". This is most likely when several nodes are being provisioned concurrently. Under the covers, Monterey uses jclouds so this should be improved by GoGrid and by a future jclouds release to reduce the number/frequency of api calls. A future release of Monterey may also include back-off and retry logic. 10. VMs in an Amazon cloud very occasionally do not provision correctly; they occasionally transition to terminated without ever starting. VMs also occasionally take longer than 10 minutes to start - Monterey provisioning will then timeout for that VM. This can slow down provisioning and interfere with some Monterey management policies. This does not affect Enterprise Edition installations on other cloud infrastructures. 11. The vCloud integration has been tested on an ENKI installation using v1.01. If another vCloud is using a different version or is configured in a significantly different way, the Monterey integration may not work. The next release should support additional vClouds. 12. It is not recommended to change the Amazon AWS Instance Type. The Monterey AMIs are not available in all Instance Types so may not launch successfully. The JVM is started with the same heap size for all Instance Types, so will not benefit from the extra memory of larger instances. 13. Editing the credentials of a cloud account or cloud environment will only take effect for newly-created networks. Existing networks will continue to use the old credentials. 14. In a cloud environment, the different cloud accounts must each use different locations. The same location must not be selected for two different accounts. 15. If Monterey Studio is installed in a different location to a previous version, OS X may not associate keychain information correctly, preventing the clouds view from opening. To enable access, edit the 'Access Control' property tab for the 'equinox.secure.storage' application password in the 'keychain Access' application, and add the Monterey Studio application manually. Note that this storage area is shared between all eclipse applications, so care must be taken when modifying it. 16. In Eclipse on the Mac, 32 bit SWT is more reliable than 64 bit. We therefore recommend that the 32 bit download of Monterey Studio (and of STS or Eclipse). 17. When using a 32 bit install with a 64 bit JVM, you will need to configure the installed JRE within Eclipse to use -d32. This is described in the troubleshooting section. The troubleshooting section of the Monterey User's Guide may be useful for resolving other problems you may encounter. The forum at http://forum.cloudsoftcorp.com is also useful.