Chef-client dependency requirements of cookbooks?

Chef Infra (archive)
1

Hi,

given the changes with each major chef release, would it make sense to add a metadata to cookbooks to define/limited the supported chef versions?

https://docs.chef.io/config_rb_metadata.html https://docs.chef.io/config_rb_metadata.html

Let’s say you have a cookbook that provides audit mode recipes, or using„sensitive“ attribute for file resources, or the recently introduced reboot resource. To some degree it’s okay to check each supported feature at run time and react accordingly, however some people are using really, really, really old setups nobody want’s to support anymore. E.g. 0.9.x and chef 10.

As a cookbook author I would prefer a explicitly exiting chef-client or "knife upload“ run, instead of some „silent working“ condition.

What do you think?

best regards
Roland

PS: One could argue if the same also applies to „ohai“.

2

Hey Roland,

We’ve got an accepted RFC (#37) to support just that use case. https://github.com/chef/chef-rfc/blob/332fe417d28995a9a696af24e0e27c173e255fff/rfc037-chef-ohai-version-metadata.md

I don’t know if there has been any progress on that front off hand, but I for one am eager to see that develop.

Steve

Steven Murawski
Community Software Development Engineer @ Chef
Microsoft MVP - PowerShell
http://stevenmurawski.com [http://stevenmurawski.com/]
On 7/2/2015 1:46:44 PM, Roland Moriz rmoriz@gmail.com wrote:
Hi,

given the changes with each major chef release, would it make sense to add a metadata to cookbooks to define/limited the supported chef versions?

https://docs.chef.io/config_rb_metadata.html [https://docs.chef.io/config_rb_metadata.html]

Let’s say you have a cookbook that provides audit mode recipes, or using„sensitive“ attribute for file resources, or the recently introduced reboot resource. To some degree it’s okay to check each supported feature at run time and react accordingly, however some people are using really, really, really old setups nobody want’s to support anymore. E.g. 0.9.x and chef 10.

As a cookbook author I would prefer a explicitly exiting chef-client or "knife upload“ run, instead of some „silent working“ condition.

What do you think?

best regards
Roland

PS: One could argue if the same also applies to „ohai“.

3

Hi Steven,

Am 02.07.2015 um 22:17 schrieb Steven Murawski steven.murawski@gmail.com:

Hey Roland,

We've got an accepted RFC (#37) to support just that use case. https://github.com/chef/chef-rfc/blob/332fe417d28995a9a696af24e0e27c173e255fff/rfc037-chef-ohai-version-metadata.md

I don't know if there has been any progress on that front off hand, but I for one am eager to see that develop.

ah - thanks!

I’ve scanned the rfc filenames before writing the mail but was probably too tired to see this one, sorry :-/

regards
Roland

Steve

Steven Murawski
Community Software Development Engineer @ Chef
Microsoft MVP - PowerShell
http://stevenmurawski.com http://stevenmurawski.com/On 7/2/2015 1:46:44 PM, Roland Moriz rmoriz@gmail.com wrote:

Hi,

given the changes with each major chef release, would it make sense to add a metadata to cookbooks to define/limited the supported chef versions?

https://docs.chef.io/config_rb_metadata.html https://docs.chef.io/config_rb_metadata.html

Let’s say you have a cookbook that provides audit mode recipes, or using„sensitive“ attribute for file resources, or the recently introduced reboot resource. To some degree it’s okay to check each supported feature at run time and react accordingly, however some people are using really, really, really old setups nobody want’s to support anymore. E.g. 0.9.x and chef 10.

As a cookbook author I would prefer a explicitly exiting chef-client or "knife upload“ run, instead of some „silent working“ condition.

What do you think?

best regards
Roland

PS: One could argue if the same also applies to „ohai“.