1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
.. -*- mode: rst -*-
.. _architecture-design:
Design Considerations
=====================
This section will discuss several aspects of the design of Bcfg2, and the
particular use cases that motivated them. Initially, this will consist
of a discussion of the system metadata, and the intended usage model
for package indices as well.
System Metadata
---------------
Bcfg2 system metadata describes the underlying patterns in system
configurations. It describes commonalities and differences between these
specifications in a rigorous way. The groups used by Bcfg2's metadata are
responsible for differentiating clients from one another, and building
collections of allocatable configuration.
The Bcfg2 metadata system has been designed with several high-level
goals in mind. Flexibility and precision are paramount concerns; no
configuration should be undescribable using the constructs present in
the Bcfg2 repository. We have found (generally the hard way) that any
assumptions about the inherent simplicity of configuration patterns tend
to be wrong, so obscenely complex configurations must be representable,
even if these requirements seem illogical during the implementation.
In particular, we wanted to streamline several operations that commonly
occurred in our environment.
* Copying one node's profile to another node.
In many environments, many nodes are instances of a common configuration
specification. They all have similar roles and software. In our
environment, desktop machines were the best example of this. Other than
strictly per-host configuration like SSH keys, all desktop machines
use a common configuration specification. This trivializes the process
of creating a new desktop machine.
* Creating a specialized version of an existing profile.
In environments with highly varied configurations, departmental
infrastructure being a good example, "another machine like X but with
extra software" is a common requirement. For this reason, it must be
trivially possible to inherit most of a configuration specification
from some more generic source, while being able to describe overriding
aspects in a convenient fashion.
* Compose several pre-existing configuration aspects to create a new profile.
The ability to compose configuration aspects allows the easy creation
of new profiles based on a series of predefined set of configuration
specification fragments. The end result is more agility in environments
where change is the norm.
In order for a classing system to be comprehensive, it must be usable in
complex ways. The Bcfg2 metadata system has constructs that map cleanly
to first-order logic. This implies that any complex configuration
pattern can be represented (at all) by the metadata, as first-order
logic is provably comprehensive. (There is a discussion later in the
document describing the metadata system in detail, and showing how it
corresponds to first-order logic)
These use cases motivate several of the design decisions that we
made. There must be a many to one correspondence between clients and
groups. Membership in a given profile group must imbue a client with
all of its configuration properties.
Package Management
------------------
The interface provided in the Bcfg2 repository for package specification
was designed with automation in mind. The goal was to support an
append only interface to the repository, so that users do not need to
continuously re-write already existing bits of specification.
|
