ServerTemplates and RightScripts
Note: ServerTemplates and RightScripts were released on June 25, 2009.
Release Date: June 11, 2009
Release Time: 9:00pm PDT
Description: The focus of this release is:
Please read the release notes in their entirety for a more exhaustive understanding of what comprises this release.
Note: Any numbers in parentheses below are for internal RightScale use only. Please ignore them, they are simply tracking numbers.
- Disclaimer -
The following new features have been added to the RightScale Cloud Management Platform. Be sure to read the documentation, follow best practice principles, and thoroughly test any new functionality before making any changes to your production deployment.
As a practical example, you could define a policy that allows a user with a specific source IP address access to your queue. Or, deny several users access after a certain date.
To learn more, see Simple Queue Service.
AWS announced elastic load balancing earlier this week (June 10). Our new release (June 12) already has support for AWS Elastic Load Balancing. (We continue to offer load balancing support via HAProxy as well.) Look here to see more about the AWS announcment. Navigate to Clouds -> AWS US or EU -> Load Balancing to see it from the RightScale Dashboard. See Elastic Load Balancers.
There is now logging support for CloudFront distributions. You can define an S3 bucket and a path prefix to store access logs. With logging enabled for your distribution, gzipped access logs get stored in a logging folder of your S3 bucket. (For example, /johndoe/logging/ETLCMKFIJFEWX.2009-06-05-19.BM8jZkoX.gz) To learn more, see Create a New CloudFront Distribution.
The browser "back" button now works across tabbed views. For example, if you are looking at a Deployments Inputs tab, then the Scripts tab, the "back" button will take you back to the Inputs tab. (Previously, you would be placed back at the parent in the navigation tree. That is, top level of the Deployments in our example.) (3528)
The following functionality has been added or improved upon for private clouds:
There is now a graphical representation of a server's launch history. Before you could only see information about previous server launches under the server's History tab. System administrators are typically only concerned about the most recent servers that were launched, the current server, as well as the next server launch. All of this information is now graphically displayed for each server.
To learn more see, Server History Timeline.
Similarly, ServerTemplates and RightScripts now have a revision history timeline, which shows the most recently committed revisions of the template/script.
To learn more see, Revision History Timeline for ServerTemplates or Revision History Timeline for RightScripts (3522w)
The new "MySQL EBS" ServerTemplate provides additional flexibility and control for archiving EBS snapshots. Previously, you only had the ability to control how many of the most recent EBS snapshots to save (keep) by defining a number in the DB_BACKUP_KEEP_LAST input parameter (default 60). However, this could result in a large number of backups (snapshots) that might not give you the desired history and coverage that is required for your application. You now have the ability to reduce the granularity around the number of snapshots that are saved for a particular time range, which should help reduce costs and provide more control and flexibility. Additional input parameters are now supported which allow you to define how many daily, weekly, monthly, and yearly snapshots to archive and save.
To learn more, see Archiving of EBS Snapshots. (3472)
You can now run "any script" on a Server Array. Previously, you could only run RightScripts that were attached to a ServerTemplate. (3529) This functions much the same way it does for a regular Server.
When you create a server array, you now have the ability to control which availability zone(s) new instances will be launched into when the array "scales-up" and grows. Previously, all servers of an array were launched into "any" availability zone. There was no way to control where an instance was launched. But, now you have the ability to control into which availability zone new instances will be launched. You can either select a specific zone or use the "Any" (default) or "Weighted" options. The "Any" option will allow Amazon to randomly launch new servers into any of the availability zones within the selected region. (The "any" option was the previous functionality that was used for launching servers in arrays.) The "any" and "weighted" options disperse your servers across multiple availability zones, which theoretically prevents all of your array servers from suddenly disappearing if an availabilty zone ever failed. The 'Weighted' option allows you to control the ratio of server dispersion. For example, if you wanted to launch a majority of servers into a particular zone (us-east-1a), you can give 'us-east-1a' a larger weighted value than the other zones. Similarly, you may want to launch all of the array servers in the same zone as your deployment to prevent incurring any cross-zone data transfer costs. Server arrays created prior to this release will inherit the "any" option.
Note: Associated cross-zone data traffic rates do apply.
To learn more, see Arrays.
Previously, you did not have the ability to edit a server array's inputs. You were forced to define the inputs at the ServerTemplate level. Now, you have the ability to define inputs at the server array level. Inputs that are defined at the server array level only apply to new instances that are launched and will overwrite input parameters that are set at either the template or deployment level (same input hierarchy applies). If you need to update the inputs of an operational server in the array, you will need to manually update each server individually.
You now have the ability to update the ServerTemplate revision of an operational (not stranded) server. When you change the revision of a template (ex: rev1 to rev2), the running server will only get the inputs and scripts from the new template revision. Even if rev2 specifies a different machine image (AMI/RightImageTM ) or instance type, these settings cannot be updated for obvious reasons. If you are following best practices, you are launching servers with committed ServerTemplate revisions in order to preserve a server's launch settings. However, you may want to "forward roll" a running server instead of having to launch a new server (rev2) and terminate the old server (rev1) whenever you need to use a new/different ServerTemplate revision. The functionality is now supported.
Changes to the software are listed here. Changes usually refer to enhancements to existing features, minor UI changes, additional logging or messaging, etc.
The Scripts Inputs tab of a running server was removed. Previously, a running server had an Inputs and Scripts Inputs tab. The Script Inputs tab showed the inputs of the current running server while the Inputs tab showed the input parameters that were used to launch the server (the same input parameters would be used for future server launches. In this releaase, we added the History Timeline bar to a server's show page, which allows you to see and edit the inputs of future ("next") server launches. There is now only one Inputs tab for a server. If you are looking at the "current" running server, the Inputs tab will show the inputs of the running server. Any changes to the Inputs tab of a running server will only affect the current running server. But, if you click the Inputs tab of the "next" server in the History Timeline, you can view/edit the inputs of all future launches of that server. Inputs that are defined under the "next" server's Inputs tab will persist and overwrite inputs defined at either the template or deployment level. The functionality of a server's inputs is the same, but the location of where you view and define those values has changed since the addition of the History Timeline bar. Hopefully, this will help eliminate confusion over inputs and where to define them.
We discovered late in the development cycle that a backwardly incompatible change to the RightScale API was required.
The call to attach an Alert Specification to a Server or ServerTemplate (POST /api/acct/1/alert_specs_subject) will have new semantics when one alert specification is attached to multiple Servers or ServerTemplates. We do not believe this affects any customer API usage but if you are using this call in your automation script please contact us so we can work with you to resolve any issues that the change might have caused.
The location of Alert Specification has moved in the User Interface of the RightScale Dashboard. Previously, this was under Design -> Alert -> Specifications. Now you will find Alert Specifications in the Alerts tab in the following three locations:
Note: Server Array Alert Specifications come from the ServerTemplate
This change makes Alert Specifications subordinate to one of the three above. Previously, you would create a single Alert Specification and it would exist outside of any context. That is, you would create it and then then associate that Alert Specification to a Server, ServerTemplate or an Instance. If a change was made to the Alert Specification, it applied to all. That implementation is far too sweeping, in that a change to the specification applies across the board (e.g. global), which does not always have the desired effect. With the new implementation you create a specification for a Server, ServerTemplate or Instance from their respective Alerts tab. (You do have the ability to "copy from" one to the other however. That way you do not have to create an Alert Specification from scratch when one already exists that is very similar in nature to your current needs.)
This release has added a Multi Cloud Name to the Settings for each image. Although the change seems subtle, and most users will not take advantage of this immediately, the implications are profound. With the advent of AWS clouds in the US and EU, and private clouds such as Eucalyptus, we needed a mechanism whereby a single ServerTemplate could be used across multiple cloud types. There is an implicit mapping of the Multi Cloud Name Setting to a specific Image. This is best explained by way of example.
To summarize, you now have a single ServerTemplate that will work across multiple clouds. The ServerTemplate references one image. However, that image is specifically identified by a mapping from the Multi Cloud Name. That is, the Multi Cloud Name maps to a specific image with a unique AWS ID. In our example, either an image in the US, or an image in EU.
The control flow has been improved when a RightScript is missing an Input value for a Server Array. The flow summary is as follows:
Previously, the "Filter by Name" search field for RightScripts was case sensitive. The search field is no longer case sensitive, but we've added a "case sensitive" checkbox for added convenience. (2805w)
When you click the Merge button when viewing a ServerTemplate's show page, it will automatically prepopulate the pulldown with the current template. Previously, the pulldown fields were blank, which could cause confusion/error when performing a merge. (3439w)
Previously, you were able to clone a previously deleted ServerTemplate and "resurrect it" if you built the correct url string using the template's ID. This functionality is no longer supported. (3061w)
Previously you were able to clone a shared ServerTemplate that references an AMI that is not publicly accessible. However, since the AMI is private, you would not have permission to use that AMI in your cloned ServerTemplate and successfully launch servers. Unfortunately, no warning message was being displayed to explain this potential problem. You will now see the following warning message, "One or more of your server images is not publicly accessible and may not be available to the users in the ___ sharing group." (2770w)
The following bugs have been resolved in this release.
Selecting a server lock or unlock action icon no longer requests user confirmation to complete, the action is carried out immediately. This operation is deemed rather benign, hence does not warrant user confirmation. (3334w) Note: this is the primary use case, there are other areas in the Dashboard where user confirmation has also been removed.
Redundant revisions of a RightScript would be created if you committed multiple ServerTemplates that referenced the same uncommitted [HEAD] RightScripts. If you committed the first template, a new RightScript revision would be created if no revision existed or if something was different (correct behavior). But, if you committed the second template, a new RightScript revision would be created that was identical to the previous revision (incorrect behavior), resulting in redundant RightScript revisions. You should not be able to create multiple revisions of a RightScript that are the same. Now, if you commit a ServerTemplate that is referencing a HEAD revision of a RightScript that was recently committed, a comparison will be made between the last committed revision and the HEAD revision of the script. If there are no changes, you will not be able to commit the same script and create a redundant revision. If the revisions are identical the most recent revision of the RightScript will be used. (2780w)
Previously, developer account users were able to submit tickets from the Support link in the Dashboard. Only premium account users should be able to submit tickets. Developer account users are now prompted to either visit the forums or upgrade their account. (2357w)
Previously, you were unable to successfully use the "Update to latest RightScripts" button if there were more than five uncommitted HEAD RightScripts. This problem was fixed. (3284w)
The diff functionality was not working correctly at all times. For example, sometimes it would incorrectly show "modified" information when information was identical in both revisions. The diff functionality should work as expected. (3439w)
Previously, you were unable to select and use SSH keys whose names contained a colon. (e.g. my:key, :12) This problem was fixed. You can now select and use SSH keys whose names contain colons. (3504w)
Several cosmetic annoyances have been resolved with the new UI. Exact issue differs somewhat depending on the browser type, but the following is a brief summary of what was resolved:
Note: There are many other changes and improvements that are very minor or intermittent in nature. An exhaustive list of all such changes is no listed here.
When a server in a Deployment is terminated, the graphic (down arrow) that indicates it is terminating was not showing. Recenty Activity did report correctly however, and functionally the Server did terminate properly. (3422w)
The "No ssh key" growler message (a temporary bubble pop-up in the upper right portion of the Dashboard) was repeated more than one time. This has been resolved so the message is only displayed once. (3608w)
There are no known unresolved issues.
Please report issues to: firstname.lastname@example.org
New and significant changes for this release with respect to ServerTemplates and RightScripts are summarized below. New and updated ServerTemplates and RightScripts are typically released 2-5 days after the new release of the RightScale Cloud Management Platform. Updated status messages with respect to actual release date/time of the ServerTemplates and RightScripts will be found here within this document.
ServerTemplates and RightScripts were released on June 25, 2009.
Warning! - RightScale ServerTemplates are published with frozen repositories and are associated with a particular RightImage. There is no guarantee that newer RightImages (RightImages CentOS v4.1.15 and 4.1.20 for both the US and EU regions and 32- and 64-bit versions) will work correctly using older versions of software packages in the frozen repositories. To ensure that an older ServerTemplate works with one of the newer RightImages, you will need to clone the template and refreeze the software repositories to a more recent date where the RightImage and the repositories are compatible. Always check to make sure that a server will boot correctly.
There is a new suite of RightScripts that allows you to utilize EBS filesystems for any application. (Previously, our ServerTemplates and RightScripts were MySQL-centric.) You will be able to use these RightScripts for applications that require persistant storage, taking full advantage of EBS features such as snapshot backups.
The following is a summary of the new RightScripts. Please see the Descriptions on their individual Info tabs for more information. For specific details, please see the actual RightScript content. (3053)
Both the DB EBS RightScripts and the EBS RightScripts mentioned above contain enhanced snapshot control. This is implemented using RightScript inputs for daily, weekly, monthly and yearly values. The implementation works the same for both the DB EBS and EBS RightScripts. To learn more, see the Archiving of EBS Snapshots.
This template uses the Percona MySQL RPMs and currently only works on 64bit images. This template configures MySQL servers to act as a master or slave in a RightScale Manager for MySQL setting. Storage of MySQL data will be done using EBS volumes. Percona(http://www.percona.com/) provides pay-as-you-go, prepaid and retainer-based consulting to create or scale applications built on the full LAMP stack (Linux, Apache, MySQL, PHP) and other open source technologies.
This template uses the Percona High Performance MySQL RPMs and currently only works on 64bit images. This template configures MySQL servers to act as a master or slave in a RightScale Manager for MySQL setting. Storage of MySQL data will be done using EBS volumes. Percona(http://www.percona.com/) provides pay-as-you-go, prepaid and retainer-based consulting to create or scale applications built on the full LAMP stack (Linux, Apache, MySQL, PHP) and other open source technologies.
Supports the new version of TomCat. The "TomCat6 FrontEnd v6" ServerTemplate already existed prior to this release.
This template uses RightGrid v1.3.0 which only supports second generation SQS queues and the 'one-shot' invocation model. If your application needs 'persistent' invocation, you have to use RightGrid v1.2.3 or less (RightGrid Worker v4).
MULTICLOUD AWS-US & AWS-EU TEMPLATES
EBS Toolbox [rev 1]
Hadoop JobTracker [rev 4]
Hadoop Namenode [rev 4]
Hadoop Slave [rev 3]
MySQL Additional v13 [rev 4]
MySQL Bootstrap v13 [rev 4]
MySQL EBS [rev 12]
MySQL EBS (Ubuntu) [rev 4]
MySQL EBS Percona (Alpha) [rev 2]
MySQL EBS Percona HighPerf (Alpha) [rev 2]
Rails-Passenger App Server v1 (Ubuntu Alpha) [rev 1]
Rails-Passenger FrontEnd v1 (Ubuntu Alpha) [rev 2]
TomCat5 App Server v6 [rev 5]
TomCat5 FrontEnd v6 [rev 5]
TomCat6 App Server [rev 1]
TomCat6 FrontEnd v2 [rev 5]
MULTICLOUD AWS-US, AWS-EU & GOGRID TEMPLATES
MySQL Additional (GoGrid Alpha) [rev 1]
MySQL Bootstrap (GoGrid Alpha) [rev 1]
PHP App Server (GoGrid Alpha) [rev 1]
PHP FrontEnd (GoGrid Alpha) [rev 1]
Rails AppServer (GoGrid Alpha) [rev 1]
Rails FrontEnd (GoGrid Alpha) [rev 1]
New RightScripts are noted as [rev 1].
DB Delete EBS volume on halt [rev 5]
DB EBS backup [rev 8]
DB EBS continuous backups [rev 8]
DB EBS restore and become master (Ubuntu) [rev 3]
DB EBS restore and become master [rev 8]
DB EBS slave init at boot [rev 6]
DB EBS slave init from non-EBS master [rev 6]
DB EBS slave init from non-EBS master v2 (Ubuntu) [rev 3]
DB MySQL gem install v5 [rev 2]
DB MySQL gem install v7 (Ubuntu) [rev 1]
DB MySQL server install v8 [rev 6]
DB MySQL server install v9 (GoGrid Alpha) [rev 2]
DB MySQL-Percona server HighPerf Install (Alpha) [rev 2]
DB MySQL-Percona server install (Alpha) [rev 1]
DB Rightscale tools install v10 [rev 15]
DB continuous backups v5 (GoGrid Alpha) [rev 2]
DB privileges set v1 [rev 3]
DB promote to master v3 (GoGrid Alpha) [rev 2]
DB unfreeze binary backups v1 [rev 2]
DNS dnsmadeeasy external id register v1 [rev 3]
DNS dnsmadeeasy external id register v2 (GoGrid Alpha) [rev 2]
DNS master DB register v2 (GoGrid Alpha) [rev 2]
EBS Rightscale tools install [rev 2]
EBS delete volume on halt [rev 2]
EBS freeze volume backups [rev 2]
EBS unfreeze volume backups [rev 2]
EBS volume backup [rev 2]
EBS volume continuous backups [rev 2]
EBS volume restore [rev 2]
GoGrid LVM Partition v1 (GoGrid Alpha) [rev 2]
Hadoop Get Master IP's [rev 2]
Hadoop Insert Slave Adder Script [rev 3]
Hadoop Insert hadoop-env.sh [rev 2]
Hadoop Insert hadoop-site.xml [rev 2]
Hadoop Install [rev 3]
Hadoop Start Map-Reduce [rev 2]
LB app to HA proxy connect v4 (GoGrid Alpha) [rev 1]
LB app to HA proxy disconnect v3 (GoGrid Alpha) [rev 1]
LB app to local HA proxy connect v4 (GoGrid Alpha) [rev 1]
LB mongrels to HA proxy connect v6 (GoGrid Alpha) [rev 1]
LB mongrels to HA proxy disconnect v5 (GoGrid Alpha) [rev 1]
LB mongrels to local HA proxy connect v3 (GoGrid Alpha) [rev 1]
MAIL Postfix Local Delivery v1 [rev 3]
MAIL Postfix Local Delivery v3 (GoGrid Alpha) [rev 1]
MISC ssh priv key install v2 [rev 3]
MISC ssh pub key install v1 (GoGrid Alpha) [rev 2]
RB custom gems install v3 [rev 3]
RB rails svn code update & db config v4 [rev 5]
RB rubygems 1.3.1 + quickinstall v4 [rev 2]
SYS Add Swap Partition [rev 3]
SYS Monitoring Apache Add v2 (Ubuntu) [rev 3]
SYS Monitoring MySQL add v7 [rev 5]
SYS Monitoring MySQL add v8 (Ubuntu) [rev 3]
SYS Monitoring install v7 [rev 5]
SYS Monitoring install v8 (Ubuntu) [rev 3]
SYS RAILS_ENV into system profile v2 [rev 2]
SYS REBOOT END Decommission [rev 2]
SYS Syslog Remote Logging Client v6 [rev 6]
SYS lvm on /mnt v10 (GoGrid Alpha) [rev 2]
WEB PHP remove v1 (GoGrid Alpha) [rev 1]
WEB TomCat Connector (Mod_JK) install from src v3 [rev 5]
WEB TomCat6 install v1 [rev 3]
WEB apache FrontEnd http vhost v3 (GoGrid Alpha) [rev 1]
WEB apache FrontEnd https vhost v3 (GoGrid Alpha) [rev 1]
WEB apache http-only rails vhost v5 (GoGrid Alpha) [rev 1]
WEB apache http-only vhost v6 (GoGrid Alpha) [rev 1]
WEB apache rails-passenger http-only vhost v5 (Ubuntu Alpha) [rev 3]"]
© 2006-2009 RightScale, Inc. All rights reserved.
© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.