Release Notes Monterey Version 3.3.0 Milestone One (v3.3 M1) New Features ------------ Key features in this milestone release include: 1. Support for CDI and Seam, including a new Seam Booking tutorial. 2. Monterey available via maven at http://developers.cloudsoftcorp.com/download/maven2/; this greatly simplifies the user experience for Spring and Seam developers. 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 ----------------------- Monterey version 3.3 M1 is backwards compatible with version 3.2. Supported Versions ------------------ For the 3.3 M1 release, Eclipse 3.6, STS 2.6 and Java 6 are supported. For Eclipse 3.7 and Java 7, testing is still ongoing. Any user feedback is gratefully received! STS 2.7.x is currently not supported, but will be in the next milestone release. 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 installed 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 many 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. 18. When querying or creating segments at a mediator (i.e. in MediationSegmentService, using segmentServiceContext.getSegmentSupport().getSegments()), the call will hang if done from inside the doMediation method. Instead, the call must be done in a new thread so that the doMediation method returns. This is because getSegments causes request/response messages to be sent to the management plane, and it is the same thread that will process the response message before getSegments can return. 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.