Bring cookbook up to Chef 13 compliance

[strong-code]

This PR brings this cookbook up to Chef 13 compliance. A breaking change in version 13 did not allow for unsafe access of node attributes in custom resources.

As this cookbook currently stands, this error is thrown when attempting to use the custom resource:

ERROR: can't modify frozen Chef::Node::ImmutableArray

The solution is to call .dup on each attribute accessed inside of ./resources/default.rb or to move values directly into that file. I tried to find a good middle-of-the-road solution.

For anything that had a simple (read: 1 liner or blank array) value, I moved it directly into the ./resources/default.rb file and removed it from ./attributes/default.rb. I also migrated the comments where appropriate.

For larger values, I left them in ./attributes/default.rb and called the .dup method on them to safely clone the node attribute when it is referenced inside of the custom resource file.

I know this is kind of an ugly PR, and I am happy to work with the maintainer to clean it up. I am not sure if you would prefer for everything to be placed directly into ./resources/default.rb or leave it as is and instead call .dup on every node attribute referenced.

[strong-code]

Also to note, I tested & verified my changes on Chef version 13.7.16

[chr4]

Thanks for investigating this!
The pattern to use attributes as default values in providers was a workaround to fix the mess in Chef to allow both: attributes in node configuration, as well as LWRP usage. Apparently, this workaround doesn't work anymore in Chef 13.

The PR looks good to me, I'd just ask you to remove the metadata.yml change.
I think this PR would require a major version bump, as it might break existing configurations, and I'm going to write a Changelog entry as well explaining this before the release. If you want to take a shot, feel free to do so - otherwise, just remove the version change and I'll handle it.

[strong-code]

@chr4 I've reverted the metadata.rb change, and I'll let you update the CHANGELOG as well.

I also added my Vagrantfile line to .gitignore. I'm not sure if there is any utility in including it, but it could help for local testing and development against various Chef versions. I can remove it from the .gitignore file if you'd prefer.

[chr4]

The Vagrantfile in .gitignore is fine for me.

This completely disables node configuration. Maybe we can use something like this to continue supporting it?

attribute :head, kind_of: [Array, String], default: node['resolvconf']['head'].dup
attribute :base, kind_of: [Array, String], default: node['resolvconf']['base'].dup
attribute :tail, kind_of: [Array, String], default: node['resolvconf']['tail'].dup

This would create a problem though when the default attribute is not set, so maybe there's a way to do something like

if node['resolvconf']['base']
  node['resolvconf']['base'].dup
else
  []
end

What do you think? (I've merged this PR, but didn't release it yet).

[robbwagoner]

@chr4 Why was this PR reverted?

[chr4]

It was not reverted, I just didn't release a new version (including this fix) yet. The reason is, that it breaks existing attribute configurations, see #20 (comment)

[robbwagoner]

@chr4 I see; I misread the reference to this in the revert commit 11c7bfd - apologies.