blob: 26d628cb3b1416a5dcc63ce6f6d63f8d81ae4a3f (
plain)
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
|
One of the more grungy and fragile portions of the bcfg1 configuration
description interface is that of bundle allocation. To wit, tags are
used for two purposes in this same process. The first use is for
initial choice of the software complement for any particular node. The
second use is for specialization of particular nodes. The use of a tag
for either purpose isn't particularly discernible from the other,
moreover, tags can be used for multiple purposes simultaneously.
<service name='internal-dns' type='dns' scope='local'>
<producer host='antares' port='53' type='udp/ip'
bundle='dhcp-server'/>
<consumer tag='dhcp-config'/>
</service>
There is a whole lot going on here, so i will highlight the
particulars i think are important.
1. There is explicit linkage between a service and the software that
provides it.
2. there is an explicit scope to describe "how far" the service goes
3. there is a notion of what network transport is required.
4. you can construct monitoring/firewalling rules from this
5. you can infer failure cascades from the relationship
6. tags are used in choosing configurations as a specialization
mechanism, no just through bundles.
How do we extend the idea of coherence from bcfg1?
|
