In the course of the
PuppetCamp Europe, I met with many people I only knew from IRC and email and it was a great time with interesting and inspiring discussions.
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.
