453927facf
This PS rewrites the document_validation module in
Deckhand to achieve the following goals:
* better validation resiliency
* add support for different document schema versions
* better support for DataSchema validation
* separation of concerns by splitting up validations
into separate classes
* support for validating documents that rely on
a DataSchema passed in via the same payload
* support for generating multiple validation errors
rather than returning after the first one found
* increase testing validations for unit/functional
tests
Better validation resiliency is achieved through more
robust exception handling. For example, it is possible
for a ``DataSchema`` to be 100% valid from the POV of
built-in schema validation, but if the "data" section
itself is utterly invalid, then an exception will be
raised -- such an exception is treated as a critical
failure.
Better generation of error messages is achieved by
creation more validation error message results.
DataSchema validation was previously wonky. A DataSchema
had to first be created in 1 revision before it could be
referenced by a batch of documents in sequential revisions.
Now, a DataSchema can be created in the same (or previous)
revision as documents that rely on it and used to validate
said documents.
Finally, the module was heavily rewritten so that more
nuanced validations can be built by inheriting from
``BaseValidator`` so as to allow for easier code
readability and maintainability.
Change-Id: Ie75742b984b7ad392cb41decc203d42842050c80
|
||
|---|---|---|
| charts/deckhand | ||
| deckhand | ||
| doc | ||
| etc/deckhand | ||
| releasenotes | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .testr.conf | ||
| AUTHORS | ||
| Dockerfile | ||
| HACKING.rst | ||
| LICENSE | ||
| Makefile | ||
| README.rst | ||
| entrypoint.sh | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
| uwsgi.ini | ||
README.rst
Deckhand
Deckhand is a storage service for YAML-based configuration documents, which are managed through version control and automatically validated. Deckhand provides users with a variety of different document types that describe complex configurations using the features listed below.
Core Responsibilities
- layering - helps reduce duplication in configuration while maintaining auditability across many sites
- substitution - provides separation between secret data and other configuration data, while allowing a simple interface for clients
- revision history - improves auditability and enables services to provide functional validation of a well-defined collection of documents that are meant to operate together
- validation - allows services to implement and register different kinds of validations and report errors
Getting Started
To generate a configuration file automatically:
$ tox -e genconfigResulting deckhand.conf.sample file is output to :path:etc/deckhand/deckhand.conf.sample
Copy the config file to a directory discoverably by
oslo.conf:
$ cp etc/deckhand/deckhand.conf.sample ~/deckhand.confTo setup an in-memory database for testing:
[database]
#
# From oslo.db
#
# The SQLAlchemy connection string to use to connect to the database.
# (string value)
connection = sqlite:///:memory:To run locally in a development environment:
$ sudo pip install uwsgi
$ virtualenv -p python3 /var/tmp/deckhand
$ . /var/tmp/deckhand/bin/activate
$ sudo pip install .
$ sudo python setup.py install
$ uwsgi --ini uwsgi.iniTesting
Automated Testing
To run unit tests using sqlite, execute:
$ tox -epy27
$ tox -epy35against a py27- or py35-backed environment, respectively. To run individual unit tests, run:
$ tox -e py27 -- deckhand.tests.unit.db.test_revisionsfor example.
To run unit tests using postgresql, postgresql must be installed in your environment. Then execute:
$ tox -epy27-postgresql
$ tox -epy35-postgresqlTo run functional tests:
$ tox -e functionalYou can also run a subset of tests via a regex:
$ tox -e functional -- gabbi.suitemaker.test_gabbi_document-crud-success-multi-bucketIntgration Points
Deckhand has the following integration points:
- Keystone (OpenStack Identity service) provides authentication and support for role based authorization.
- PostgreSQL is used to persist information to correlate workflows with users and history of workflow commands.
Note
Currently, other database backends are not supported.
Though, being a low-level service, has many other UCP services that integrate with it, including: