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

[Jos Backus < >]

Correct, it's an organization limitation. While I understand it's on purpose, I still think its arbitrary - they are not really cookbooks, etc.

You are right about the java cookbook being poorly structured. And this is a recurring issue that I have with supermarket cookbooks. My guess is this is because the bar the DSL offers is so low. I agree that monkey-patching is generally undesirable.

Cheers,
Jos

-------- Original Message --------
From: Tensibai < >
Date: Fri, Sep 18, 2015, 1:07 AM
To:
Subject: [chef] Re: Re: Re: Re: Re: Object-Oriented Chef

Sorry, I misunderstood what you mean in this case (and still don't see exactly the use case for it, just organizing recipes ?)

Regarding your use case with two java version I assume the way to go would be to move the recipe into a LWRP and call the LWRP with corresponding attributes twice in a wrapper cookbook. (You may even do a PR for this)

This sounds less likely to break in future than monkey patching the DSL in my opinion.

 

In Ruby code it's common to nest directories. E.g.

 

require 'chef/mixin/params_validate'

 

You can't do the same with cookbooks, they have a fixed structure. My argument has nothing to do with resource convergence.

 

Thanks for your comment!

 

 

From: Tensibai
Reply-To: " "> "
Date: Thursday, September 17, 2015 at 1:11 AM
To: " "> "
Subject: [chef] Re: Re: Re: Object-Oriented Chef

 

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

Usually when I ear that, I've the reaction "You're doing it wrong".

If you need arbitrary nesting of cookbooks, than you're not anymore describing a state but the steps to get to this state.

If you use Chef to replace scripts and run it only on-demand I see why you're looking for this, but IMHO you're using the wrong tool in this case as Chef is aimed to be run periodically to enforce a state, so you should avoid nested steps.

There's some case where a "dual run" is needed as you can't do the whole state in one pass, in this case my usual way is to set a tag on node on the first pass, skip what has to be skipped on the first pass when the tag is absent, and use a execute resource to schedule the next run in 1 min or more, depending on the use case.

I do this to provision mysql clusters, I can't tell who the replication partner will be before it's up, so I schedule a new chef run every 2 mins until the partner is found in search and the initial replication is done.

This leave unused code in the long term run for those boxes, but it's better than looping within the run waiting the other box to get in (which may never be true if your vagrant driver provision sequentially as the vSphere plugin did before 1.0.2 for example)

This was my $.2 on the subject :)