[chef] Re: Re: Re: Re: release 0.9.12 does not include [CHEF-1423] - Support versions of recipes on the run list

[Ringo De Smet < >]

Joshua,

On 11 January 2011 15:56, Joshua Timberman 
<
 >
 wrote:
>
> I think this might be covered by environment run lists in 0.10 roles. The 
> cookbook version constraints will be used in environments themselves.

While environments are definitely a good thing, the way you explain it
below makes me frown...

Back to basics (from the wiki):
- Cookbooks: "Cookbooks are the fundamental units of distribution in
Chef. They encapsulate all the resources you need to automate your
infrastructure and are easily sharable with other Chef users."
- Roles: "Roles in Chef provide a mechanism for easily composing sets
of functionality for each of your nodes through recipes and
attributes."

If I take a similar example in software engineering: product and
library. A naive definition of the product could be that it is build
out of a set of libraries. But a product evolves, so "product v1" uses
"libA v1" and "libB v1" while "product v2" could use "libA v1.1" and
"libB v1.2". Usually, the place where you enlist your libraries also
contains a version specification (e.g. Gemfile)

What you highlight below is that the role lists the cookbooks, but the
cookbook version(s) are defined in the environment.

> % cat environments/production.rb
> name "production"
> cookbook_versions(
>  "apache" => "1.0"
> )
>
> % cat environments/development.rb
> name "development"
> cookbook_versions(
>  "apache" => "1.5"
> )
>

Does this mean that I can only have a single version of a cookbook
active in an environment? How do you support zero-downtime upgrade
using the scenario of adding nodes in the new configuration and then
stopping the nodes with the old configuration?

> All the cookbooks would be versioned, and then you can pin a particular 
> version to an environment. If you wanted to test a new deployment in a 
> particular environment, for example swapping out apache for nginx in 
> development:
>
> % cat roles/webserver.rb
> name "webserver"
> env_run_lists(
>  "production" => ["recipe[apache]"],
>  "development" => ["recipe[nginx]"]
> )

In my proposed setup, I would have the mapping (ignore the syntax
details, you probably get the message):

production env -> role["webserver = 1.0"] -> recipe["apache = 1.0"]
development env -> role["webserver = 1.5"] -> recipe["apache = 2.0"]

Having versioned roles can then also be committed to source control.
Would you commit your environment config to source control? I see
environments more as transient "objects".

This looks like good teaching material for the Advanced Course in a
few weeks, no? :-)

Ringo