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.
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:
No significant security 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.
Same as End User Impact
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
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