Berkshelf and metadata version constraints

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: ‘git@github.com: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: ‘git@github.com:evertrue/et_monitoring-cookbook.git’ with branch: ‘v1.1.0’ at ref: ‘cc0924a4fe6959d0f0439a44b7f1af1318604ab4’

[Berkshelf] Installing et_monitoring (1.1.0) from git: ‘git@github.com: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

Hi Eric,

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

I'm +1 for this :slight_smile:

Cheers,
Torben

On Fri, Jan 17, 2014 at 11:05 PM, Eric Herot eric.opscode@herot.com 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: 'git@github.com: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: 'git@github.com:evertrue/et_monitoring-cookbook.git'
with branch: 'v1.1.0' at ref: 'cc0924a4fe6959d0f0439a44b7f1af1318604ab4'

[Berkshelf] Installing et_monitoring (1.1.0) from git: 'git@github.com: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

Hi Eric,
I think it is not a Berkshelf issue, but it is the way chef solo works.
Because there is not a chef server, there is not cookbook’s version
contraints check. This is one of the reasons we are moving to chef zero
indeed.
Berkshelf is doing exactly what you are asking to it: to download that
specific version of cookbooks. And chef solo is doing what it is able to
do: load the cookbooks it finds with that name, with no possibility to do
checks on metadata version constraints.
This is what I’ve understood since now, maybe that I’m wrong, in this case
there are a lot of awsome chefs far more expert than me in this ml that can
correct me.
Cheers,
Marco
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:
‘git@github.com: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:
'git@github.com:evertrue/et_monitoring-cookbook.git’
with branch: ‘v1.1.0’ at ref: ‘cc0924a4fe6959d0f0439a44b7f1af1318604ab4’

[Berkshelf] Installing et_monitoring (1.1.0) from git:
'git@github.com: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