Aspects and Closures and Promises (Oh My!)

Alva L. Couch

Tufts University

Goals

• To form a unified theory of system administration

• To point out similarities and differences between existing theories

• To suggest next steps

Aspects

• Embody the idea of constraints needed in order for a system to work properly. – Example: the hostname has to be listed

identically in several files in /etc.

• An aspect is a pair <P, C> where– P is a set of parameters. – C is a set of constraints on parameter value.

Key ideas of aspects

• Parameters stored in different locations are considered distinct.

• Most common constraint is identity: P1==P2 (note that we mean the values of the parameters, not their names!)

• Easiest way to manage aspects: generate all configuration data from “one file”, where identity relationships are automatically preserved.

Closures

• Idea of a closure: a domain of “semantic predictability”.

• Theoretically, a function F from a set of sequences of inputs to predicted outputs

• A closure is a function F:Σ*→Σ where– Σ is an alphabet of transactions that can occur– Σ* is the set of all sequences of transactions

Closure structure

• The definition of a closure is easy. • The “structure” of a closure arises from

equivalences on Σ*, where we consider g≡h whenever F(g)=F(h)

• This gives rise to a set of equivalence classes of inputs Σ*/≡, where the members of each class evoke the same response.

• The “configuration” of a closure can be considered as the equivalence class E⊆Σ* (under the equivalence relation ≡) corresponding to the inputs received so far.

Closures and aspects

• If transactions involve selecting parameter values in accordance with constraints, and behaviors are predictable as a result, then an aspect (together with its behavior) forms a closure.

Distributed aspects

• Many aspects are “distributed” among a network.

• Example: the identity of the DNS server has to be a server that in actuality provides DNS service.

• Logic behind generative configuration management: distributed aspects are guaranteed to be correct.

Promises

• A promise is a commitment to provide service.

• A →π B: A promises π to B

• π contains two parts– A “type” T that distinguishes the kind of

promise. – Subsidiary data D that further identifies

the nature of the promise.

One primitive kind of promise

• Type T = a parameter name

• Data D = a parameter value

• Interpretation: if you set this parameter to this value, “it’ll all work”.

Another kind of promise

• T=“DNS service”

• D=“I am a DNS server you could use”

• You could decide, based upon receiving this promise, whether to bind to that DNS server or not.

Degenerate case: master/slave

• One host serves as “master”.

• It “promises” that if everyone conforms to a specific configuration, all will work.

X

A

B

C

D

E

F

π

π

π

π

π

π

Distributed masters for differing aspects

• Natural evolution: one master/aspect (in Paul Anderson’s definition of the word)

XY

A

BC

D

Promise types

• π: a promise to provide something• U(π): an acknowledgement or agreement

to use the value contained in π• C(π): an agreement to coordinate value of

π with another host, so that the two hosts agree on the value of π– A –C(π)→ B means

• A asks B to coordinate with A on π. • B responses that it will coordinate. • B responds with values for π (as π is updated).

Promises and closures

• A promise is something made between agents, not something that exists in an agent by itself.

• Inside an agent, we want “closure”. • Between agents, we have “promises”.• Thus there is little meaning to a promise

within a closure, but a rather straightforward meaning between closures.

Promises and constraints

• A promise always– binds the sender with a constraint. – provides an option to the receiver.

• A promise never – binds or constrains the receiver. – requires a response.

Simple promises

• A sends π to B. • B sends U(π) to A. • Thus A and B are bound together. • Example: A provides file service,

directory service, backup service, etc. B agrees to use service provided by A.

Promises and distributed aspects

• A promise is a way of communicating constraints to other hosts.

• It always gives options.

• So the receiving host may choose between options given.

• Distributed aspects are satisfied by using only promised services.

Promise theory in action

A B

C D

C(π)

C(π)

C(π)

Promise theory in action (2)

A B

C D

C(π)

C(π)

C(π)

Xπ

U(π)

π

Promise theory in action (3)

A B

CD

C(π)

C(π)

C(π)

Xπ

U(π)V(π)

ππ

V(π)

ππ

V(π)

At the end of this process, all coordinated nodes share service X.

How networks self-organize from promises

• Servers broadcast promises to serve.

• Clients receive broadcasts, promise to use.

• Communities use coordination promises to ensure a consistent environment.

• Result is bindings that form distributed aspects.

Promises and distributed aspects

• Promises solve the problem of non-working services and bad bindings.

• But there is no way to undo a promise!

• If a host decides not to be a DNS server, must reboot the promise process.

• Bindings occur at boot time and are not persistent between boots.