Add Support for Custom TripleO Validations¶
All validations are currently stored in a single directory. This makes it inconvenient to try and write new validations, update from a remote repository or to add an entirely new (perhaps private) source.
The deployer wants to develop and test their own validations in a personal checkout without risking changes to the default ones.
The deployer wants to use a stable release of TripleO but consume the latest validations because they are non-disruptive and check for more stuff.
A third party has developed validations specific to their product that they don’t want to or can’t include in the tripleo-validations repository.
We will store a default set of TripleO validations in a Swift container called
tripleo-validations. These will be shared across all plans and are not
expected to be updated by the deployer. This container should be created on
initial undercloud deployment.
We will provide a mechanism for deployers to add a custom set of validations
per deployment plan. These plan-specific validations will be stored in a
custom-validations subdirectory in the plan’s Swift container. Storing them
together with the plan makes sense as these validations can be specific to
particular deployment plan configuration, as well as makes the import/export
Since custom validation will be stored as part of the plan, no additional workflows/actions to perform CRUD operations for them will be necessary; we can simply use the existing plan create/update for this purpose.
The validation Mistral actions (e.g.
will need to be updated to take into account this new structure of
validations. They will need to look for validations in the
tripleo-validations Swift container (for default validations) and the
custom-validations subdirectory (for custom validations), instead of
sourcing them from a directory on disk, as they are doing now.
If a validation with the same name is found both in default in custom validations, we will always pick the one stored in custom validations.
As a further iteration, we can implement validations as per-service tasks in standalone service Ansible roles. They can then be consumed by tripleo-heat-templates service templates.
Do nothing. The deployers can already bring in additional validations, it’s just less convenient and potentially error-prone.
We could provide a know directory structure conceptually similar to
run-partswhere the deployers could add their own validation directories.
Other End User Impact¶
In order to add their own validations, the deployer will need to
update the deployment plan by adding a
custom-validations directory to it,
and making sure this directory contains the desired custom validations. The
plan update operation is already supported in the CLI and the UI.
Since the validation sources will now be Swift containers, downloading validations will potentially be necessary on each run. We will have to keep an eye on this an potentially introduce caching if this turns out to be a problem.
Other Deployer Impact¶
Testing and developing new validations in both development and production environments will be easier with this change.
- Primary assignees:
- Other contributors:
Move to using Swift as default storage for tripleo-validations (1).
find_validationfunctions to read validations from all the sources specified in this document.
In order to be able to implement this new functionality, we first need to have the validations use Swift as the default storage. In other words, this spec depends on the blueprint 1.
The changes will be unit-tested in all the tripleo repos that related changes land in (tripleo-common, instack-undercloud, tripleo-heat-templates, etc).
We could also add a new CI scenario that would have a custom-validations directory within a plan set up.
We will need to document the format of the new custom-validations plan subdirectory and the new behaviour this will introduce.