Inheritance of Inputs

Overview

Inputs can be defined at several different levels and each level has its own set of input tabs. The enforced input hierarchy rules help you more efficiently manage server configurations across a deployment. It's important to understand the input hierarchy rules and how they're applied to servers so that you can control which values will ultimately be inherited and used when a script is executed.

Important!  Input hierarchy rules are only evaluated and applied to a server at launch time. Once a server is operational, the input values are saved locally to the current server. If you want to change the input on a running server, you need to modify the input value under the "current" server's Inputs tab and run the associated script. Any changes to a "current" server will not affect future launches or relaunches of that server unless the setting is preserved at one of the input hierarchy levels.

• RightScript / Chef Recipe - The lowest level of precedence is at the script level.
• ServerTemplate - Define commonly used generic values for inputs at the ServerTemplate level. Inputs defined at the ServerTemplate level overwrite values set at the script level.
• Deployment - Define inputs that you want all servers in your deployment (or associated server arrays) to use at the deployment level. Inputs defined at the deployment level overwrite inputs defined at the ServerTemplate or script level.
• Server / Server Array - The highest level of precedence is the server or server array level. Inputs defined at this level overwrite inputs defined at any other level.

ServerTemplate Level

Typically, most servers inherit their input values from their ServerTemplates. Many of the ServerTemplates published by RightScale already have default values that are predefined for many of the more generic inputs, which helps streamline and simplify the setup process for end users. Only application-specific inputs should be left undefined since they are unique to each setup. To improve the usability of your ServerTemplate, keep the number of undefined inputs at the ServerTemplate to a minimum. Setting values for your Inputs is arguably the most difficult part of becoming proficient using the RightScale Dashboard to manage your cloud assets. Using our ServerTemplates as a starting point for what you build and manage in the cloud facilitates using sensible settings for your inputs. Although you can change or override the default inputs of a ServerTemplate, making unnecessary changes increases the risk of entering incorrect or invalid input settings.

Deployment Level

Input values defined at the deployment level take precedence over any input values defined at the ServerTemplate level. When you edit and define input values at the deployment level, they are inherited by all servers in the deployment and overwrite any input values that are inherited from ServerTemplates or scripts. It's useful to define inputs at the deployment level if you have multiple deployments that use the same ServerTemplate revision.  For example, your 'staging' deployment might use the same ServerTemplates as your 'production' deployment. In such cases, you can modify inputs for the 'staging' deployment in order to isolate it from the 'production' deployment so that you do not accidentally overwrite data on your production database.  In the following example, we changed the ADMIN_EMAIL input at the deployment level.

Server / Server Array Level

Lastly, inputs that are defined at the individual server or server array level overwrite input values that are defined at the script, ServerTemplate or deployment levels.  In the following diagram, notice that the values that are set at the server level are inherited by the server. 

As a general rule, you should always define inputs at either the ServerTemplate or deployment levels for configuration settings or changes that you want to persist across your current deployment, as well as for future server launches/relaunches. You should only define inputs at the server level for making temporary changes. The ability to define inputs at the server level should only be used in unique situations or for performing quick tests on a single server. In a production environment, it's important to define inputs at a higher level for organizational and consistency reasons.  For example, let's say you define the location of your SVN repository for application code (Input: SVN_APP_REPOSITORY) at the deployment level.  Now, when you need to perform an update to your application and point to the latest branch, all you have to do is change the value in one location and then run the code update script (RightScript: WEB app svn code checkout) across all servers in the deployment.  In a single action you just updated all of your application servers, performing code pushes easily.

Best Practices for Inputs