Step by step validation Spec
Change-Id: Ic2c9e95b50315371c63b374a2d6e1c2de16c6c1c
This commit is contained in:
Frederic Lepied
parent
4f6cd0d8a4
commit
45f99411f5
149
specs/ocata/step-by-step-validation.rst
Normal file
149
specs/ocata/step-by-step-validation.rst
Normal file
@ -0,0 +1,149 @@
|
|||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
=======================
|
||||||
|
Step by step validation
|
||||||
|
=======================
|
||||||
|
|
||||||
|
Include the URL of your launchpad blueprint:
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/tripleo/+spec/step-by-step-validation
|
||||||
|
|
||||||
|
Validate each step during the installation to be able to stop fast in
|
||||||
|
case of errors and provide feedback on which components are in error.
|
||||||
|
|
||||||
|
Problem Description
|
||||||
|
===================
|
||||||
|
|
||||||
|
During deployment, problems are often spotted at the end of the
|
||||||
|
configuration and can accumulate on top of each other making it
|
||||||
|
difficult to find the root cause.
|
||||||
|
|
||||||
|
Deployers and developers will benefit by having the installation
|
||||||
|
process fails fast and spotting the lowest level possible components
|
||||||
|
causing the problem.
|
||||||
|
|
||||||
|
Proposed Change
|
||||||
|
===============
|
||||||
|
|
||||||
|
Overview
|
||||||
|
--------
|
||||||
|
|
||||||
|
Leverage the steps already defined in Tripleo to run a validation tool
|
||||||
|
at the end of each step.
|
||||||
|
|
||||||
|
During each step, collect assertions about what components are
|
||||||
|
configured on each host then at the end of the step, run a validation
|
||||||
|
tool consumming the assertions to report all the failed assertions.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
We could use Puppet to add assertions in the code to validate what has
|
||||||
|
been configured. The drawback of this approach is the difficulty to
|
||||||
|
have a good reporting on what are the issues compared to a specialized
|
||||||
|
tool that can be run outside of the installer if needed.
|
||||||
|
|
||||||
|
The other drawback to this approach is that it can't be reused in
|
||||||
|
future if/when we support non-puppet configuration and it probably
|
||||||
|
also can't be used when we use puppet to generate an external config
|
||||||
|
file for containers.
|
||||||
|
|
||||||
|
Security Impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
* some validations may require access to sensitive data like passwords
|
||||||
|
or keys to access the components.
|
||||||
|
|
||||||
|
Other End User Impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
This feature will be activated automatically in the installer.
|
||||||
|
|
||||||
|
If needed, the deployer or developper will be able to launch the tool
|
||||||
|
by hand to validate a set of assertions.
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
We expect the validations to take less than one minute by step.
|
||||||
|
|
||||||
|
Other Deployer Impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
The objective is to have a fastest iterative process by failing fast.
|
||||||
|
|
||||||
|
Developer Impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Each configuration module will need to generate assertions to be
|
||||||
|
consummed by the validation tool.
|
||||||
|
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Note that this approach (multiple step application of ansible in
|
||||||
|
localhost mode via heat) for upgrades and it will work well for
|
||||||
|
validations too.
|
||||||
|
|
||||||
|
https://review.openstack.org/#/c/393448/
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee: <shardy@redhat.com>
|
||||||
|
|
||||||
|
Other contributors to help validate services:
|
||||||
|
<launchpad-id or None>
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
* generate assertions about the configured components on the server
|
||||||
|
being configured in yaml files.
|
||||||
|
|
||||||
|
* implement the validation tool leveraging the work that has already
|
||||||
|
been done in ``tripleo-validations`` that will do the following
|
||||||
|
steps:
|
||||||
|
|
||||||
|
1. collect yaml files from the servers on the undercloud.
|
||||||
|
|
||||||
|
2. run validations in parallel on each server from the undercloud.
|
||||||
|
|
||||||
|
3. report all issues and exit with 0 if no error or 1 if there is at
|
||||||
|
least one error.
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
To be added.
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
The change will be used automatically in the CI so it will always be tested.
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
We'll need to document integration with whatever validation tool is
|
||||||
|
used, e.g so that those integrating new services (or in future
|
||||||
|
out-of-tree additional services) can know how to integrate with the
|
||||||
|
validation.
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
A similar approach was used in SpinalStack using serverspec. See
|
||||||
|
https://github.com/redhat-cip/config-tools/blob/master/verify-servers.sh
|
||||||
|
|
||||||
|
A collection of Ansible playbooks to detect and report potential
|
||||||
|
issues during TripleO deployments:
|
||||||
|
https://github.com/openstack/tripleo-validations
|
||||||
|
|
||||||
|
Prototype of composable upgrades with Heat+Ansible:
|
||||||
|
https://review.openstack.org/#/c/393448/
|
||||||
Loading…
Reference in New Issue
Block a user