[chef] Re: Berkshelf Question: cookbook versioning in metadata vs. berksfile


Chronological Thread 
  • From: Ranjib Dey < >
  • To:
  • Subject: [chef] Re: Berkshelf Question: cookbook versioning in metadata vs. berksfile
  • Date: Thu, 13 Jun 2013 14:46:26 -0700

given you are freezing the version of bar from foo, any reason why you are controlling bar directly from Berkshelf? why not control foo from berkshelf and allow berkshelf to do the dependency resolution. that way berks upload should generate a berksfile.lock which should reflect the bar & its version freeze



On Thu, Jun 13, 2013 at 2:25 PM, Kevin Karwaski < " target="_blank"> > wrote:
Ohai Chefs,

We've been looking at implementing a Berkshelf based workflow within
my org and we've hit some challenges managing dependent cookbook
version constraints.

Basically, we'd like to bind the dependent cookbook version constraint
in the app cookbook's metadata and use chef_api in the Berkshelf file
to point to our chef server.

For example:

Cookbook 'Foo App' metadata.rb contains:
depends 'bar', '1.0.0'

Berksfile contains:
metadata
chef_api :config
site :opscode

cookbook 'bar'


However, the version constraint in the metadata file is not observed;
berks just fetches the latest version of the 'bar' cookbook on our
chef server.

Is there any way to force Berkshelf to respect the version constraint
in metadata? Am I missing something here? Maybe I'm not approaching
this the right way but any insight/feedback would be greatly
appreciated.

$ berks --version
Berkshelf (2.0.3)

Thanks!
-K.

--
Kevin Karwaski
Operations Engineer @ {Fiksu}




Archive powered by MHonArc 2.6.16.

§