I'm always very impressed with Joey's work. I'm a heavy user of git-annex. My concern with Propeller is there's too much fragmentation around configuration management tools: this is something that only Propeller can do, and the impression I get is that most other projects support Chef or Puppet, while I'm currently using Salt, because I like its pattern of declaring the desired state of a system (and I picked it before Joey released Propeller).

It seems all to easy to jump on one technology stack, gain its improvements, but find that there's a whole lot of nice things you've locked yourself out of, because you can't really use more than one tool at once. And because implementation language seems to be a core feature, I'm not sure reusing modules is a feasible.

I don't have any suggestions, though :(.

Well, I suppose it's perfectly valid to write a propellor property

puppetClient PuppetConfig :: Property

So if propellor's capabilities for (re)installing a system are why you want to use it, it can be composed with other configuration management tools this way.

Of course, I wrote propellor because I've read enough puppet and chef and ansible and salt documentation that I knew it would be easier to write my own tool that I fully understood and worked just the way I wanted, rather than learning those rest well enough to pick one, and then mangle it to behave the way I wanted. Quite aware that only solves the problem for me. ;)

So, what is the use case for this ability? The first thing that occurs to me is running an OS on a VPS provider that they don't natively support (e.g. Gentoo on DigitalOcean.) But since VPS providers are generally using PV Xen instances, the kernel is controlled from outside--so you can't just overwrite the one in the rootfs and update grub and call it a day.

The current solution involves leaving the old OS around, making the new OS a squashfs image on disk, and then setting up the old OS to kexec the new one early on in each boot cycle. It's be cool, though, if you could figure out a way with Propellor to have the new OS live in the rootfs, in harmony with the most minimal fragments of the old OS necessary to kexec.

I humbly request you make D-I more user friendly and predictable for automated installations first. In particular, partman is nearly inscrutable, especially on modern systems with EFI, GPT, LVM, and so forth.