[chef] Re: Re: Re: Object-Oriented Chef

[Ranjib Dey < >]

inline responses

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

Hi Ranjib,

Noah helpfully pointed me to Halite which seems exactly what I am after.

awesome

You make good points about the DSL easing adoption and making the tool friendly for non-Rubyists. My objection to cookbooks is chiefly that we already have gems and classes/modules, and cookbooks and recipes are very limited compared to those other structures.

yes. but as i said, cookbooks are different due to static contents & segment (gems have only ruby files and executables)

In fact, when starting out with Chef a couple of months ago, I was very surprised to find that cookbooks could not nest arbitrarily.

yeah, .. there are several limitations.. all they just dont have all the joys of pure gems. use libraries to bridge.

I’d expect Ohai integration in a pure Ruby Chef environment not to be much of a problem - surely an API such as ohai.data[‘foo’] would be sufficient?

 

its per easy,,, o = Ohai::System.new. o.run_plugins. chef injects this data inside node object during startup, which appears as automatic attributes.

Your LXCHelper example is tantalizingly close and shows most of the plumbing I’d expect to be there, but instead of the instance_eval, there would just be a bunch of method calls to classes that push resources on some resource collection associated with a run_context, as Noah suggested.

right. i prefer instance eval, for the same reason we instance_eval on recipe.

I personally would appreciate more documentation of this use case of Chef, for people that are comfortable with Ruby and feel limited by the current cookbook/recipe paradigm (“What do you mean, recipes can’t take parameters?”).

to me attributes are recipe parameters.

Im sorry you feel limited, lets see if we can make this betters.

I think of chef as a generic infrastructure library in ruby. knife being the CLI front end, client being the implementation of CM pattern, chef server being a metadata source. Now, unless you need CM, you dont need the client bits, use the subsystem. In past we have two question on the same line. First, what about a completely serializable DSL (i dont know if you can call that dsl), like yaml or json. Second, what if we have an explicit DSL, i.e. instead of instance_eval, we implement a class or something similar. To me both of this two are two extremes. First one reduces composability (u are bound by the platform), while second on allow some composition but not with some quirks (certain things dont work :-)), which albeit is annoying from pure ruby perspective. But remember theres nothing in Chef that prevent you from doing what you want. i,e. you can you cookbook syncer to grab things, and then build node, construct run list, execute it.

i dont which one is best (serializable files, implicit DSL of current chef, or explicit DSL, the one you are talking about). i'll be very interested to know others opinion. I see there are limited perf benefits, and a lot of ease for pure ruby devs. But  lot bigger learning curve for non-rubyist, and also a lot more verbosity. Unless your resource list is lot smaller than your all other logic (which is rarely the case, in my experience) explicit dsl will be pretty verbose.

it will be nice if you specify an use case instead, and we compare how you could have implemented it if explicit DSL was there, and then we share how currently we can do this. we can compare its lot easier that way

Thanks for your feedback and suggestions!

Jos

From: Ranjib Dey
Reply-To: " " target="_blank"> "
Date: Wednesday, September 16, 2015 at 4:30 PM
To: " " target="_blank"> "
Subject: [chef] Re: Object-Oriented Chef

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