[chef] Re: Berkshelf and metadata version constraints

[Torben Knerr < >]

Hi Eric,

afaik there is indeed no consistency check in this situation. You should raise an issue here:

https://github.com/RiotGames/berkshelf/issues

I'm +1 for this :-)

Cheers, 

Torben

On Fri, Jan 17, 2014 at 11:05 PM, Eric Herot < " target="_blank"> > wrote:

Hi Chefs,

I couldn't quite figure out how to Google this problem so I thought this was the next best place.

So I have a metadata.rb version constraint like so:

  depends 'et_monitoring', '= 1.5.1'

and I have a Berkshelf file wit a tag constraint like so (bear with me here):

  cookbook 'et_monitoring', git: ' :evertrue/et_monitoring-cookbook.git', tag: 'v1.1.0'

As you might imagine, the version of the et_monitoring cookbook tagged as v1.1.0 also has that as its metadata version.  So here's what's weird: When I run "berks update && vagrant provision", the version that gets uploaded (as you might imagine), is the one defined by the Berksfile tag, like so:

$ berks update && vagrant provision

…

Installing et_monitoring (1.1.0) from git: ' :evertrue/et_monitoring-cookbook.git' with branch: 'v1.1.0' at ref: 'cc0924a4fe6959d0f0439a44b7f1af1318604ab4'

…

[Berkshelf] Installing et_monitoring (1.1.0) from git: ' :evertrue/et_monitoring-cookbook.git' with branch: 'master' at ref: 'cc0924a4fe6959d0f0439a44b7f1af1318604ab4'

…

blah blah blah Vagrant continues on its merry way until it encounters the reason that et_monitoring v1.1.0 was deprecated in the first place and errors out (thus demonstrating that it is in fact running v1.1.0 of the cookbook).

So my question is, why does this not cause an unresolvable versions error?  This is making our testing environment a bit unpredictable.

Am I just misunderstanding how the version constraint system works, or is this a bug?

You guys are awesome

Eric