Chef based uploads. Optional dependency resolution.

[chrisroberts]

Two updates in here. The first uses chef proper to perform cookbook uploads. This removes the requirement for ridley and lets berkshelf work properly on erchef.

The second bit allows for disabling dependency resolution on uploads to allow only uploading the cookbook(s) specified. Cookbook must be defined within the Berksfile, which is an acceptable requirement as this will likely only be used with cookbooks in active development (-D switch).

[reset]

@chrisroberts thanks for the pull request! I had a few questions:

• What changed with erchef that Ridley is now broken? Do you have a stack trace? As far as I knew there were no changes in the API.
• Prior versions of Chef server required you to upload all of the dependencies of a cookbook to the Chef Server even if they were already present. Is this changed?

[chrisroberts]

Hi @reset,

• sandboxing checksums would not match up with erchef. I think the deeper issue though is that the ridley bits feel more like a NIH approach that is easily solvable (and has better compatibility) using existing chef internals. I think the erchef interactions highlight this as using knife to upload cookbooks would work as expected but berkshelf would fail.

Example error from erchef:

2013-01-03T06:23:42Z erchef@127.0.0.1 INFO req_id=u1ry9UGpLdi6ZVFxF22Ysg==; status=400; method=POST; path=/sandboxes; user=croberts; msg={ej_invalid,fun_match,<<"checksums">>,{[]},object,object,<<"Bad checksums!">>}; req_time=10

• I have not run into chef server (any version) requiring an upload of all dependencies for each cookbook upload. So long as dependent cookbooks are available on the server, there is no issue uploading a lone cookbook. However, this may be due to using the internal chef uploader as opposed to ridley.

Thanks!

[reset]

• Ridley was written to be a thread safe and concurrent API client for Chef. The Chef internals use a singleton for their configuration in the form of Chef::Config. Multiple Chef Server support is on the roadmap for Berkshelf which would allow you to upload your cookbooks to X number of Chef Servers in one go. The API wrappers provided in the Chef internals did not do the job that we required. The Chef API is who holds the contract, not the Chef internals, so saying there is better compatibility by using the private classes in the Chef internals is not a true statement.
• If it wasn't Chef Server then it was the Knife cookbook upload command that required dependent cookbooks to be present in your cookbooks directory when uploading. It would make sense that this isn't a requirement since the API for uploading cookbooks is just sandboxes. I fully support having a skip-dependencies flag and this sounds very reasonable.

I will look into the issue with Ridley and the API exposed by erchef - it should be an easy fix.

If you'd like to rebase or re-open your pull request to include just the skip-dependencies CLI option on the upload command that would be awesome. I wouldn't include this as an option in the Configuration, though. This feels more like just a flag on upload that you would want to set. What do you think?

[reset]

Issue with the Chef API response from erchef solved with berkshelf/ridley#44

[reset]

released 1.1.2 to fix upload errors

[chrisroberts]

Cleaned pull req: #296