University of Cambridge > > Microsoft Research Cambridge, public talks > Composition and Inheritance in Declarative Configuration Languages

Composition and Inheritance in Declarative Configuration Languages

Add to your list(s) Download to your calendar using vCal

If you have a question about this talk, please contact Microsoft Research Cambridge Talks Admins.

Please note, this event may be recorded. Microsoft will own the copyright of any recording and reserves the right to distribute it as required.

Configuring large computing installations is a difficult problem—there are many different subsystems involved, all with their own language, and many different people with an interest in overlapping aspects of the overall configuration. Deploying and maintaining a configuration which reliably meets everyone’s “higher-level” requirements is hard, and configuration errors are responsible for a significant proportion of system failures.

Almost all large installations use some type of “configuration tool” in an attempt to automate and unify the process. These often involve some kind of custom specification language, which is often claimed to be “declarative”. But all practical configuration languages have developed in very informal ways, with a complex semantics which are error-prone and difficult to use. Declarative configuration languages in particular, are quite different from programming languages, and have not been widely studied in any formal way, despite their critical role in most large infrastructures.

For a long time, I have been interested in understanding the overall configuration process, and particularly in designing more usable languages, which provide specific features to support this in a clear in and correct way. Although there is little directly related work, this has led to interesting connections with a number of other areas, two of which have been the subject of previous Microsoft Research Phd Scholarships:

- The use of constraint-based specifications1 (with Andy Gordon) particularly the novel use of these of these to support conflict-free composition of partial specifications from different stake-holders

- The use of provenance techniques (from the database field) to track the dependencies between final configuration parameters and the source specifications which affect them2 (with Dimitrios Vytiniotis). This has implications for fault diagnosis, and security (which is not addressed well, if at all, in current languages), and it suggests new ways of resolving potential conflicts.

I have also been involved in the deployment of the resulting configurations, particularly distributed agent-based approaches using automated planning.

Recently, we have been trying to formalise the semantics of practical declarative configuration languages[3,4] and the difficulty of this has highlighted some of the reasons why this type of language has acquired an (unnecessary) reputation for complexity. This has led to an interest in human-factors work on the usability of configuration languages5, and it seems that these considerations should be a fundamental part of the design process for any new language – I have a (currently unfunded) proposal for a Phd in this area6.

I plan to use some recent work on composition of configurations as the focus for a talk which will draw on various aspects of this previous work. The short note [7] is an accessible description of this for a non-specialist audience. However, I would like to share my experiences with the configuration problem in general to see if there was any further possible synergy, and I would be happy to focus more on any aspects which may be of interest, and to discuss anything else which may potentially be of common interest.

Paul Anderson


- “Puppet” ( is probably the most common “declarative” tool.

- “Cfengine” ( was one of the first-generation tools which claimed to be “declarative”.

- “SmartFrog” ( probably has the cleanest semantics, but has never been widely used outside of HP.

- “LCFG” ( was developed here in Informatics, and is probably the oldest “declarative” tool. But the “language” is very primitive, and the tool is not widely used outside of the University.

- Chef ( is derived from Puppet, but takes a more imperative approach, probably due to the apparent difficulty of using the Puppet language.

- “Ansible” ( is a more imperative approach focussing on “tasks” which are executed in order” – this is claimed to be more simple than a declarative approach.

- Microsoft Powershell ( is an an imperative language and framework for scripting configuration changes, however DSC (“desired state configuration”) introduces some declarative features.


Summary: The short note [7] is an informal introduction to the composition problem which avoids the distracting details of ``real’’ configurations, and the technicalities of ``real’’ configuration languages. [4] is a good introduction to the difficulties and complexities of ``real’’ languages, and the more formal work on the semantics. [2] is a short position paper which illustrates some usability problems and motivates the current work provenance work.

[1] Constraint-based autonomic configuration 2013 Self-adaptive and self-organizing systems conference (SASO), September 2013 John A Hewson & Paul Anderson & Andrew D Gordon

[2] Toward provenance-based security for configuration languages The 4th Usenix workshop on the theory and practice of provenance, June 2012 Paul Anderson & James Cheney

[3] A formal semantics for the SmartFrog configuration language Journal of Network and Systems Management Paul Anderson & Herry Herry

[4] μPuppet: A Declarative Subset of the Puppet Configuration Language Technical report, December 2016 Paul Anderson, James Cheney, Weili Fu & Roly Perera

[5] Usability of System Configuration Languages: Confusion caused by Ordering Adele Mikoliunaite

[6] Usability of System Configuration Languages – IGS Studentship Proposal

[7] Composition in the L3 Configuration Language

This talk is part of the Microsoft Research Cambridge, public talks series.

Tell a friend about this talk:

This talk is included in these lists:

Note that ex-directory lists are not shown.


© 2006-2019, University of Cambridge. Contact Us | Help and Documentation | Privacy and Publicity