Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Berkshelf install failure for ganglia-0.2.1 #43

Open
aaduffy opened this issue Jul 23, 2014 · 1 comment
Open

Berkshelf install failure for ganglia-0.2.1 #43

aaduffy opened this issue Jul 23, 2014 · 1 comment

Comments

@aaduffy
Copy link

aaduffy commented Jul 23, 2014

This issue is about distribution of ganglia through the use of Berkshelf. Somewhere in the chain of custody between github and a machine running Berkshelf your cookbook is being mangled. This issue probably needs to be routed through another project but I have been unable to figure out who precisely. Please bare with me. I figure this project has a vested interest in proper distribution to Chef users. I am hopeful someone on this project can help redirect me to the proper place to log an issue, or someone will know enough to help convey the problem to the right people.

The issue:
when using ganglia-0.2.1 with Berkshelf the cookbook becomes damaged and cannot be uploaded to a Chef server because it fails validation.

Environment:
berkshelf: 3.1.4
chef server: 11.1.0

Analysis:
Uploading ganglia-0.2.1 with the command berks upload fails because of a validation error. The error reports as follows:

E, [2014-07-23T16:28:27.255594 #10823] ERROR -- : Cookbook file attributes/PaxHeader/ganglia.rb has a ruby syntax error:
E, [2014-07-23T16:28:27.256008 #10823] ERROR -- : /home/vagrant/.berkshelf/cookbooks/ganglia-0.2.1/attributes/PaxHeader/ganglia.rb:1: syntax error, unexpected tIDENTIFIER, expecting $end
E, [2014-07-23T16:28:27.256121 #10823] ERROR -- : 18 gid=1876110778
E, [2014-07-23T16:28:27.256721 #10823] ERROR -- :       ^
E, [2014-07-23T16:28:27.263077 #10823] ERROR -- : Ridley::Errors::CookbookSyntaxError: Invalid ruby files in cookbook: ganglia (0.2.1).
E, [2014-07-23T16:28:27.266391 #10823] ERROR -- : /var/lib/gems/1.9.1/gems/ridley-4.0.0/lib/ridley/chef/cookbook.rb:198:in `validate'

Viewing the contents of the ganglia cookbook on disk it is clear that there has been some error in the tar package handling. This may have occurred at github, at the Opscode supermarket intermediary, or in the Berkshelf code. Within the cookbook every directory is mirrored with a PaxHeader directory, which is a bookkeeping artifact from tar packaging. The PaxHeader directories should not show up in the output from tar. Here is a list of the files as they appear in the downloaded cookbook: https://gist.github.com/4ba91ca3463844aa16d4.git

In that output you can see that, for example, the attributes directory is mirrored by an attributes/PaxHeader directory. attributes contains the file ganglia.rb which has the actual ruby code to set cookbook attributes. attributes/PaxHeader contains the file ganglia.rb which includes metadata tar uses to track the file. Since attributes/PacHeader/ganglia.rb represents itself as a ruby file (by its file extension .rb) the Chef server attempts to validate the ruby contained within. Since the file is metadata, and not actual ruby code, the validation fails and uploading ganglia to the Chef server fails.

So the question is, where do things break down?

My project downloads 62 cookbooks in addition to ganglia. Ganglia is the only cookbook which manifests this particular problem. I am happy to attempt to find a forum in Opscode, or on GitHub to replay this issue, but I am uncertain whether and how the cookbooks provided through supermarket.getchef.com (where Berkshelf pulls Opscode blessed cookbooks) come from. Perhaps they have a cached copy of the project tar that was provided manually from this project?

For my part I am able to script deletion of PaxHeader directories and can move along smoothly. But I sense this may be a problem for other ganglia users who employ Berkshelf. I bring it up here because I suspect folks on this project will be the best advocates for this being straightened out. If I can be of assistance I am happy to do so, but will require input as to where the proper venue is for lodging this issue.

Thanks!

@fhats
Copy link

fhats commented Jul 30, 2014

+1, I ran into this problem recently as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants