veyepar: Type driven configuration management with Propellor

Author(s):	Joey Hess
Location	Tasman Hall B/C
Date	jan Tue 17	Days Raw Files
Start	21:15	First Raw Start	20:40
Duration	0:45:0	Offset	0:34:12
End	22:00	Last Raw End	22:10
Chapters	00:00 0:25:17 0:41:30
Total cuts_time	46 min.

http://linux.conf.au/schedule/presentation/116/
raw-playlist raw-mp4-playlist encoded-files-playlist host archive tweet mp4 svg png

assets release.pdf Type_driven_configuration_management_with_Propellor.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:
Locked:	clear this to unlock
Locked by:	user/process that locked.
Start:	initially scheduled time from master, adjusted to match reality
Duration:	length in hh:mm:ss
Name:	Video Title (shows in video search results)
Emails:	email(s) of the presenter(s)
Released:	has someone authorised pubication
Normalise:
Channelcopy:	m=mono, 01=copy left to right, 10=right to left, 00=ignore.
Thumbnail:	filename.png
Description:	The configuration of Linux hosts has become increasingly declarative, managed by tools like Puppet and Ansible, and by the composition of containers. But if a server is a collection of declarative properties, how do you make sure that changes to that configuration make sense? You can test them, but eventually it's 3 AM and you have an emergency fix that needs to go live immediately. Data types to the rescue! While data types are usually used to prevent eg, combining an Int and a Bool, they can be used at a much more abstract level, for example to prevent combining a property that needs a Debian system with a property that needs a Red Hat system. Propellor leverages Haskell's type system to prove the consistency a host's configuration before deploying it. I'll show how Propellor started with a simple type for its properties, and increasingly refined the types as Propellor was developed, with the goal of catching as many configuration problems as possible, before the configuration gets deployed to the hosts. All the way up to type level detection of port conflicts! Propellor doesn't stop at configuring the top level of a host. It can reach inside containers on the host, and configure them using the same properties that can be used at the top level. It can create and manage chroots, docker containers, and systemd machines. A container defined in Propellor can be added to the multiple hosts, or moved between hosts by cutting and pasting a line in the config file. Propellor applies the same type-level checks to the properties of containers as to the properties of hosts. Going further, Propellor can create bootable disk images for a host. This unifies initial installation with ongoing configuration of a host. This is particularly useful for managing the configuration of embedded Linux systems, which are often painful to install interactively. This talk is full of examples of Propellor configuration in Haskell, but no knowledge of Haskell is required. markdown
Comment:	production notes