GUI Deployment configuration improvements¶
TripleO UI deployment configuration is based on enabling environments provided by deployment plan (tripleo-heat-templates) and letting user set parameter values.
This spec proposes improvements to this approach.
The general goal of TripleO UI is to guide user through the deployment process and provide relevant information along the way, so user does not have to search for a context in documentation or by analyzing TripleO templates.
There is a set of problems identified with a current deployment configuration solution. Resolving those problems should lead to improved user experience when making deployment design decisions.
The important information about the usage of environment and relevant parameters is usually included as a comment in environment file itself. This is not consumable by GUI. We currently use capabilities-map.yaml to define environment meta data to work around this.
As the number of environments is growing it is hard to keep capabilities-map.yaml up to date. When certain environment is added, capabilities-map.yaml is usually not updated by the same developer, which leads to inaccuracy in environment description when added later.
The environments depend on each other and potentially collide when used together
There are no means to list and let user set parameters relevant to certain environment. These are currently listed as comments in environments - not consumable by GUI (example: )
There are not enough means to organize parameters coming as a result of heat validate
Not all parameters defined in tripleo-heat-templates have correct type set and don’t include all relevant information that Hot Spec provides. (constraints…)
Same parameters are defined in multiple templates in tripleo-heat-templates but their definition differs
List of parameters which are supposed to get auto-generated when value is not provided by user are hard-coded in deployment workflow
Propose environment metadata to track additional information about environment directly as part of the file in Heat (partially in progress ). Similar concept is already present in heat resources . In the meantime update tripleo-common environment listing feature to read environments and include environment metadata.
Each TripleO environment file should define:
metadata: label: <human readable environment name> description: <description of the environment purpose> resource_registry: ... parameter_defaults: ...
With the environment metadata in place, capabilities-map.yaml purpose would simplify to defining grouping and dependencies among environments.
Implement environment parameter listing in TripleO UI
To organize parameters we should use ParameterGroups. (related discussion: )
Make sure that same parameters are defined the same way across tripleo-heat-templates There may be exceptions but in those cases it must be sure that two templates which define same parameter differently won’t be used at the same time.
Update parameter definitions in TripleO templates, so the type actually matches expected parameter value (e.g. ‘string’ vs ‘boolean’) This will result in correct input type being used in GUI
Define a custom constraint for parameters which are supposed to be auto-generated.
Potential alternatives to listing environment related parameters are:
Use Parameter Groups to match template parameters to an environment. This solution ties the template with an environment and clutters the template.
As the introduction of environment metadata depends on having this feature accepted and implemented in Heat, alternative solution is to keep title and description in capabilities map as we do now
No significant security impact
Other End User Impact¶
Resolving mentioned problems greatly improves the TripleO UI workflow and makes deployment configuration much more streamlined.
Described approach allows to introduce caching of Heat validation which is currently the most expensive operation. Cache gets invalid only in case when a deployment plan is updated or switched.
Other Deployer Impact¶
Same as End User Impact
- Primary assignee:
- Other contributors:
tripleo-heat-templates: update environments to include metadata (label, description), update parameter_defaults to include all parameters relevant to the environment
tripleo-heat-templates: update capabilities-map.yaml to map environment grouping and dependencies
tripleo-heat-templates: create parameter groups for deprecated and internal parameters
tripleo-heat-templates: make sure that same parameters have the same definition
tripleo-heat-templates: make sure type is properly set for all parameters
tripleo-heat-templates: create custom constraint for autogenerated parameters
tripleo-common: update environments listing to combine capabilities map with environment metadata
tripleo-ui: Environment parameters listing
tripleo-common: autogenerate values for parameters with custom constraint
tripleo-ui: update environment configuration to reflect API changes, provide means to display and configure environment parameters
tripleo-ui: add client-side parameter validations based on parameter type and constraints
tripleo-ui: don’t show parameters included in deprecated and internal groups
Heat Environment metadata discussion 
Heat Parameter Groups discussion 
The changes should be covered by unit tests in tripleo-common and GUI
Part of this effort should be proper documentation of how TripleO environments as well as capabilities-map.yaml should be defined