Success Stories for chef-dk on Windows


#1

Ohai, all!

Is chef-dk (0.3.5 and 0.3.6) working well for Windows users? I’ve not been
tracking chef-dk as closely as I’d like, so apologies if this is a repeat
question.

Since pulling off my stand alone ruby install and running out of the box
chef-dk, I’ve had problems with both foodcritic (runs silently do nothing)
and with test-kitchen (converge actions die due to pathnames being too
long). I run with a couple different drives (C: for chef-dk, D: for most of
my cookbook dev repos, and E: for my sandbox VMs) and suspect this may be
the root of Much Evil™ for ruby based tools (the heartache I’ve gone
through with Vagrant on this is staggering).

I’d appreciate any thumbs up/down from fellow Windows 7 users that have
multiple drives and are using chef-dk. I keep my host OS pretty clean and
it’s unlikely (though certainly possible) that I’ve radically tweaked
something in a way that doesn’t appreciate being tweaked.

David


#2

Sorry, not a Windows user here so I can’t thumb up or down, but as a
Windows sysadmin (formerly anyway), when I hear something like “path names
too long” I have to ask: are said path names actually too long? NTFS is not
friends with path names longer than 255 characters, which I know is a
grotesque notion in this day and age, but a source of problems nonetheless,
and if you have such paths, it’s not an issue directly related to Chef-DK,
although you could blame it for creating those paths in the first place! :slight_smile:

On Wed, Jan 28, 2015 at 9:09 AM, David F. Severski davidski@deadheaven.com
wrote:

Ohai, all!

Is chef-dk (0.3.5 and 0.3.6) working well for Windows users? I’ve not been
tracking chef-dk as closely as I’d like, so apologies if this is a repeat
question.

Since pulling off my stand alone ruby install and running out of the box
chef-dk, I’ve had problems with both foodcritic (runs silently do nothing)
and with test-kitchen (converge actions die due to pathnames being too
long). I run with a couple different drives (C: for chef-dk, D: for most of
my cookbook dev repos, and E: for my sandbox VMs) and suspect this may be
the root of Much Evil™ for ruby based tools (the heartache I’ve gone
through with Vagrant on this is staggering).

I’d appreciate any thumbs up/down from fellow Windows 7 users that have
multiple drives and are using chef-dk. I keep my host OS pretty clean and
it’s unlikely (though certainly possible) that I’ve radically tweaked
something in a way that doesn’t appreciate being tweaked.

David


#3

Hi David,

ChefDK works fairly well on Windows I would say. There are some glitches if
you install it to anything other than C:/opscode/chefdk afaik

If you want to keep your system clean and have taken care of the above
mentioned issue you might be interested in this:

Here’s an example cookbook repo which runs all kinds of tests (including
test-kitchen) in a bundle environment, which works perfectly fine with the
ChefDK embedded Ruby (in fact this is part of my acceptance test suite for
bills kitchen ;-)):

HTH,
Torben
Am 28.01.2015 15:09 schrieb “David F. Severski” davidski@deadheaven.com:

Ohai, all!

Is chef-dk (0.3.5 and 0.3.6) working well for Windows users? I’ve not been
tracking chef-dk as closely as I’d like, so apologies if this is a repeat
question.

Since pulling off my stand alone ruby install and running out of the box
chef-dk, I’ve had problems with both foodcritic (runs silently do nothing)
and with test-kitchen (converge actions die due to pathnames being too
long). I run with a couple different drives (C: for chef-dk, D: for most of
my cookbook dev repos, and E: for my sandbox VMs) and suspect this may be
the root of Much Evil™ for ruby based tools (the heartache I’ve gone
through with Vagrant on this is staggering).

I’d appreciate any thumbs up/down from fellow Windows 7 users that have
multiple drives and are using chef-dk. I keep my host OS pretty clean and
it’s unlikely (though certainly possible) that I’ve radically tweaked
something in a way that doesn’t appreciate being tweaked.

David


#4

Correction to my earlier response: technically it’s not NTFS that’s the
problem, rather it’s a legacy Win32 API that is still omnipresent.

On Wed, Jan 28, 2015 at 9:46 AM, Torben Knerr mail@tknerr.de wrote:

Hi David,

ChefDK works fairly well on Windows I would say. There are some glitches
if you install it to anything other than C:/opscode/chefdk afaik

If you want to keep your system clean and have taken care of the above
mentioned issue you might be interested in this:
https://github.com/tknerr/bills-kitchen

Here’s an example cookbook repo which runs all kinds of tests (including
test-kitchen) in a bundle environment, which works perfectly fine with the
ChefDK embedded Ruby (in fact this is part of my acceptance test suite for
bills kitchen ;-)):
https://github.com/tknerr/sample-toplevel-cookbook

HTH,
Torben
Am 28.01.2015 15:09 schrieb “David F. Severski” davidski@deadheaven.com:

Ohai, all!

Is chef-dk (0.3.5 and 0.3.6) working well for Windows users? I’ve not
been tracking chef-dk as closely as I’d like, so apologies if this is a
repeat question.

Since pulling off my stand alone ruby install and running out of the box
chef-dk, I’ve had problems with both foodcritic (runs silently do nothing)
and with test-kitchen (converge actions die due to pathnames being too
long). I run with a couple different drives (C: for chef-dk, D: for most of
my cookbook dev repos, and E: for my sandbox VMs) and suspect this may be
the root of Much Evil™ for ruby based tools (the heartache I’ve gone
through with Vagrant on this is staggering).

I’d appreciate any thumbs up/down from fellow Windows 7 users that have
multiple drives and are using chef-dk. I keep my host OS pretty clean and
it’s unlikely (though certainly possible) that I’ve radically tweaked
something in a way that doesn’t appreciate being tweaked.

David