[chef] Re: Object-Oriented Chef

[Ranjib Dey < >]

right, and thats what makes chef very compelling. Those who wanted similar use cases, have done it. Here are a few more examples[1], [2]. But the recipe DSL layer not only makes thing concise, it also eases adopting, implementing things with chef if you are new. For those who are coming form cfengine or puppet, i think its easier than groking raw ruby. I also think from a standard CM style execution (i.e building a set of resources and then check & repair cycle) recipe makes a lot of sense, since that are the authoritative sources for resource declaration. Also, this makes up what we call cookbook, which is recipe+ artifacts required for recipe execution that can be shared as independent. Chef community is built around that. The cookbook route also allows segments (files, templates etc).. which are then exploited by recipes/resources. In your example you have not used ohai yet,, for any non-trivial work, you'll node ohai data as well.. recipe/dsl layer takes care of all those things.


i think, chef already have a decent design for raw consumption (i.e. use chef from any ruby apps). We dont have the necessary docs or blogs around it. Also a better understanding of Chef's public API (so that version compatibility can be maintained ). But let us know exactly what you are looking for and we can tell you the core chef api.

i 'll also say that theres nothing inherent in the chef DSL layer that restrict you from using raw ruby library modules etc.. we can take an example and explore that may be..

[1]https://github.com/ranjib/chef-stage
[2]https://github.com/ranjib/chef-lxc/blob/master/lib/chef/lxc_helper.rb

On Wed, Sep 16, 2015 at 3:44 PM, Jos Backus < " target="_blank"> > wrote:

Hi,

It would be nice if there was better support for the native Ruby Chef classes/methods aside from the Chef::Recipe DSL with its fixed structure of cookbooks/recipes, etc. It seems to me that with access to the run_context class and the various resources, one could implement multiple run/convergence queues easily enough (by instantiating different run_contexts and operating on them), for example, and it would also open up the ability to use traditional classes/modules for adding structure and reusability, rather than the limited Chef::Recipe API. I understand that the current DSL is concise, convenient for beginners and mimics what Puppet uses, but it lacks structural power.

Thoughts?

Jos