New build of ChefDK against new net-ssh

[wfarr]

net-ssh 2.8.0 — shipped with the current build of ChefDK — includes a rather annoying bug around ssh-agent and the IdentitiesOnly setting:

• if IdentitiesOnly is set to yes, the keys_only option gets set to true on Net::SSH, and when :keys_only => true, Net::SSH will never use the ssh agent.

This bad behavior was fixed in Net::SSH 2.9.0 (this commit specifically: net-ssh/net-ssh@6232252).

opscode/chef appears to look for ~> 2.6 when resolving dependencies, so a new build of the ChefDK should pick up the latest release of net-ssh.

I would very much appreciate a new build to address this bug! I spent a good chunk of time today hunting down why knife ssh was being fussy for me but not for my colleagues using Chef through means besides ChefDK. 😁

[lamont-granquist]

well, i agree, and we're in the process of cutting a new release, but there's really nothing actionable to do with this issue. no code to change, nothing to review, and it'll get fixed when we do a release. not sure about the utility of tracking this in an issue (certainly from my perspective this is just clutter that hangs around until we eventually do a release and then someone needs to go 'hey did we fix this?', and waste time tracking down the gem version in the latest release and validating it and closing it...)

[sethvargo]

@lamont-granquist what's the timeline for pushing out that release?

[lamont-granquist]

1-2 week-ish i think if not sooner.

[wfarr]

I look forward to the new release!

Is there any chance of getting an unofficial nightly that fixes this issue? I imagine your build infrastructure is a bit better equipped to build ChefDK via chef-omnibus than my little Macbook Air.

[lamont-granquist]

rolling releases/nightlies are on the plan, but we need to build out a better artifact storage and release script than what we've got right now. trying to do what you ask is just as burdensome to the team as building a release right now.

[wfarr]

Okay. Thank you for the response.

[danielsdeleo]

@wfarr while we don't have nightlies wired into the download page, you can get them via the api. Doing something like:

curl https://opscode.com/chef/metadata-chefdk\?p\=mac_os_x\&pv\=10.9\&m\=x86_64\&nightlies\=true

Will get you a download URL and checksums for the most recently published nightly. Though we're working on some stuff with test stability and false positives from our package integrity monitoring, so I can't make any promises as to the nightly-ness of the builds.

[danielsdeleo]

Oh, if you're not on mac, read this to get the right URL parameters. The API is kinda picky about those and just returns nothing if you get them wrong: http://docs.opscode.com/api_omnitruck.html

[wfarr]

I am on OSX, thanks! :)

[wfarr]

For anyone else watching this issue, I've pulled down http://opscode-omnibus-packages.s3.amazonaws.com/mac_os_x/10.9/x86_64/chefdk-0.1.1%2B20140615085052.git.36.f1ae9c1-1.dmg and it works swell here.

[lamont-granquist]

heh, when did we get nightlies working?

[lamont-granquist]

so in theory this should work, but in practice i'm getting a different result from the metadata endpoint and its 404'ing:

$ curl -L https://www.opscode.com/chef/install.sh | sudo bash -s -- -n -P chefdk

[lamont-granquist]

@danielsdeleo any ideas on what i'm missing with that ^^^

[lamont-granquist]

output: https://gist.github.com/lamont-granquist/b5bf07b98331130b4e3b

[lamont-granquist]

so... the curl | bash above should work, but the 404's are because we're still working out the bugs...

[danielsdeleo]

Not sure what's going on there. Maybe an S3 URL encoding issue?

[lamont-granquist]

well i can manually hit the metadata endpoint now and i get a 20140613 build that doesn't exist instead of the 20140615 build (that is still in s3). it looks like omnitruck lost some state?

sort of wonder if the %-encoded '+' isn't confusing the opscode-version library that omnitruck uses...