Using parameters in PaaS provisioning

When setting up service blueprints for platform-as-a-service (PaaS) provisioning with BMC Database Automation or any third-part provider, you can use parameters in various parts of the process. Parameters let users override values defined in the provider template and the service blueprint configuration.

Parameters differ from options, which let end users select from a predefined set of choices when requesting a service.

This topic includes the following subtopics:

Parameters for PaaS applications

PaaS applications can run software packages in the form of scripts. The script must be defined in BMC Database Automation as an Action, and the Action must be published to the product catalog. (Currently, the process of publishing the Action is different than the process for publishing a BMC Database Automation template.)

If you define a SQL script as an Action and the script contains a parameter, the name of the parameter must be enclosed in curly brackets, and the name must begin with GAC_. For example, if you want the value of a parameter named "token" to be passed into SQL Action, the parameter in the SQL Action must be named {GAC_token}.

If you define some other type of script as an Action (for example, a Perl script or a software installation script) and you want to include parameters in the script, insert parameters according to the syntax of the script you are executing.

For detailed information about how Actions are constructed in BMC Database Automation, see Creating-an-Action and Actions-environment-variables.

Parameters for BMC Database Automation resources

For on-premise PaaS, PaaS resources are based on templates defined in BMC Database Automation. There are two categories of parameters that can be inserted into templates:

User-defined—Parameters that must be set up in a BMC Database Automation template before the template is published to the product catalog. End users can provide input for user-defined parameters to override characteristics of the template. For more information on setting up variables (that is, parameters), see Managing-templates-for-Oracle-on-Linux-and-UNIX in the documentation for BMC Database Automation.
Note
Parameters placed in the non-editable or hidden sections of BMC Database Automation templates cannot be overridden. Do not place parameters in those sections if you want BMC Cloud Lifecycle Management to use those parameters.

Predefined—Parameters that can always be inserted into the resource set definition to override values specified in a service blueprint. The following predefined parameters are always available:

Parameter name	Purpose
BmcDbName	(Required) Defines the first eight characters of the name of the database being provisioned. This parameter is particularly important because you cannot deploy two databases with the same name to the same environment. The only way to specify the name when you are deploying more than one database is through the use of parameters.
BmcDbEdition	Identifies the database edition being provisioned.
BmcDbInstanceMemory	Specifies the amount of memory made available for a database instance.
BmcDbMasterUserName	(Required) Defines the master user for the database being provisioned.
BmcDbMasterUserPassword	(Required) Sets the password for the master user.
BmcDbVersion	Specifies the database version you are deploying, such as 10.2.0.2.

The name you assign to a parameter in the resource definition must exactly match the name in the list above or it must exactly match the name of the corresponding field as defined in BMC Database Automation template.

Parameters for Docker resources

The following table lists the parameters that you can specify for a Docker resource:

Parameter name	Purpose
Command to Run	Specifies the command to run on the specified string or an array of strings Note that BMC Cloud Lifecycle Management accepts the syntax that is applicable to the Docker native REST API. However, BMC Cloud Lifecycle Management requires comma as the space delimiter. For example, if you want to run /bin/sh startup.sh at Container startup, specify /bin/sh,startup.sh for this parameter.
CPU Shares	Specifies the CPU Shares for the container; specifies the relative weight v/s other containers
Docker Image Tag	(Required) Specifies the version tag of the Docker image For example, for dockeruser1/busybox:1.23.2 specify the Docker Image Tag as 1.23.2.
Docker Registry	Specifies the Docker registry For example: For private images on Docker hub, specify registry.hub.docker.com. For private registry, specify the fully qualified host name:port. For public Docker images, leave this parameter empty.
Docker Repository Namespace	(Required) Specifies the repository namespace of the Docker image For example, for dockeruser1/busybox:1.23.2 specify the Docker Repository Namespace as dockeruser1.
Docker Repository Password	(Required) Specifies the password to log on to the repository
Docker Repository User Name	Specifies the user name to log on to the repository
Domain Name	Specifies the string containing the domain name to use for the container
Environment Variables	Specifies a list of environment variables For only one environmental variable, use the format VAR=value. For multiple environmental variables, use the format: -e VAR=value -e VAR1=value1.
Exposed Ports	Specifies the list of local ports to be exposed outside the container in the format: port1;port2
Hostname	Specifies the string containing the host name to use for the container
Installable Resource	(Required) Specifies the string containing the Image Repository name For example, for dockeruser1/busybox:1.23.2 specify the Installable Resource as busybox.
Links	Specifies the list of links for the container. Each link entry should be in the format: NameOfResourceSet1:alias1;NameOfResourceSet2:alias2
Memory in MB	Specifies the memory limit in MB
Port Bindings	Specifies the map of exposed container ports and the host port they should map to in the format: port1:hostPort1; port2:hostport2
Publish All Ports	Indicates whether to allocate a random host port for all of a container's exposed ports. Valid value: true, false
Volumes	Specifies the object mapping mount point paths (strings) inside the container to empty objects in the format: /alias0;/alias1:/value1;/alias2:/value2

Usage of Installable Resource-related parameters

Cloud administrators have the flexibility to lock down or open up which part of the image repository they want to expose to end users.

The following table is an example scenario that shows how you can expose some of the parameters based on your environment:

Environment	Possible actions that end users can perform	Is "User Entry Enabled" option selected?
Environment	Possible actions that end users can perform	Docker Registry	Docker Repository Namespace	Docker Repository User Name	Docker Repository Password	Installable Resource	Docker Image Tag
Development	Select a particular registry or Docker hub account and then select a repository within the Docker hub	Yes	Yes	Yes	Yes	Yes	Yes
Staging	Select an image for any repository of a specific account only	No	No	No	No	Yes	Yes
Pre- Production	Select any version of any image for a particular repository or a particular account only	No	No	No	No	No	Yes
Production	Cannot select an image because it is burnt into the blueprint	No	No	No	No	No	No