[chef] Re: Re: Re: An deep topic


Chronological Thread 
  • From: Jeff Blaine < >
  • To:
  • Subject: [chef] Re: Re: Re: An deep topic
  • Date: Tue, 08 Jul 2014 19:46:09 -0400

On 7/8/2014 1:09 AM, John E. Vincent (lusis) wrote:
> Julian,
> 
> Thanks for taking the time to respond and also thanks for the feedback
> on the twitters. More inline.
> 
>     Do I believe that we ingested too much? Yes, the #1 pain point people
>     had with Chef was client-side dependency resolution. We grabbed
>     Berkshelf, the first thing that was convenient & met the need. But we
>     also got a lot of things that are kind of superfluous to the goal. The
>     "Berkshelf Way", "Environment Cookbooks", and friends all have little
>     to do with that, and will not be used by most people. (Bring on the
>     flames?)
> 
> 
> I think this is accurate and communicates where I have a problem. All
> the things have been intermingled when all that was needed was a
> depsolver.

Enormous +1 from me. We've no interest in implementing the Berkshelf Way
and have no desire for Librarian or Berkshelf as they stand. The
benefits of a cookbook depsolver are obvious, and I completely
understand how the tooling needs to mature via things like that, but
we've never had a real need for even that.

>     Client-side dependency resolution is what it solves, in other words,
>     the need to get into dependency downloading hell ("knife cookbook
>     download xyz", oh noes, "xyz" depends on these other 3 cookbooks that
>     depend on 2 other ones that depend on...)
> 
> 
> I guess this was where I didn't have a problem. My deps always resolved
> fine with "knife cookbook site vendor" and I never had a problem. I look
> now and see that maybe I was stuck in some old deprecated way but muscle
> memory is a thing. But it always did what I wanted ;)

Exactly. Get out of my brain.

-- 
Jeff Blaine
kickflop.net
PGP/GnuPG Key ID: 0x0C8EDD02



Archive powered by MHonArc 2.6.16.

§