Allow specifying an alternate keyfile via attribute definition.

[wamcvey]

The original provider required that the encrypted certificate data_bag be encrypted with the default secret key. This pull requests adds the ability to specify an alternate keyfile to use to encrypt/decrypt the data_bag by setting an override attribute in a role file similar to:

override_attributes(
   "certificate" => {
         "secret_keyfile" => "/etc/chef/certificate_databag_keyfile"
   }
)

[atomic-penguin]

I am not opposed to the idea of specifying an alternate file. However, I think this should use a default value in the resources file. I don't particularly like the idea of using Chef attributes in providers, and am not certain it will actually work as you intended. Are you sure that Chef attributes actually exist when the LWRP provider is evaluated?

This will no longer merge, as the provider was refactored. Closing this issue as won't fix, since it will not merge. Please open a new pull request. I'll update the changelog at release time, I would prefer if you just give me a good commit message.

[atomic-penguin]

Apparently tied to the issue, mmkay :/

[wamcvey]

Well, the attribute is set during the evaluation of the provider, as this fork is in use in my environment and the right keyfile is being used to unlock the encrypted databag. I'm not particularly tied to the keyfile being specified via attribute. It could certainly be a parameter to the lwrp. I'm fairly new to chef as well as to ruby, so I'll have a bit more reading to do to learn the inner details of developing LWRPs and figuring out what it takes to to add it as a resource parameter.

[atomic-penguin]

Found the page which illustrates this concept, if you want to read up on it. It is the Anatomy of a Chef Run.

In this diagram it shows the order which Chef loads its resources. As far as I know, node attributes have not been loaded when your LWRP is evaluated in the Compile Resources phase.