[chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Berkshelf Frustrations, or, Am I Just Doing It Wrong?


Chronological Thread 
  • From: Jamie Winsor < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Berkshelf Frustrations, or, Am I Just Doing It Wrong?
  • Date: Fri, 29 Mar 2013 12:07:20 -0700

Nick,

Berkshelf isn't just for uploading and downloading your cookbooks. While these are two features that you are currently using it for, Berkshelf is a source code management tool that provides software engineers with the tools they need to:
  • Generate new cookbooks
  • Create virtual environments to test convergence
  • Package cookbooks
  • Distribute cookbooks
  • Download/Retrieve cookbooks and their dependencies
It doesn't manage the environments on your Chef server, though. You still should control what cookbooks are present on your environments by locking the top level dependencies.

-- 
Jamie Winsor
@resetexistence
https://github.com/reset

On Friday, March 29, 2013 at 11:42 AM, Brian Akins wrote:

In the actual chef orgs, it really just a convenience for downloading cookbooks from our cookbook org and uploading them to a particular chef server/org. We could just write a tool to do this, I suppose, but we already use berkshelf with Vagrant for testing, etc already. When building/updating out TLC's we can use berkshelf to generate the list of exact versions we depend on.  If Berksfile.lock worked as intended, then we wouldn't have to do this I suppose.


On Fri, Mar 29, 2013 at 1:50 PM, nick hatch < " target="_blank"> > wrote:
Maybe I'm just being dense -- but what value does Berkshelf provide if you explicitly pin versions in this manner? 

-n


On Thu, Mar 28, 2013 at 1:57 PM, Jamie Winsor < " target="_blank"> > wrote:
> Michael's explanation is 100% in line with how we handle things here at Riot
>
> --
> Jamie Winsor
> @resetexistence
> https://github.com/reset
>
> On Thursday, March 28, 2013 at 1:07 PM, Michael Glenney wrote:
>
> We pin versions in the top level cookbooks.  We also restrict versions in
> our environment files but it's always a =< so if an older cookbook is
> relying on an older version of something the environment file doesn't get in
> the way.
>
> In the metadata of top level cookbooks we're strict:  depends "java", "=
> 1.0.0"
> and we list out even cookbooks that aren't called directly by the TLC, that
> are dependencies of others, just to make sure everything is pinned.
>
> In the non-TLC's we're more relaxed:  depends "java", "~> 1.0.0"
> which makes development and testing a little more bearable.
>
> MG
>





Archive powered by MHonArc 2.6.16.

§