Spec for verification of configuration files

This specification introduces a datasource driver and agents to collect
configuration files handled by the oslo-config library on the different
nodes and make them available to the congress datalog engine as a
datasource.

Change-Id: I5683a839e8fb85d7d44fd01e8800481fd2bd3fbb
Implements: blueprint configuration-files-validation
Co-Authored-By: Valentin Matton <vmatt.openstack@gmail.com>
Co-Authored-By: Pierre Crégut <pierre.cregut@orange.com>
This commit is contained in:
Valentin Matton 2017-10-16 10:41:33 +02:00 committed by Pierre Crégut
parent 07286b8cfb
commit d993127245
2 changed files with 366 additions and 0 deletions

View File

@ -4,6 +4,14 @@
Congress Project Specifications
===============================
Queens approved specs:
.. toctree::
:glob:
:maxdepth: 1
specs/queens/*
Pike approved specs:
.. toctree::

View File

@ -0,0 +1,358 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
==========================================
OpenStack Configuration Files Validation
==========================================
https://blueprints.launchpad.net/congress/+spec/configuration-files-validation
Congress could be used by cloud operators to formalize the constraints between
options defined in configuration files with the help of business rules written
in Datalog and verify the compliance of their deployments automatically.
It is intended to be complementary to config management systems that should only
create valid configuration files and to integration tests such as RefStack.
Problem description
===================
Each OpenStack service on each node in parameterized by a set of configuration
files describing the value of the various configuration options. In this
proposal we only consider configuration files managed by the oslo-config
library. Configuration options are not independent:
* Each option value is constrained but the constraints may go beyond the
expressive power of oslo-config type system.
* For a given service on a given node, constraints may exist between different
options.
* On a given node, constraints and incompatibilities may exist between various
options belonging to different services. For example, when a functionality in
a given service depends on the availability of another functionality in
another service.
* Between nodes, other constraints exist either for a given service or between
services.
Constraints may be defined by different actors:
* Service developers know the constraints on the options they define and usually
document them informally in the source code in the description field associated
to the option.
* Cloud integrators will discover additional constraints when they develop
deployment code. Most of the time those options are only implicitly defined in
the source code of the scripts.
* Administrators may want to enforce additional constraints reflecting the
operational environment constraints.
* For companies having multiple instances of OpenStack, rules could be
used to ensure compliance of the instances with their global engineering
rules.
* Although OpenStack provides abstractions that hide implementation details
from end-users, some back-ends or some back-end combinations may impose
constraints on what is available to the end-user. When administrators
discover some back-end limitations, it may be useful to add congress rules
reflecting those limitations before a more permanent solution is found.
Datalog could be used as a formal language to describe those constraints and
Congress could be used to enforce those constraints if the configuration files
were available for processing. Although Congress is usually used for more
dynamic data coming from running instances, nothing precludes the use of more
static data sources.
Proposed change
===============
The extension adds a new agent deployed on OpenStack nodes that collect the
configuration files as defined in its own configuration. The agent communicates
with a datasource driver included in the congress analyzer through the
message bus. The agent is configured with its own configuration file describing
the files it transmit (an example configuration file is given in the 'Other
deployer impact' section).
The agent is responsible for conveying information on option values but also on
their meta-data: layout in groups, type, flags such as deprecation, secret
status, etc. Meta-data are described in templates which are in fact a collection
of namespaces. Namespace contain the actual definition of meta-data. To avoid
versionning problems, Meta-data must be obtained directly from the service.
To limit the amount of traffic between the driver and agents, template files are
hashed. Agents first reply to queries with hashes. The driver will request the
content only if the hash is unknown. The same process is used for namespaces.
The only processing performed by agents on the option files is the removal of
the values of secret options.
The datasource driver is responsible for populating the extensional database
with information provided by the agents:
* option definitions are extracted from templates and namespaces and translated
in new Datalog tables.
* option values are parsed by the oslo-config library and stored with an
identification of the origin (file and node).
The Datalog model defines several tables:
* hosts
* files
* templates
* namespaces
* option values
The definition of an option is split between three tables:
* The option table defines the mapping between the option id and the fields
that build up the key: name, namespace and group of the option.
* The option_info table defines the type and the flags of the option. It uses
the id defined in the option table to uniquely identify the option.
* Depending on the type of the option, attributes specific to a given type are
defined in a specialized table. The option id is used again as a key to refer
to the option table.
Regarding the uniqueness of configuration meta-data in the extensional database,
the driver must ensure that the ids are deterministic. An option identified
by the same name, same group name and same namespace name should always be
given the same unique id. The use of the MD5 hash function (there is no
cryptographic requirement) guarantees uniqueness and determinism.
Alternatives
------------
Installers usually generate correct set of configuration files for a
more or less extensible set of options but provide little help for live
maintenance of those files. They may also restrict the configuration
space beyond what is necessary.
The proposed change must be considered as a work in progress. It does not fully
address the problem of the location and the management of constraints. Most
constraints are known by the service developers and should be maintained in the
source code of services in a dedicated meta-data field of the option definition.
The use of an external agent to push a service configuration is not the only
solution. The oslo-config library could be modified to push the configuration
read by the service to the datasource driver. This could be done through the use
of a hook in oslo-config. It would require additional configuration of the
services to identify the endpoint.
Policy
------
We would like to aggregate policy violations in a few tables partitioning
violations by their degree (error, warn, info).
Example:
X: neutron-server host
Y: ovs-agt host
Z: lb-agt host
::
warn('Multinode OVS and linuxbridge use incompatible UDP ports', 'vxlan_conflicting_ovs_lb_udp_ports') :-
vxlan_conflicting_ovs_lb_udp_ports()
vxlan_conflicting_ovs_lb_udp_ports(Y, Z) :-
value(X, 'neutron.conf', 'DEFAULT', 'core_plugin', 'ml2'),
value(X, 'ml2_conf.ini', 'ml2', 'type_drivers', 'vxlan'),
value(X, 'ml2_conf.ini', 'ml2', 'mechanism_drivers', 'openvswitch'),
value(X, 'ml2_conf.ini', 'ml2', 'mechanism_drivers', 'linuxbridge'),
value(Y, 'openvswitch_agent.ini', 'agent', 'tunnel_types', 'vxlan'),
not value(Y, 'openvswitch_agent.ini', 'agent', 'vxlan_udp_port', 8472),
value(Z, 'linuxbridge_agent.ini', 'vxlan', 'enable_vxlan', 'True')
We'd like the 'value' table to be intelligible to most potential contributor,
and also meaningful enough to spare them from predictable joins.
Currently the 'value' table is derived from the extensional tables, which
describe configuration files and their meta-data. Although it is defined
intentionally, it could be useful to consider it as an extensional predicate.
Here is how we derived it:
::
value(hostname, file, group, name, value) :-
config:option(id=option_id, group=group, name=name),
config:file(id=file_id, host_id=host_id, name=file),
config:host(id=host_id, name=hostname),
config:value(option_id=option_id, file_id=file_id, val=value)
Policy actions
--------------
None.
Data sources
------------
The data sources are the different configuration files of OpenStack projects
using the Oslo.config library for their configuration.
Data model impact
-----------------
None
REST API impact
---------------
None
Security impact
---------------
Configuration files contain sensitive credentials. Those credentials MUST NOT
be transmitted to the Congress engine. The agent has access to types and must
filter out credentials. Values of any option marked as secret will not be
available within the engine.
Notifications impact
--------------------
None
Other end user impact
---------------------
None other than the usual management of the datasource and policy.
Eventually, we would like to feed the engine with rules that are coming from and
maintained in the services source code.
Performance impact
------------------
Performance impact should be limited because of the static nature of the values
provided by this datasource.
The main impact is the traffic on the message bus used to exchange
configuration files between agents and Congress server. The server may
rate-limit this traffic. If performance is still a concern, another solution is
to limit the use of the bus to announcement and use a REST endpoint on the
server to record new configuration files.
We give the driver control over the way data is retrieved. We want to prevent
the duplicated sending of files and templates, and to prevent overloading the
driver. When the driver is activated, it periodically notifies agents, over the
communication bus requesting their data description. An agent send description
of the files it has been set to provide. The description contains hashes of
namespaces, templates and configs. The driver then requests the resources, which
hashes have not been recognized.
We use the RPC server of the datasource associated DseNode.
Other deployer impact
---------------------
We add a dedicated group and options to configure an agent and the configuration
files to manage.
*validator.host*
A string option serving as a node id, in a way that is meaningful to
administrators.
*validator.version*
A string option introducing the notion of version and what it would be on this
node. It could be used to discriminate handling of different version of a
config-file coexisting in a cloud instance during a migration.
This information may be provided differently in the future to be defined
at the services level.
*validator.services*
An dict option describing the OpenStack services activated on this node. The
values are also dictionaries. Keys are paths to config-files,
values are paths to the associated templates. For instance::
congress: { /etc/congress/congress.conf:/opt/stack/congress/etc/congress-config-generator.conf }
Example config :
::
[DEFAULT]
transport_url = rabbit://..@control:5672/
[validator]
services = nova : { /etc/nova.conf:/opt/stack/nova/etc/nova/nova-config-generator.conf:
version = ocata
host = node_A
Developer impact
----------------
Discuss things that will affect other developers working on OpenStack,
such as:
* If the blueprint proposes a change to the driver API, discussion of how
other hypervisors would implement the feature is required.
Implementation
==============
Assignee(s)
-----------
Primary assignees:
* Valentin Matton
* Pierre Crégut
Work items
----------
* Agent to collect the config files
* Datasource interacting with the agents
* Integration to devstack
Dependencies
============
We will depend on oslo-config-generator config-files, which can be used to
describe OS services config-files.
https://github.com/openstack/oslo-specs/blob/master/specs/juno/oslo-config-generator.rst
We rely extensively on the oslo-config lib.
Testing
=======
We propose to use tempest tests in a setting with 2 nodes. One of which hosts
the congress-server and the second an agent. Communications will be tested :
sending of meta-data and files.
Documentation impact
====================
This feature introduces an agent component that requires separate configuration.
It also defines new datasources.
References
==========