ChefDK for Windows: Progress Update

Hi Chefs,

I’d like to give you a quick update on our progress towards shipping a Windows build of ChefDK. I know that with the dependency solver changes in Berkshelf 3, it can be a struggle to get berks running on Windows so we’re working to get you a build as soon as we can.

Here’s an overview of the things we’re working on to get ChefDK for Windows ready to ship:

Update Omnibus Build Definitions

The first step is to actually get the thing to build using our Omnibus
build tool. The good news here is that we have a working build, and are
now just cleaning up our patches to make them suitable to merge. The
relevant pull requests are:

Add/Fix Windows Support In Build Tools

ChefDK uses Appbundler to create the executables for embedded applications. Appbundler provides a performance boost over regular Rubygems executables and locks dependencies to known good versions while still allowing plugins to be loaded. On Windows, Ruby executables need to be wrapped in small batch scripts in order to be run directly on the command line. We’ve added support for batch script generation in pull request #3

Update Chef for Ruby 2.0 on Windows

The latest Ruby versions include some performance improvements for Windows and Ruby 1.9.3 end-of-life is just around the corner, so we want to ship the newest Ruby available with ChefDK. We’ve found two issues so far when running Chef on Ruby 2.0 on Windows. The first was a simple dependency update to the win32-api gem which we have already merged. Once that was fixed, we found that the ruby-wmi gem was crashing Ruby when running the tests. We don’t use many of ruby-wmi’s features, so we’re investigating accessing Win32OLE directly as a way to workaround the issue. We’re currently testing the following patches to see if they resolve this problem: Chef PR #1405 (so far so good!).

Update Omnibus to Better Support MSI Creation

To create the MSI with the right images, text, etc. we need to rewrite our MSI creation code, which is currently hard-coded to building chef-client. The relevant pull request is Omnibus Ruby #149.

Add Windows Machines to the Build Cluster

This is ongoing. The cookbooks we use to configure our internal CI infrastructure are private, so I unfortunately cannot share any code with you.

QA

Once we’ve fixed the above issues, we’ll begin publishing nightly builds of ChefDK for Windows. From there, we’ll do some manual QA to try to catch any bugs that could have slipped past our automated test suites.

ETA?

We’re optimistic that we’ll be able to get a release out for you soon, but like any complex software project, there’s a risk that we could uncover more bugs as we get further along and continue to test. We’ll keep you updated on our progress and we’ll certainly be asking for your help with testing as soon as we have the nightly builds out. Stay tuned!

Author Dan DeLeo

  • codesilverback

    Can I suggest Chef start dogfooding on Windows? It is the only way to bring your Windows offering up to snuff. Lenovo makes some really nice ultrabooks these days ;)

    • Hillsid3

      Yeah, like an alpha version. This way we ourselves could let you guys know the bugs.

      • There aren’t packages yet to release as alpha. As soon as the build cluster is configured and producing builds, the nightly builds will be available and will serve as alpha releases.

    • We do have developers on Windows, myself included. ChefDK is a brand new project, so it will take some time to get all of the engineers to tear down their existing tools and switch their workflow over while minimizing delay to their own projects. All of the Windows developers will be switching over to ChefDK before others, because ChefDK on Windows will be providing some tools that weren’t working on Windows previously and will be a significant step forward.

      • codesilverback

        Good to hear. There’s tremendous room for growth on that platform and right now it seems like an afterthought to team Chef.

        • It’s far from an afterthought. We have dedicated resources kicking out Windows all the time, from multiple teams. Totally committed to Windows being a first-class citizen.

          The biggest obstacle to that, as the blog post illustrates, is really just getting all the other core technologies to treat Windows as a first class citizen. Once we have that, the rest is all down hill :)

          • codesilverback

            Hey Adam, I appreciate you weighing in, and I hate to be that guy, but it is totally clear that you guys don’t do much testing on Windows.

            I found another “doesn’t work at all” issue in another opscode cookbook today. https://github.com/opscode-cookbooks/jenkins/issues/210

          • I’m sorry you had a problem with a cookbook.

            Like I said, it’s far from an afterthought, but there is quite a bit of groundwork to be done just to get to the place where it’s even possible to get to test parity across content. That’s why the DK work is so important, and that’s why we’re making the investment in ensuring the same high level of functionality in the core tooling works across all the platforms people develop for Chef on, including Windows.

            Part of improving that quality is being able to prove it – and proving it means getting the entire toolchain in tip-top shape. The fact that it’s not perfect (yet) doesn’t mean it’s an afterthought – it just means we can only make progress as fast as we can type. :)