CloudCenter 4.8 has reached End of Life (EOL) as of November 14, 2018. See End of Support Notices for additional context.

Using Parameters

About Parameters and Macros

Parameters (also referred to as macros) are global or tier/step-specific system- or user-defined variables for which values can be provided at deployment time. These parameters can be used as tokens or macros inside the application's configuration file or configuration scripts. At deployment time, the macros are replaced by the actual values specified in the parameter.

The CloudCenter platform allows you to define your own parameters or use CloudCenter-supported parameters.

Understanding Service and Deployment Parameters

Service Profiles and Application Profiles use two types of parameters:

  • Service Parameters

  • Deployment Parameters

Service Parameters  

Service Parameters are initially defined in a Service along with optional values. Service Parameters are not available in a deploy flow.

When you add a Service to a tier in an Application Profile, all Service Parameters and values are copied over from the defined service to the Application Profile tier. 

  • You can optionally change the value(s) of a service parameters during the application modeling process.

  • Once Service Parameters are saved in an Application Profile, they decouple themselves from the Service Parameters in the Service

    • Any change in the values of Service Parameter in the Service will not be reflected in the Application Profile

    • For String, List or any other parameter type, the value will be stored in the Application Profile.  

  • New Service Parameters that are added in the Service are not automatically added to all Application Profiles that have this Service as a tier

  • When modifying Service Parameters in Application Profiles:

    • New Service Parameter = you must edit and save the Application Profile with the correct values 

    • Existing Service parameters:

      • Are NOT automatically updated based on the values in the Service Parameter (during an edit process).

      • These parameters need to be explicitly overridden. 

Example 1: 

    • If the MySQL Service in your environment has a Service Parameter, called mysql_password with the value set to mysql_service_password.  

    • When modeling an Application Profile, you saved the Application Profile without editing the password. Now the value mysql_service_password is saved in the Application Profile for this parameter.  

    • Later, you edit the mysql_password Service Parameter in the Service to a new password (for example, new_mysql_service_password). Now, the older password mysql_service_password, is still retained and used in the Application Profile.

Example 2: 

    • This example uses the List type for a Service Parameter, called number_of_instances defined in a Service. The initial values for this List is defined as 1 and 2, with 2 being the default value. 

    • When modeling an Application Profile, you saved the Application Profile with that Service using the value as 2 for this Service Parameter.  

    • Later, the Service was modified to add Values 3 and 4 for the number_of_instances Service Parameter. However, the value of 2 will continue to be used in newer deployments of the existing Application Profile, until you manually edit the Application Profile and select one of the newly added values (3 or 4) from the dropdown and save it again.  

Deployment Parameters 

Deployment Parameters can be defined in either a Service or an Application Profile. Deployment Parameters defined in a Service are inherited by the Application Profile that uses the Service as the tier. 

  • The value(s) for a Deployment Parameter:

    • Are inherited from a Service or created in an Application Profile.

    • Can be modified during the Application Modeling process and at Deployment time, based on the visibility preference set in the parameter.  

  • If you define a Deployment Parameter in a Service and use the Service in an Application Profile, and later edit the Service with the parameter value, then:

    • The deployment parameter is automatically updated for the existing saved applications.

    • The default values for the parameter type of either string, type, or number is picked from the service until it is modified and saved in the application. 

  • The exception is when a user explicitly overrides the value of the inherited Deployment Parameter in the Application Profile. In this case, manually overridden values are not updated when their value is changed in the Service 

  • New Deployment Parameters added in a Service are automatically added to all Application Profiles that use the Service as a tier. 

Example 1:

    • If the MySQL Service in your environment has a Deployment Parameter called, mysql_password with a value of mysql_service_password. 

    • Two scenarios: 

      • When modeling the application that uses the MySQL Service, you saved the Application Profile without editing the value for the mysql_password parameter. At a later time, the value of this parameter in the Service was changed to new_mysql_service_password. Immediately, the new value is automatically updated in all Application Profiles that use this Service as a tier. You do not need to explicitly edit the Application Profile and change it. 

      • When modeling the application that uses the MySQL Service, a user changed the value for the mysql_password in the Application Profile to new_app_level_mysql_password. At a later time, the value of the parameter is changed to new_mysql_service_password in the Service. The specific Application Profile and deployments initiated from that Application Profile will continue to use the overridden parameter new_app_level_mysql_password 

Example 2:

    • This example uses the List type for a Deployment Parameter, called number_of_instances defined in a Service. The initial values for this List is defined as 1 and 2, with 2 being the default value.

    • When modeling an Application Profile, you saved the Application Profile with that Service using the value as 2 for this Deployment Parameter.  

    • Later, the Service was modified to add Values 3 (default) and 4 for the number_of_instances Service Parameter. Existing applications will pass the value of 3 to new deployments.

    • However if the value was initially overridden to 1 in the Application Profile and saved, then after changing the value in the Service to 3 & 4, 1 is passed to the deployment.

When to Use Deployment Parameters

  • In you environment, you may sometimes use Service Parameters instead of using Deployment Parameters. 

  • If you use a Service Parameter, called SAMPLE_AB_Deployment where you use a different set of values for each Application Profiles(where you set No for Test Environments and Yes for Production Environments ). In this case:

    • Yes = the old and incorrect value. 

    • The Service Parameter value does not change in any of the Application Profiles – it continues to use the older value.

    • If you remove the Service and again add it, it will update to the new Service Parameter value.  

  • To avoid this issue when you require the inherit behavior, consider using Deployment Parameters instead of Service Parameters.  

  • In this example:

    • Define SAMPLE_AB_Deployment as a Deployment Parameter.

    • Do not override the value for this parameter in the Application Profile – by doing so, when you flip the value in the Service it will automatically be flipped in Application Profiles as well.

Defining Parameters

When adding a new service, you can use global parameters, tier/step-specific system parameters, or user-defined parameters and add values at deployment time.

  • Service Parameters: These parameters are specific to a newly-added/modified service. The parameter is called when a user calls this service. See Define a Custom Service and Service Administration for additional context.

  • Global Parameters: These parameters apply to all tiers and steps within this application as displayed in the following screenshot.

  • Deployment (Custom) Parameters: These parameters are specified for each step or tier within an application as displayed in the following screenshot. See Application Tier Properties for additional context.

Parameter Type

Regardless of the parameter being defined at the service level, the global application level, or at a tier level, you can specify the Type for each parameter, as shown in the following screenshot.

The Type dropdown enables you to determine your own value for a custom field:

 by selecting one of the following options from the Type dropdown list.

TypeDescription
string

Provide an alpha-numeric value (limited to 255 characters).

API Enumeration = string (valueConstraint)

number

Provide a range of numbers (limited to 255 characters).

API Enumeration = number

list

Provide a list of comma separated text values (limited to 255 characters).

API Enumeration = list (valueList)

webservice

WebService is a parameter type introduced in CloudCenter 4.4.

You can provide list of dynamic webservice parameters while deploying a job. From this list, users can select one parameter. The webservice parameter type is available in custom parameters, global parameters, and services. The output should be in the following format:

[{"name":"p1","displayName":"Param 1"},{"name":"p2","displayName":"Param 2"}]

If you configure this parameter type, you must provide the Protocol (HTTP or HTTPS), Web Service URL, and the credentials (Username and Password) for this webservice.

To use this parameter type, you must set the Content-Type to be returned by webservice as application/html.

API Enumeration = webservice (webserviceListParams)

password with confirmation

Provide an alpha-numeric value (limited to 255 characters).

The UI provides a confirmation textbox.

API Enumeration = password_input (valueConstraint )

password

Enter text with no constraints – for example, use this field for a password that just needs to be entered without validation or confirmation.

The UI does not provide a confirmation textbox.

API Enumeration = password

path

A URL for the download location at the time of orchestration.

Options for pathDescription
Repository

Different repositories supported by CloudCenter.

See Shared Artifact Repositories > CloudCenter Repository Types for a list of options.

Format: %REPO_ID_{id}%xyz.war

Example: %REPO_ID_2%xyz.war where 2 is the ID of the repository in CloudCenter

File in Package

Path of the ZIP file defined in the application package of the application profile parent tier.

Example: %PACKAGE_DIR%script.sh

Storage

Path for the mounted storage location.

Linux VM Example: /shared

URLURLs of type HTTP, HTTPS, and FTP

API Enumeration = path (text that encodes a URL)

textarea

You can add any free form text in this area – for example, use this field for to define a parameter with values as file contents, or to define a private key, or to define a script, and so forth.

API Enumeration = textarea (text of any length (long))

secretkeyEffective CloudCenter 4.9.0, this type is useful when configuring a Container Service. When you select this parameter, you can configure another layer of abstraction when specifying the Key Name (group-level coordinate) and the Key (the location) to retrieve the actual value of the secretkey for the deployment parameter that uses this type. The secret value is not visible to users nor is it maintained by the CloudCenter platform. This type is merely retrieves the secret from the specified location and uses that secret as configured.

Default Value Usage

The cliqrIgnoreAppFailure parameter does not terminate nodes during a failure and continues to keep all failed application deployment nodes running. If you configure this parameter, then you can enter true or false in the Default Value field to ensure that a VM is or is not terminated if an error is encountered at start up. See Troubleshooting Parameters for additional context.

Deployment-Specific Parameters

The CloudCenter platform includes an improvement to allow service parameters to be displayed to end users when they complete a Deployment form. Users are prompted to confirm if a parameter is a deployment parameter. Based on the Permission Control settings for this service a user can also be assigned permissions to change the parameter value at deployment time.

Granular Control for User-Defined Parameters

The User Options that the following table describes provide granular control over a user-defined parameters:

User OptionCheckedUnchecked
Should this parameter be visible to the user?This parameter is visible to users in the Topology Properties sections.This parameter is not visible to users. This allows admins to configure hidden parameters for licensing or tracking purposes (for example, to track how many users are using this service).
Should this parameter be editable by the user?Users can override this parameter in the Topology Properties settings.This service becomes automatically invisible to the user, and therefore not editable.
Should this parameter be optional?

Marked optional – The CloudCenter platform accepts the provided default values, if any (default = None), and the user must select a value to change the default.

Marked required – If a default value is not provided, then the user must select one of the values returned by the web service.

Supported Parameters


Back to: Parameters and Macros

  • No labels
Terms & Conditions Privacy Statement Cookies Trademarks