Service Validation

Registered by Shawn Hartsock on 2014-02-04

This feature request allows a service to register validators to be executed on the service's configuration before the service launches. It will allow any tier inside the service from driver to conductor to register an object implementing the validator API which the service may then use to run validation tests.

* any layer of a service may register a validator
* validators always run before the service can launch

Example uses
* VMware drivers may open vSphere connections and test Cluster configurations and datastore availablility
* General connectivity validations can happen before launch of the service
* availability of host and port numbers (for a service to bind to) can be verified before service launch
* verify rabbit, database, or other service is available before launch (establishing service launch ordering)

Use of the validator is optional. The service validator allows for fail early and loud operation.

NOTE: This is different from static configuration validation because it allows a service author to provide a class for validating a configuration at runtime for use by their driver, package, or service before the service starts. This is a runtime check that can be used to validate networking, system configurations, or other information that will not necessarily be available to the static configuration validator.

Etherpad for discussion
https://etherpad.openstack.org/p/service-validation

Blueprint information

Status:
Started
Approver:
Doug Hellmann
Priority:
Low
Drafter:
Shawn Hartsock
Direction:
Needs approval
Assignee:
Shawn Hartsock
Definition:
Pending Approval
Series goal:
None
Implementation:
Slow progress
Milestone target:
None
Started by
Shawn Hartsock on 2014-02-04

Related branches

Sprints

Whiteboard

See:
    https://review.openstack.org/#/q/status:open+project:openstack/oslo.config+branch:master+topic:bp/service-validation,n,z

addressed by:
     https://review.openstack.org/#/c/71100/

Notes on design:

A registry will hold references to validator objects. The validator interface may be over-loaded for custom validators or a method may be supplied.

Validators will register for a set of required options in cfg. If the trigger options are present, the validator is fired. If the trigger options are not present the validator is disabled. This allows a driver writer to register a validator to just their driver, or a service author to register a validator to just their service configuration parameters.

A validator can be registered from any point within the code-base mirroring the way configurations are dealt with.

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.