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 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: P 1 ==P 2 (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) X Y A B C 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( π)

Promise theory in action (2) A B C D C( π) X π U( π) π

Promise theory in action (3) A B C D C( π) X π U( π) 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.