Add example for role specific parameters

How to define and use a role specific parameter with a different
variable name. A service can have a more specific name whereas the
role variable has a more generic name.

Working example based on: https://review.opendev.org/#/c/738925/

Change-Id: I1eb291d36483f138a523b3dc9a3b8a9a1baf581a
Signed-off-by: Luke Short <ekultails@gmail.com>
This commit is contained in:
Luke Short 2020-07-21 16:33:01 -04:00
parent 0f112d37dc
commit 79822361ae

View File

@ -55,10 +55,54 @@ which will be done by the service implementation::
NeutronDpdkMemoryChannels: {get_param: NeutronDpdkMemoryChannels} NeutronDpdkMemoryChannels: {get_param: NeutronDpdkMemoryChannels}
NeutronDpdkSocketMemory: {get_param: NeutronDpdkSocketMemory} NeutronDpdkSocketMemory: {get_param: NeutronDpdkSocketMemory}
A service can have a unique variable name that is different than the role specific one.
The example below shows how to define the service variable ``KeystoneWSGITimeout``, override
it with the role specific variable ``WSGITimeout`` if it is found, and create a new alias variable
named ``wsgi_timeout`` to store the value. Later on, that value can be retrieved by using
``{get_attr: [RoleParametersValue, value, wsgi_timeout]}``.::
parameters:
KeystoneWSGITimeout:
description: The timeout for the Apache virtual host created for the API endpoint.
type: string
default: '60'
tags:
- role_specific
resources:
RoleParametersValue:
type: OS::Heat::Value
properties:
type: json
value:
map_replace:
- map_replace:
- wsgi_timeout: WSGITimeout
- values: {get_param: [RoleParameters]}
- values:
WSGITimeout: {get_param: KeystoneWSGITimeout}
outputs:
role_data:
description: Role data for the Keystone API role.
value:
config_settings:
map_merge:
- keystone::wsgi::apache::vhost_custom_fragment:
list_join: [' ', ['Timeout', {get_attr: [RoleParametersValue, value, wsgi_timeout]}]]
Now the variable can optionally have a default set at the composable roles data level.::
- name: Undercloud
RoleParametersDefault:
WSGITimeout: '600'
.. note:: .. note::
As of now, not all parameters can be set per role, it is based on the As of now, not all parameters can be set per role, it is based on the
service or template implementation. Each service should have the service or template implementation. Each service should have the
implementation to merge the global parameters and role-specific implementation to merge the global parameters and role-specific
parameters, as explained in the above example. A warning will be shown parameters, as explained in the above examples. A warning will be shown
during the deployment, if an invalid parameter (which does not support during the deployment, if an invalid parameter (which does not support
role-specific implementation) is provided as role-specific input. role-specific implementation) is provided as role-specific input.