Deployment Parameters

Overview

Workload Manager includes an improvement to allow service parameters to be displayed to end users during deployments. Users can define parameters as deployment parameters and set preferences for them. These preferences govern if the parameters should be visible, editable, and optional during a deployment.

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 for a Deployment Parameter:

    • Is 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.

Adding Deployment Parameters

Deployment Parameters are intended to be customized by the user at deployment time and can be created at the service level and used as inherited parameters within an application or directly created when modeling an application.

  • Service-Level Parameters: The parameter is specific to service. If you define a deployment parameter at the service level, then it is displayed as an inherited parameter in the tier where the service is used while modeling an application. You can customize the visibility preferences for this parameter and override the default value when modeling an application.

    The following screenshot shows a service-level parameter.

  • Tier-Level Parameters: The parameter is specific to each step or tier within an application. You can define a deployment parameter at the tier level when modeling an application. You can control the visibility preferences for this parameter during the application modeling process and configure them to be visible, editable, or options during the deployment process.

    The following screenshot shows tier-level parameters.

Using Deployment Parameters

See Using Parameters for additional details.

Inherited Deployment Parameters

If a parameter is defined at the service level, then this parameter displays (inherited) when viewed at the tier level.

The following screenshot shows inherited deployment parameters.

These parameters are made available to users that use this service when deploying applications.

When users model applications, these parameters are visible to those using this service. If used at application modeling time, you can only edit the default values for a deployment parameter.

Granular Control for User-Defined Parameters

This section explains the options that allow granular control for deployment parameters. The following image highlights the Use Defaults switch.

This switch is present in the parameters editor dialog box to the right of the value of each parameter which is visible and not locked.

  • On: Default. Workload Manager uses the default value specified in the parameter definition.

  • Off: If the field is not locked and you type a value for the parameter, the toggle is automatically turned off.

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

User OptionCheckedUnchecked
Should this parameter be visible to the user?

This parameter will be visible to users during the application deployment.

Users can override the visibility setting during the application modeling process.

This parameter is not visible to users during the application deployment.
Should this parameter be editable by the user?

This parameter will be editable by users during the application deployment.

Users can override the edit setting during the application modeling process.

This service becomes automatically is disabled for users, and therefore not editable during the application deployment.
Should this parameter be optional?

Marked optional – This parameter will be optional for users during the application deployment.

Users can override the optional setting during the application modeling process.

Marked required – This parameter is requires and the user must provide or select a value during the application deployment.

Allow selection of multiple values (only displayed if a "list" parameter is selected)Users can select multiple values for this parameter during the application deployment.Users can select one value for this parameter during the application deployment.

Deployment Parameters Icons

Note that the header for each parameter section has the following icons on the right side:

  • + adds a new resource – at the required point

  • - deletes an existing  parameter

  • ↑ moves the priority of the resource further up the list.

  • ↓ moves the priority of the resource further down the list.

Deleting Deployment Parameters

If a deployment parameter is deleted at the service level, all usage for this parameter is impacted – this deployment parameter will not be available when:

  • You edit an application containing that service.

  • Users deploy an application containing that service.

Editing Deployment Parameters

If the default value for a deployment parameter is changed at the service level, then this change reflects in the usage for this parameter at the application level IF the default value was not overridden during the application modeling process.

Defining Parameters

You can define deployment parameters in new and existing services:

  • If an app is not modified, these parameters show on the deployment flow based on the visibility.

  • At the app level, deployment parameters are shown from the service.

  • You cannot remove deployment parameters at the app level.

  • You can edit the default values or visibility setting; app-level values take precedence

  • If you edit the default values, the values are stored only in the app.

  • If you remove an updated parameter from service, it is not shown in the app or job.

  • If you change parameter values to the same values of service, it is not saved at the app level and it is picked up at the service level.

You can define deployment parameters on the Service page. To do so, click Edit for the service and scroll down to the Deployment Parameters area. By default, parameters are collapsed. You can click any parameter to expand it and view the parameter's configuration.

When you model an app and drag a service in the Topology Modeler page, the Properties display shows how many deployment parameters exist. Click the Deployment Parameters field to see the name of each parameter. You can expand each parameter further and may some times see that a parameter has been assigned an inherited designation.

Inherited Parameters

The inherited designation next to a parameter means that the parameter is derived from the Services page and is not defined within an application/deployment.

Here are some general guidelines when working with inherited parameters:

  • You cannot define a new parameter that has the same name as an inherited parameter.

  • You cannot delete them in the Service page (the Minus icon button is disabled).

  • You cannot update the Parameter Name, Display Name, Help Text, or Type fields (these fields are disabled).

  • You can update the Default Value and User Options.

Where Do You See Defined Parameters?

On the Deploy page, in the Tier Settings area, you can see each deployment parameter that is defined. If a value is defined as editable for the parameter, you can edit it here, while deploying the app.

On the Deployment Details page, you can see the parameters for a deployment under Parameters (applies to global, custom, and deployment parameters).

  • No labels
Terms & Conditions Privacy Statement Cookies Trademarks