Today I want to write about the work I’m currently commisioned for by puppetlabs, porting puppet to Microsoft Windows.

Current Status

After disabling some minor pieces (color, conf file watching) and fixing a few bugs (see the tree on github) and a little bit hacking various parts to pass through paths with a drive letter, I was able to create the first file on windows with puppet. On the downside a few technical problems with the code surfaced, the most daunting were approximately 600 spec failures (out of 8.500 examples).

The Plan

Markus Roberts and myself used some of the breaks and sessions to hash out solutions for the various hurdles that I identified. After fixing those, we can move on to pushing the actual basic Microsoft Windows support to master without breaking hell loose and start implementing providers on a larger scale, while people have something in hand to start playing with.

Unit Testing

This one was easy. Most of the test failures are caused by examples that use Puppet::Type.type(:file) when they need a type to test the “other” functionality they’re testing. This legacy is a result of bad experiences with examples that did not fail after removing the “tested” code, because they were stubbing away too much. As a next step in the evolution of such examples, puppetlabs will create an simple, instrumentable type specifically to be used in tests. That way it’ll be a “real” type for the examples, without any of the complex functionality needs of “real” types.

File is lacking providers

In my git tree is already a start of a POSIX and a Microsoft Windows provider for file handling. This is currently only a spike implementation and will have to be seriously expanded once the unit tests don’t blow up when touching this area.

Moving to multi-valued titles

I’ve started a discussion about the design of multi-valued titles on the puppet-dev mailing list. This should make implementing the various path syntaxes much more convenient and easier to handle in the file type. Markus promised me a prototype to play with.

Providing actual functionality

There was discussion at the puppetcamp whether or not to use the command line tools from the resource kit to manipulate users, groups, services and what-not. While I have not looked deeply into this, as my focus until now was getting puppet to run at all, I believe those tools will be a good source of what should be possible, but no good for implementing the providers. One, the tools are another external dependency, they have localized output which will make parsing them very hard, and the output can differ from one release to the next. On the other hand, MRI has quite flexible ways to access the underlying C APIs of Microsoft Windows and those functions are documented and should be quite stable.

Let me quote the pertinent part from Luke’s mail:

DavidS wrote:

• Create a new github account to collect all modules with a repo per module.
• Add devs as available to the modules/repos as collaborators to allow them to push changes.
• Use the issue tracker attached to each module for bug tracking.
• Use a meta-repo to combine “matching” module versions into “releases”.
• Encourage wide-spread collaboration.

I’m willing to do all the necessary legwork to set this up. Just say the word.

That’s basically the plan. If you make a ‘puppet-modules’ account and want to set it up… That would be awesome.

So there we go, I’ve created a puppet-modules account on github where useful and maintained repos can be published. To seed the effort I’ve already committed a few of my core modules and expect to add some more at a later time when the workflow is settled in.

The primary entry point for local perusal is the puppet-manifests repository which contains all others as submodules. This is very convenient to clone all modules at once:

$ git clone git://github.com/puppet-modules/puppet-manifests.git
$ cd puppet-manifests/
$ git submodule init
$ git submodule update

Within modules/ you can now find git repositories for all published modules, ready to go.

For working on the repos, I’ve created forks of all modules in my private github account to avoid cluttering the “published” versions.

If you have any patches or modules to contribute or want to collaborate, please use github’s issue tracker of the concerned module or send a shout to puppet-users or me privately.

Puppet doesn’t care whether it manages one or a hundred servers with the same configuration. Contrary to manual configuration, the effort scales with the number of programmed services instead of the number of administrated servers.

Another important factor is the organisation of configuration into modules. These can be developed, tested and deployed independently. David runs the first and one of the biggest public repositories of such modules under the very liberal BSD-License. Thanks to my engagement in the puppet community I was recently asked by multiple IT-departments to hold on-site trainings.

Finally it has to be noted that a manifest (puppet configuration) is a very detailed documentation of the (intended) system state.

David uses puppet for EDV-Beratung&Service to run a web- and mail hosting system. Before the advent of puppet, each customer was configured manually, leading to all kind of errors. With puppet any error gets fixed once and for all by improving the source code of the puppet manifest. Additionally this will also fix the problem on all existing customers.