cookbook_versions in environments

[rmoriz]

I ran into an issue which I don't fully understand:

setup:

• 2+ environments
• hard version constraint of a dependency cookbook

$ knife environment compare                   
                     production  rollout  staging
windows              latest      = 3.1.1  latest 

However the node resolves to the latest version (3.1.2 in this case):

$ chef-client -E rollout
...
  - windows (3.1.2)
  - yum-epel (2.1.2)
  - zap (0.15.1)
  - zypper (0.4.0)
…

Using knife download cookbook windows -E rollout i'm also getting the 3.1.2 release instead of the expected 3.1.1 release. That said, knife download cookbook windows --cookbook-version 3.1.1 works as expected. 😕

[ctdk]

I'm checking this out now, after adding options for purging statuses and reports per that earlier issue. It's in the 0.11.6-merging branch, so if you get a chance to try it out that'd be great - I have more testing to do on it still, so it's not release worthy yet, but for the first step it passes the go tests.

[ctdk]

Moving along on this. One thing I noticed, though, is that it doesn't look like knife cookbook download obeys environment constraints, so that's behaving as intended at least. The first thing is still a problem though, although it's one of those things that chef-pedant tests for and it passes that fine. I'll dig in, but I suspect there's a subtle interaction between two cookbooks. (I've certainly had goiardi do the right thing with environment constraints plenty of times.)

[e1ven]

I believe I ran into this as well-

It appears that goiardi will respect environment version constraints for any cookbooks that are specified in the run-list, but not their dependencies.

When I run chef-client, goiardi will pull in cookbooks with the locked versions as expected, and it will pull in any cookbooks which are specified as dependencies in metadata.rb.

When retrieving these dependencies, any version constaints specified in metadata.rb are respected.
Goiardi does not apply the environment constraints against these dependency cookbooks, however.
This is different from the Progress Software chef-server implementation, which will respect these dependencies.

So for example, if we have-

• Environment X, specifying constraints

  • cookbook1, '~> 1.0'
  • cookbook2, '~> 2.0'

• A run-list of ["recipe[cookbook1]"]

• cookbook1 (available in versions 1.0, 2.0, 3.0)

  • depends on cookbook2

• cookbook2 (available in version 1.0, 2.0, 3.0)

Running chef-client/cinc-client against goiardi will pull cookbook1 1.0 and cookbook2 3.0
Running chef-client/cinc-client against chef-server will pull cookbook1 1.0 and cookbook2 2.0

I'm not particularly familiar with this codebase, but it appears that we need to add these env constraints later in cookbook.go, when evaluating these cookbook dependencies.

I couldn't get the master branch to work quite right, so I made my own temporary fork of 0.11.10 with my implementation of this change. This change works for me in production.
Hopefully this help illustrate the problem better, even if it's not the right solution :)
https://github.com/e1ven/goiardi/pull/1/files
(The SQL index changes in the PR are unrelated -
These indexes were never accessed on my server, but it slowed the DB down substantially to keep writing them)