Cloud Computing Made Easy®
Release Notes
From Kaavo - Wiki
Visit Kaavo Website for more information
Release 2.5.0 (August 31, 2010)
- Web Service API Enhancements: Added following additional APIs to the IMOD Web Services interface, for details please review the Kaavo Web Services Documentation
- getSystems(userId, password)
- getNTierDetail(systemName, userId, password)
- getTierDetail(systemName, tierName, userId, password)
- getServerTypeDetail(systemName, tierName, serverRole, userId, password)
- getEvents(systemName, userId, password)
- Enhanced Event Processing: Multiple concurrent events on a system are now processed sequentially in order and the IMOD engine executes the corresponding actions. Duplicate events are ignored
- Speed Up Shutdown process: During Shutdown tier level workflows don't wait for servers to be terminated, they continue after the server shutdown request has been sent to the provider
- Dynamically Defined Event Triggers are now Persisted: Previously only the event triggers defined prior to starting a system were persisted and any event trigger defined while the system was running (dynamic event) was not persisted. To simplify the usage, we removed the distinction of dynamic events and now event triggers defined on a group of servers when the system is running are persisted as well as automatically configured. As these events are persisted, they are automatically configured every time the system is restarted too.
- Improved Disaster Recovery: Improved disaster recovery for the SaaS version of IMOD. Our current SaaS version of IMOD is running in the cloud. In the case of an extremely unlikely event of all datacenters of the cloud provider becoming unavailable, we now have the ability to bring IMOD SaaS version online at an alternate cloud provider in less than 2 hours
- Key Authentication for Terremark: Added support for public key authentication for servers on the Terremark cloud
- Deployment Error Handling: Added ability to customize responses to error conditions during deployment and server configuration by adding onError attribute in the server startup workflow tag <startup timeout="300" onError="Continue"/>
- onError="Continue" means if error occurs the rest of the system will continue ignoring the error
If we do not specify any onError attribute, it will act according to the current default behavior, i.e. the tier and the system deployment will be in error state and users have to manually abort the system and retry the deployment after addressing the issue responsible for the error. See the following example of how to configure this within the serverType tag:
serverType role="loadbalancer" min="1" max="8">
...............................
...............................
...............................
<startupCount>2</startupCount>
<workflow>
<startup timeout="1200" onError="Continue"></startup>
<shutdown/>
</workflow>
...............................
...............................
</serverType>
Release 2.4.0 (August 2, 2010)
- Terremark Cloud Support: Released support for Terremark vCloud Express, enabling users to deploy and manage applications on the Terremark Cloud. We have not tested the Windows OS on Terremark cloud yet; for jump start please refer to the Sample Terremark System Definition provided with this release. Refer to Terremark Account Setup for getting started.
- UI Wizard Support for Physical Servers: Users can now perform hybrid deployments including the physical servers using the Multi-cloud deployment UI wizard. This eliminated the need to manually edit the system definition for adding Physical Servers to deployments.
- Support for EC2 Cluster Compute:: Added support for Amazon EC2 Cluster Compute instance. Cluster Compute Instance has Quadruple Extra Large 23 GB memory, 33.5 EC2 Compute Units, 1690 GB of local instance storage, 64-bit platform, 10 Gigabit Ethernet. Amazon currently support the cluster compute instance for AMI ami-7ea24a17. When configuring the server pick the instance type cc1.4xlarge. You also need to pick EBS as the root device. Following is the snippet of the System Definition XML for the Cluster Compute Instance.
<rootDeviceType>ebs</rootDeviceType> <machineIdentifier>ami-7ea24a17</machineIdentifier> <instanceType>cc1.4xlarge</instanceType> <availabilityZone>us-east-1b</availabilityZone>
- UI Validation Improvement: Added friendly error messages for validating the syntax when editing the Events and Actions from the UI.
- Gluster Deployment System Definition: Released sample system definition for deploying and configuring and running multi-server Gluster on EC2.
- Fine-grain Action Execution: Added, ability to Execute Actions on Individual Servers, i.e. if there are more than 1 server in a group of servers (server roles) users can now specify the actions to be executed on a specific server in the group. This is currently supported in the System Definition XML, in the next release we will add support for this fine grain control in the Action UI. The syntax for executing actions on specific server is [tier=app][serverrole=jira][index=2] e.g. if there are 5 jira servers in the app tier, specifying index=2 will execute the action on the second app server. In previous release the action was executed on all the servers in the group. Users can still execute actions on all servers in the group by not adding the index, e.g. [tier=app][serverrole=jira] will execute actions on all 5 jira servers in the app tier.
Release 2.3.0 (July 2, 2010)
- Physical Server Support: Released support for physical servers, allowing users to manage complex hybrid deployments for workloads using physical servers, private cloud, and public cloud resources simultaneously. For details refer to the Physical Server Section of the n-tier guide. Note in this release UI wizard for configuring physical servers is not supported, so you have to directly add/edit the System Definition XML for physical servers.
- UI for Custom Events: Users can now define custom workflows to be executed in response to pre-defined events using the UI wizard. Making the UI easy to use is very important to us, so please keep on providing the feedback so we can continue to improve it. We appreciate your feedback and hope you like the new improvements.
- Encryption of System Definition: Before this release we were only storing the user sensitive information in encrypted format in the cloud. Starting this release we have started to store the entire System Definition in encrypted format as complex system definition files could have sensitive deployment information.
Release 2.2.0 (May 31, 2010)
- Kaavo Web Services: Released Web Services to allow developers to programatically interact with Kaavo IMOD to manage and deliver on-demand custom apps, SaaS, and PaaS offerings to their customers. Register for the free one hour webinar to learn how to use Kaavo Web Services. For additional information on using Kaavo Web Services please checkout Kaavo Web Services Documentation
- Event UI: Added additional Event tab for deployed systems to allow adding and configuring events using graphical interface. Currently the graphical interface support lifecycle events like pre-shutdown, post-startup, etc. Graphical interface in this release doesn't support custom events, for now please use the online XML editor for the custom events. Currently we support few provider specific commands in pre-shutdown and post-startup tags for Amazon EC2; we are planing on deprecating this support and replacing these commands with common actions. Graphical interface doesn't recognize provider specific commands, please use the XML document for editing them and it is better to write reusable actions instead of these commands. We are continuously improving the user interface to make it easy to create and edit the System Definition so please keep on providing the feedback.
- Forums: Added Forums site for related discussions and issues please sign up at http://forums.kaavo.com and start using it
- Post Execution Delete: Simplified the ability to delete generated file on the server side after executing an action by setting delete-on-exit flag on the action. This is helpful in case there is sensitive information like username or password in the file which shouldn't be left on the server. See the example below.
<action name="start-apache" execute="true" delete-on-exit="true" target="[tier=web_tier][serverrole=default]">
<scriptName>apache.sh</scriptName>
<scriptPath>/root</scriptPath>
<scriptTemplate type="inline">
<