Release 0.9.12 does not include - Support versions of recipes on the run list

Chef Infra (archive)
1

I installed chef 0.9.12 for testing usage of cookbook version in run list but it does include that support

E.g. I specified in one role the following run_list

run_list [
“recipe[accounts::service_account,0.0.0]”,
“recipe[accounts::user_account,0.0.0]”,
“recipe[accounts::ssh_keys,0.0.0]”
]

But get an error when running chef-client

/usr/lib/ruby/gems/1.8/gems/chef-0.9.12/bin/…/lib/chef/cookbook_version.rb:461:in load_recipe': Cannot find a recipe matching service_account,0.0.0 in cookbook accounts (ArgumentError) from /usr/lib/ruby/gems/1.8/gems/chef-0.9.12/bin/../lib/chef/mixin/language_include_recipe.rb:40:ininclude_recipe’
from /usr/lib/ruby/gems/1.8/gems/chef-0.9.12/bin/…/lib/chef/mixin/language_include_recipe.rb:27:in each' from /usr/lib/ruby/gems/1.8/gems/chef-0.9.12/bin/../lib/chef/mixin/language_include_recipe.rb:27:ininclude_recipe’
from /usr/lib/ruby/gems/1.8/gems/chef-0.9.12/bin/…/lib/chef/run_context.rb:94:in load' from /usr/lib/ruby/gems/1.8/gems/chef-0.9.12/bin/../lib/chef/run_context.rb:91:ineach’
from /usr/lib/ruby/gems/1.8/gems/chef-0.9.12/bin/…/lib/chef/run_context.rb:91:in load' from /usr/lib/ruby/gems/1.8/gems/chef-0.9.12/bin/../lib/chef/run_context.rb:55:ininitialize’
from /usr/lib/ruby/gems/1.8/gems/chef-0.9.12/bin/…/lib/chef/client.rb:166:in new' from /usr/lib/ruby/gems/1.8/gems/chef-0.9.12/bin/../lib/chef/client.rb:166:inrun’
from /usr/lib/ruby/gems/1.8/gems/chef-0.9.12/bin/…/lib/chef/application/client.rb:222:in run_application' from /usr/lib/ruby/gems/1.8/gems/chef-0.9.12/bin/../lib/chef/application/client.rb:212:inloop’
from /usr/lib/ruby/gems/1.8/gems/chef-0.9.12/bin/…/lib/chef/application/client.rb:212:in run_application' from /usr/lib/ruby/gems/1.8/gems/chef-0.9.12/bin/../lib/chef/application.rb:62:inrun’
from /usr/lib/ruby/gems/1.8/gems/chef-0.9.12/bin/chef-client:26
from /usr/bin/chef-client:19:in `load’
from /usr/bin/chef-client:19

I look at source and found nothing related to pach indicated in [CHEF-1423]

Huy Le
Tecnología ING DIRECT
Administrador de sistema
Tel: +34 91 206 76 85

Por favor, no imprima este correo si no es necesario.

Attention:
The information contained in this message and or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please contact the sender and
delete the material from any system and destroy any copies.

2

Hi,

On Mon, Dec 27, 2010 at 6:23 AM, le.huy@ingdirect.es wrote:

I installed chef 0.9.12 for testing usage of cookbook version in run
list but it does include that support

Although the CHEF-1423 ticket was tagged for the 0.9.12 release, it
did not make it into the release. A good way to get an overview of
what did make it into a particular release is to look at the release
notes:

http://wiki.opscode.com/display/chef/Release+Notes

In the meantime, we have been working on integrating cookbook version
constraint logic into Chef and making the syntax for specifying
version constraints more consistent. What has been implemented on the
master branch is described here:

http://wiki.opscode.com/display/chef/Cookbook+Version+Constraints

E.g. I specified in one role the following run_list

run_list [
"recipe[accounts::service_account,0.0.0]",
"recipe[accounts::user_account,0.0.0]",
"recipe[accounts::ssh_keys,0.0.0]"
]

The syntax changed from the original ticket; to peg a cookbook version
in a run list item, use '@':

"recipe[accounts::user_account@0.0.0]"

I look at source and found nothing related to pach indicated in
[CHEF-1423]

If you are willing and able to run some tests against master, you
should be able to test the feature and we would be interested in any
feedback you have.

We are hoping to include this work in the next minor release of Chef (0.10.0),
but what is and is not in the release is not yet written in stone.

  • seth
3

Seth,

On 28 December 2010 20:21, Seth Falcon seth@opscode.com wrote:

In the meantime, we have been working on integrating cookbook version
constraint logic into Chef and making the syntax for specifying
version constraints more consistent. What has been implemented on the
master branch is described here:

http://wiki.opscode.com/display/chef/Cookbook+Version+Constraints

Have you also been thinking of versioning roles? I think this would
come in handy to evolve your setups.

The role "webserver" today could be totally different tomorrow, so
being able to link webserver@1.0 to @1.0 and webserver@2.0
to @2.0 makes sense to me.

Ringo

4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ohai!

On Jan 11, 2011, at 2:33 AM, Ringo De Smet wrote:

Have you also been thinking of versioning roles? I think this would
come in handy to evolve your setups.

The role "webserver" today could be totally different tomorrow, so
being able to link webserver@1.0 to @1.0 and webserver@2.0
to @2.0 makes sense to me.

I think this might be covered by environment run lists in 0.10 roles. The cookbook version constraints will be used in environments themselves.

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

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

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]"]
)

Opscode, Inc
Joshua Timberman, Technical Evangelist
IRC, Skype, Twitter, Github: jtimberman

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)

iEYEARECAAYFAk0sb5AACgkQO97WSdVpzT2V7ACfRQqxuPPruVShibHTWMyL1uiZ
i/8AoI0VUDE/HiWXNBFzeWMS1zNwdPl4
=S1SU
-----END PGP SIGNATURE-----

5

Joshua,

On 11 January 2011 15:56, Joshua Timberman joshua@opscode.com 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? :slight_smile:

Ringo