74528a518d
This PS integrates document replacement with document layering. The case
works something like this:
GIVEN:
- Parent A
- Child B
- Child C
WHEN:
- Child B is a replacement for A
THEN:
- B must layer with A, then C must layer with B, rather than A,
as B replaces A.
This is the most basic scenario and there are certainly far more
intricate ones, involving interplay with substitution as well.
To implement this new functionality, relatively minor coding changes
were made, mostly in whether to consider a document's parent or its
parent's replacement while layering, as well as determining the
dependency chain for document sorting.
Unit tests surrounding replacement have been moved into their own files
and a scenario has been added for the case described above. In addition
the same case is tested via a functional test scenario.
The unit tests have been "hardened" to run the layering scenarios twice:
once by passing in the documents in their original order, an order which
is usually written for human maintainability (i.e. B depends on A, so
make the order A followed by B). However, in reality the order of the
documents will be randomized, so every layering unit test is also
run a second time with the documents in reverse order to better ensure
that the dependency chain is resolved correctly.
Change-Id: Ieb058267f3a46b78e899922b6bc5fd726ed15a1b
|
||
|---|---|---|
| charts/deckhand | ||
| deckhand | ||
| docs | ||
| etc/deckhand | ||
| images/deckhand | ||
| releasenotes | ||
| tools | ||
| .coveragerc | ||
| .dockerignore | ||
| .gitignore | ||
| .gitreview | ||
| .stestr.conf | ||
| HACKING.rst | ||
| LICENSE | ||
| Makefile | ||
| README.rst | ||
| entrypoint.sh | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.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.
Find more documentation for Deckhand on Read the Docs.
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
For more detailed installation and setup information, please refer to the Getting Started guide.
Testing
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 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: