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.

Sign up for GitHub

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

Jump to bottom

TypeError: no implicit conversion of nil into Integer in detect_unprocessed_resources #5565

Closed
kpmueller opened this issue Nov 18, 2016 · 9 comments
Closed

TypeError: no implicit conversion of nil into Integer in detect_unprocessed_resources #5565

kpmueller opened this issue Nov 18, 2016 · 9 comments
Assignees
@adamleff

Comments

@kpmueller
Copy link

kpmueller commented Nov 18, 2016 •
edited
Loading

Description

Chef run crashes during detect_unprocessed_resources with TypeError: no implicit conversion of nil into Integer

Chef Version

12.16.42-1

Platform Version

Ubuntu 14.04

Replication Case

Dunno

Client Output

  * aws_s3_file[/etc/ssl/certs/build.piazza.com.crt] action create
    * remote_file[/etc/ssl/certs/build.piazza.com.crt] action create (skipped due to not_if)
     (up to date)
  * aws_s3_file[/etc/ssl/private/build.piazza.com.key] action create
    * remote_file[/etc/ssl/private/build.piazza.com.key] action create (skipped due to not_if)
     (up to date)
  * template[/etc/nginx/sites-available/build] action create (up to date)
  * execute[nxensite build] action run (skipped due to not_if)
  * execute[nxdissite default] action run (skipped due to only_if)

Running handlers:
[2016-11-18T12:06:43-08:00] ERROR: Running exception handlers
Running handlers complete
[2016-11-18T12:06:43-08:00] ERROR: Exception handlers complete
Chef Client failed. 15 resources updated in 11 seconds
[2016-11-18T12:06:43-08:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2016-11-18T12:06:43-08:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2016-11-18T12:06:43-08:00] ERROR: no implicit conversion of nil into Integer
[2016-11-18T12:06:43-08:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

Stacktrace

chef-stacktrace.out
@chr4
Copy link
Contributor

chr4 commented Nov 21, 2016

I was experiencing the same issue, and I found the cause (for me). As the error message is pretty generic, it was hard to track down.

I'm using the cacert cookbook and in my case this issue was because of an attribute named hash:

attribute :hash, kind_of: String, default: nil

As soon as I renamed the attribute to cert_hash instead, the issue was gone. Apparently, starting from chef-12.16.42, naming an attribute hash will result in this (or a similar) error.

I'm just releasing a workaround-version for the cacert cookbook. I'm not sure whether this behaviour is intentional?

@adamleff
Copy link
Contributor

@kpmueller Thanks for the issue report!

@chr4 thanks for chiming in with additional information. That is definitely not intended behavior, and the resources attribute names shouldn't affect this, so we need to get this fixed.

Can you provide additional details so I can build a reproducible test case? Any specifics on how you're using the cacert cookbook, what version of the cookbook you used, etc. would be mighty helpful so I can nip this in the bud. Thanks!

@chr4
Copy link
Contributor

chr4 commented Nov 21, 2016 •
edited
Loading

Thanks for looking into this! The error should be easily reproducible:

Using cacert-0.3.0 and running chef-client --once -o 'recipe[cacert::cacert.org]' should make Chef "run through", but display "failed" at the end. The above error message will show up in the logs, and a stacktrace is dumped.

Let me know in case you need more information.

@adamleff
Copy link
Contributor

@chr4 thanks for the response. I'm about to head out on vacation, but this is on my list of stuff to do between family things and hopefully I'll have an answer for you next week. I appreciate your patience.

@chr4
Copy link
Contributor

chr4 commented Nov 21, 2016

As I've published a workaround-release, this works for now and there's no need to hurry. Enjoy your vacation!

@kpmueller
Copy link
Author

the workaround in ca-cert is working for me, too. I don't have a reproducible test case other than what chr4 has given.. thanks!

@adamleff
Copy link
Contributor

Sorry folks, didn't want you to think I forgot about this. Still plan on digging into this deeper this week. Thanks for your patience.

@kpmueller
Copy link
Author

I think my error was due to cacert::cacert.org cookbook. The workaround has fixed my problem! So no rush, for my part. (thanks for looking at it, by the way!)

@thommay thommay added this to the Accepted Minor milestone Nov 30, 2016
@adamleff adamleff mentioned this issue Dec 1, 2016
Merged
adamleff added a commit that referenced this issue Dec 1, 2016
@adamleff
Use object ID when detected unprocessed Resources
450fbb1 
In the Data Collector, when detecting unprocessed resources, a Set
was built up using the resource object itself as the Set element.
Internally, Set adds this to a Hash.

We allow users to create custom resources that could contain a property
named "hash" which in turn wires up a `#hash` instance method on the
Resource. Ruby expects object's `#hash` method to return a Fixnum that
it uses internally. So if a resource had a "hash" property that returned
a String, bad things happened.

With this change, we make our own Hash and use the resource's object ID
in the key so we don't have to worry about the resource's `#hash` method
getting called and throwing an exception. I will send up a separate
change that warns users when they choose a property name that is already
an existing method name.

Fixes #5565.

Signed-off-by: Adam Leff <adam@leff.co>
@adamleff
Copy link
Contributor

adamleff commented Dec 1, 2016

@kpmueller and @chr4: I've sent up PR #5604 that will fix this moving forward, and I also plan on adding warnings (and possibly deprecations) if a resource attempts to use a property that happens to be named the same as an existing ruby method, as bad things happen in certain cases, like this one where #hash is expected to be a method on every Ruby object and return a Fixnum. In this case, you had a hash property that returned a string, which is why changing the name of the property fixed your issue.

Thanks again for the report and also thanks for fixing your cookbook!

adamleff added a commit that referenced this issue Dec 5, 2016
@adamleff
Use object ID when detected unprocessed Resources
31ded71 
In the Data Collector, when detecting unprocessed resources, a Set
was built up using the resource object itself as the Set element.
Internally, Set adds this to a Hash.

We allow users to create custom resources that could contain a property
named "hash" which in turn wires up a `#hash` instance method on the
Resource. Ruby expects object's `#hash` method to return a Fixnum that
it uses internally. So if a resource had a "hash" property that returned
a String, bad things happened.

With this change, we make our own Hash and use the resource's object ID
in the key so we don't have to worry about the resource's `#hash` method
getting called and throwing an exception. I will send up a separate
change that warns users when they choose a property name that is already
an existing method name.

Fixes #5565.

Signed-off-by: Adam Leff <adam@leff.co>
@btm btm closed this as completed in #5604 Dec 12, 2016
btm pushed a commit that referenced this issue Dec 12, 2016
@adamleff @btm
Use object ID when detected unprocessed Resources (#5604)
a4e5ed2 
* Use object ID when detected unprocessed Resources

In the Data Collector, when detecting unprocessed resources, a Set
was built up using the resource object itself as the Set element.
Internally, Set adds this to a Hash.

We allow users to create custom resources that could contain a property
named "hash" which in turn wires up a `#hash` instance method on the
Resource. Ruby expects object's `#hash` method to return a Fixnum that
it uses internally. So if a resource had a "hash" property that returned
a String, bad things happened.

With this change, we make our own Hash and use the resource's object ID
in the key so we don't have to worry about the resource's `#hash` method
getting called and throwing an exception. I will send up a separate
change that warns users when they choose a property name that is already
an existing method name.

Fixes #5565.

Signed-off-by: Adam Leff <adam@leff.co>
@chef chef locked and limited conversation to collaborators Nov 16, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@adamleff adamleff

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@thommay @adamleff @chr4 @kpmueller