How to get test-kitchen to work when cookbook is named "cookbook-x"

Chef Infra (archive)
1

Hi all,

I’m trying to get test-kitchen to work and am running into some issues
that I was hoping to get some help with.

In our organization git repo, we have all our Chef cookbooks in git
repos named “cookbook-X”, where X is a project we work on.

For example, we work on the OpenStack Nova project. We have a repo
called github.com:att-cloud/nova that houses our Nova code changes and a
repo called github.com:att-cloud/cookbook-nova that houses our cookbook
for Nova.

The above seems to me to be a very common developer scenario, but
apparently it’s not what many tools in the Chef ecosystem are hard-coded
to look for – namely ChefSpec and test-kitchen.

For ChefSpec, we get around the problem of ChefSpec not being able to
find the cookbook by doing this:

cd $cookbook
mkdir -p cookbooks
ln -s … cookbooks/$short_name

Where $short_name would be just “nova”.

This little hack allows ChefSpec to run properly.

Unfortunately, we can’t seem to figure out how to do the same thing with
test-kitchen.

If I run kitchen init && kitchen test in our cookbook-nova root dir,
things look like this:

http://paste.openstack.org/show/25829/

There are a number of Foodcritic failures like this:

FC007: Ensure recipe dependencies are reflected in cookbook metadata:
/home/jpipes/repos/att-cloud/cookbook-nova/recipes/api-ec2.rb:21

Which refer to an include_recipe that refers to a “nova::”

If I go into test/kitchen/Kitchenfile and change this line:

cookbook “cookbook-nova” do

to this:

cookbook “nova” do

I get more failures when running kitchen test:

http://paste.openstack.org/show/25830/

How do others get around this problem? I can’t imagine that our shop is
the only one that has developers working on projects and cookbooks that
have similar naming conventions… since you can’t have the code and the
cookbook repo named the same thing.

Any and all advice most appreciated,
-jay

2

Jay,

A quick fix might be to declare the "name:" attribute in your
cookbook's metadata.rb.

it's not a required field, and I've found that being explicit solves a
lot of the foodcritic-related rules on this.

-Mike Fiedler

On Tue, Nov 13, 2012 at 5:19 PM, Jay Pipes jaypipes@gmail.com wrote:

Hi all,

I'm trying to get test-kitchen to work and am running into some issues
that I was hoping to get some help with.

In our organization git repo, we have all our Chef cookbooks in git
repos named "cookbook-X", where X is a project we work on.

For example, we work on the OpenStack Nova project. We have a repo
called github.com:att-cloud/nova that houses our Nova code changes and a
repo called github.com:att-cloud/cookbook-nova that houses our cookbook
for Nova.

The above seems to me to be a very common developer scenario, but
apparently it's not what many tools in the Chef ecosystem are hard-coded
to look for -- namely ChefSpec and test-kitchen.

For ChefSpec, we get around the problem of ChefSpec not being able to
find the cookbook by doing this:

cd $cookbook
mkdir -p cookbooks
ln -s .. cookbooks/$short_name

Where $short_name would be just "nova".

This little hack allows ChefSpec to run properly.

Unfortunately, we can't seem to figure out how to do the same thing with
test-kitchen.

If I run kitchen init && kitchen test in our cookbook-nova root dir,
things look like this:

Paste #25829 | LodgeIt!

There are a number of Foodcritic failures like this:

FC007: Ensure recipe dependencies are reflected in cookbook metadata:
/home/jpipes/repos/att-cloud/cookbook-nova/recipes/api-ec2.rb:21

Which refer to an include_recipe that refers to a "nova::"

If I go into test/kitchen/Kitchenfile and change this line:

cookbook "cookbook-nova" do

to this:

cookbook "nova" do

I get more failures when running kitchen test:

Paste #25830 | LodgeIt!

How do others get around this problem? I can't imagine that our shop is
the only one that has developers working on projects and cookbooks that
have similar naming conventions... since you can't have the code and the
cookbook repo named the same thing.

Any and all advice most appreciated,
-jay

3

On 11/13/2012 05:36 PM, Mike wrote:

Jay,

A quick fix might be to declare the "name:" attribute in your
cookbook's metadata.rb.

it's not a required field, and I've found that being explicit solves a
lot of the foodcritic-related rules on this.

Thanks Mike! That indeed got rid of the FC007 errors.

I will continue to plod through the test-kitchen tutorials :slight_smile:

Again, thanks!
-jay

4

I usually just check it out with just the short name:

git clone …/cookbook-nova nova

Do you have a hard requirements that the local directory is named like the
repository?

On Tue, Nov 13, 2012 at 11:19 PM, Jay Pipes jaypipes@gmail.com wrote:

Hi all,

I'm trying to get test-kitchen to work and am running into some issues
that I was hoping to get some help with.

In our organization git repo, we have all our Chef cookbooks in git
repos named "cookbook-X", where X is a project we work on.

For example, we work on the OpenStack Nova project. We have a repo
called github.com:att-cloud/nova that houses our Nova code changes and a
repo called github.com:att-cloud/cookbook-nova that houses our cookbook
for Nova.

The above seems to me to be a very common developer scenario, but
apparently it's not what many tools in the Chef ecosystem are hard-coded
to look for -- namely ChefSpec and test-kitchen.

For ChefSpec, we get around the problem of ChefSpec not being able to
find the cookbook by doing this:

cd $cookbook
mkdir -p cookbooks
ln -s .. cookbooks/$short_name

Where $short_name would be just "nova".

This little hack allows ChefSpec to run properly.

Unfortunately, we can't seem to figure out how to do the same thing with
test-kitchen.

If I run kitchen init && kitchen test in our cookbook-nova root dir,
things look like this:

Paste #25829 | LodgeIt!

There are a number of Foodcritic failures like this:

FC007: Ensure recipe dependencies are reflected in cookbook metadata:
/home/jpipes/repos/att-cloud/cookbook-nova/recipes/api-ec2.rb:21

Which refer to an include_recipe that refers to a "nova::"

If I go into test/kitchen/Kitchenfile and change this line:

cookbook "cookbook-nova" do

to this:

cookbook "nova" do

I get more failures when running kitchen test:

Paste #25830 | LodgeIt!

How do others get around this problem? I can't imagine that our shop is
the only one that has developers working on projects and cookbooks that
have similar naming conventions... since you can't have the code and the
cookbook repo named the same thing.

Any and all advice most appreciated,
-jay

5

I have run across a couple of cases where this bit me or others. Should the name attribute be added to the boilerplate metadata.rb?

--
Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
jeffh@automatedlabs.com 206-853-5216
Skype: jeffhulten

On Nov 13, 2012, at 2:40 PM, Jay Pipes wrote:

On 11/13/2012 05:36 PM, Mike wrote:

Jay,

A quick fix might be to declare the "name:" attribute in your
cookbook's metadata.rb.

it's not a required field, and I've found that being explicit solves a
lot of the foodcritic-related rules on this.

Thanks Mike! That indeed got rid of the FC007 errors.

I will continue to plod through the test-kitchen tutorials :slight_smile:

Again, thanks!
-jay

6

Should the name attribute be added to the boilerplate metadata.rb?
My vote is "yes".

This especially has usefulness when I may have a cookbook named
"apache2" in my corp repo, and if I fork the
opscode-cookbooks/apache2, I pretty much have to rename the repo to
something sane, like 'opscode-apache2` or something like that.

I can then clone locally and call it whatever I like, like Andrea
mentioned he does, but then again, I may have a conflict.

Tools like librarian and berkshelf should be able to parse the name
attribute as well, and place things correctly - I haven't confirmed
any of that.

-M

On Tue, Nov 13, 2012 at 5:47 PM, Jeffrey Hulten jeffh@automatedlabs.com wrote:

I have run across a couple of cases where this bit me or others. Should the name attribute be added to the boilerplate metadata.rb?

--
Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
jeffh@automatedlabs.com 206-853-5216
Skype: jeffhulten

On Nov 13, 2012, at 2:40 PM, Jay Pipes wrote:

On 11/13/2012 05:36 PM, Mike wrote:

Jay,

A quick fix might be to declare the "name:" attribute in your
cookbook's metadata.rb.

it's not a required field, and I've found that being explicit solves a
lot of the foodcritic-related rules on this.

Thanks Mike! That indeed got rid of the FC007 errors.

I will continue to plod through the test-kitchen tutorials :slight_smile:

Again, thanks!
-jay

7

On 11/13/2012 05:41 PM, Andrea Campi wrote:

I usually just check it out with just the short name:

git clone …/cookbook-nova nova

Do you have a hard requirements that the local directory is named like
the repository?

Like I mentioned, we already have a project called "nova" in the repo,
so I suppose I'd have to change my local repo structure to something
like this:

/repos/cookbooks/nova
/repos/projects/nova

I just prefer to have all code in a single local repo dir.

Best,
-jay

On Tue, Nov 13, 2012 at 11:19 PM, Jay Pipes <jaypipes@gmail.com
mailto:jaypipes@gmail.com> wrote:

Hi all,

I'm trying to get test-kitchen to work and am running into some issues
that I was hoping to get some help with.

In our organization git repo, we have all our Chef cookbooks in git
repos named "cookbook-X", where X is a project we work on.

For example, we work on the OpenStack Nova project. We have a repo
called github.com:att-cloud/nova that houses our Nova code changes and a
repo called github.com:att-cloud/cookbook-nova that houses our cookbook
for Nova.

The above seems to me to be a very common developer scenario, but
apparently it's not what many tools in the Chef ecosystem are hard-coded
to look for -- namely ChefSpec and test-kitchen.

For ChefSpec, we get around the problem of ChefSpec not being able to
find the cookbook by doing this:

cd $cookbook
mkdir -p cookbooks
ln -s .. cookbooks/$short_name

Where $short_name would be just "nova".

This little hack allows ChefSpec to run properly.

Unfortunately, we can't seem to figure out how to do the same thing with
test-kitchen.

If I run kitchen init && kitchen test in our cookbook-nova root dir,
things look like this:

http://paste.openstack.org/show/25829/

There are a number of Foodcritic failures like this:

FC007: Ensure recipe dependencies are reflected in cookbook metadata:
/home/jpipes/repos/att-cloud/cookbook-nova/recipes/api-ec2.rb:21

Which refer to an include_recipe that refers to a "nova::<recipe>"

If I go into test/kitchen/Kitchenfile and change this line:

cookbook "cookbook-nova" do

to this:

cookbook "nova" do

I get more failures when running kitchen test:

http://paste.openstack.org/show/25830/

How do others get around this problem? I can't imagine that our shop is
the only one that has developers working on projects and cookbooks that
have similar naming conventions... since you can't have the code and the
cookbook repo named the same thing.

Any and all advice most appreciated,
-jay
8

On Tue, Nov 13, 2012 at 5:47 PM, Jeffrey Hulten jeffh@automatedlabs.com wrote:

I have run across a couple of cases where this bit me or others. Should the name attribute be added to the boilerplate metadata.rb?

Patch already provided here awaiting review:
http://tickets.opscode.com/browse/CHEF-3562

There's an issue open that asks if name should be a required
attribute: http://tickets.opscode.com/browse/CHEF-3490

And yet another ticket to make name be the name of the cookbook rather
than the directory: http://tickets.opscode.com/browse/CHEF-3307

Bryan

9

Yes, I've faced this when using Berkshelf n Berkshelf restricts to have the name.

Librarian is liberal.

@millisami
~ Sachin Sagar Rai
Ruby on Rails Developer
http://tfm.com.np
http://nepalonrails.com (http://nepalonrails.tumblr.com)
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Thursday, November 15, 2012 at 1:16 AM, Bryan McLellan wrote:

On Tue, Nov 13, 2012 at 5:47 PM, Jeffrey Hulten <jeffh@automatedlabs.com (mailto:jeffh@automatedlabs.com)> wrote:

I have run across a couple of cases where this bit me or others. Should the name attribute be added to the boilerplate metadata.rb?

Patch already provided here awaiting review:
http://tickets.opscode.com/browse/CHEF-3562

There's an issue open that asks if name should be a required
attribute: http://tickets.opscode.com/browse/CHEF-3490

And yet another ticket to make name be the name of the cookbook rather
than the directory: http://tickets.opscode.com/browse/CHEF-3307

Bryan

10

On Thu, Nov 15, 2012 at 6:31 AM, Bryan McLellan btm@loftninjas.org wrote:

On Tue, Nov 13, 2012 at 5:47 PM, Jeffrey Hulten jeffh@automatedlabs.com wrote:

I have run across a couple of cases where this bit me or others. Should the name attribute be added to the boilerplate metadata.rb?

Patch already provided here awaiting review:
http://tickets.opscode.com/browse/CHEF-3562

There's an issue open that asks if name should be a required
attribute: http://tickets.opscode.com/browse/CHEF-3490

And yet another ticket to make name be the name of the cookbook rather
than the directory: http://tickets.opscode.com/browse/CHEF-3307

Assume dependency resolution is handled by separate tools (Librarian,
Berkshelf, etc.)
There are two types of names:
a) what is the name of this cookbook (some have the convention of the
folder or repo name), e.g. chef-ant or cookbook-ant, etc.
b) What is the name of this cookbook when someone is trying to
satisfy the depends in another cookbook, e.g ant

It seems sensible to leave the the current name as optional with
meaning unchanged, and introduce depends_name (as a requirement?)
Where depends_name is the name of this cookbook when someone tries
to satisfy a depends requirement stated in another cookbook.

So you could have metadata.rb:

name chef-ant
depends_name ant

I'm only part way through writing a Librarian-chef source so I leave
it to more experienced hands to comment authoritatively, but so far it
seems that this is a useful addition that reflects the fact that
dependency resolution is often handled by tools that need to know
'what should other cookbooks know this cookbook as', yet are dealing
with source repo's and archives that have idiosyncratic naming
conventions.

Hopefully that makes sense.

Regards
Mark

Bryan

11

Mark,

That is similar to the "replaces" method in the cookbook metadata.

Librarian-chef does not currently support dependency replacements, but
there's no reason it couldn't in the future.

Cheers,
Jay

On Thu, Nov 15, 2012 at 9:00 PM, Mark Van De Vyver mark@taqtiqa.com wrote:

On Thu, Nov 15, 2012 at 6:31 AM, Bryan McLellan btm@loftninjas.org
wrote:

On Tue, Nov 13, 2012 at 5:47 PM, Jeffrey Hulten jeffh@automatedlabs.com
wrote:

I have run across a couple of cases where this bit me or others. Should
the name attribute be added to the boilerplate metadata.rb?

Patch already provided here awaiting review:
http://tickets.opscode.com/browse/CHEF-3562

There's an issue open that asks if name should be a required
attribute: http://tickets.opscode.com/browse/CHEF-3490

And yet another ticket to make name be the name of the cookbook rather
than the directory: http://tickets.opscode.com/browse/CHEF-3307

Assume dependency resolution is handled by separate tools (Librarian,
Berkshelf, etc.)
There are two types of names:
a) what is the name of this cookbook (some have the convention of the
folder or repo name), e.g. chef-ant or cookbook-ant, etc.
b) What is the name of this cookbook when someone is trying to
satisfy the depends in another cookbook, e.g ant

It seems sensible to leave the the current name as optional with
meaning unchanged, and introduce depends_name (as a requirement?)
Where depends_name is the name of this cookbook when someone tries
to satisfy a depends requirement stated in another cookbook.

So you could have metadata.rb:

name chef-ant
depends_name ant

I'm only part way through writing a Librarian-chef source so I leave
it to more experienced hands to comment authoritatively, but so far it
seems that this is a useful addition that reflects the fact that
dependency resolution is often handled by tools that need to know
'what should other cookbooks know this cookbook as', yet are dealing
with source repo's and archives that have idiosyncratic naming
conventions.

Hopefully that makes sense.

Regards
Mark

Bryan

12

On Fri, Nov 16, 2012 at 1:23 PM, Jay Feldblum y_feldblum@yahoo.com wrote:

Mark,

That is similar to the "replaces" method in the cookbook metadata.

Good point. From what I know of librarian-chef it seems a required
replaces, which is how other cookbooks should interpret its
contents, e.g. ant, would be more useful than a required name that
could still be anything, e.g. chef-ant.

Agreed?

A required name, that can be arbitrary, would still seem to leave
open the question 'is this cookbook a candidate for the depends in
another?'

A small issue might be that replaces is not obviously descriptive of
what it provides, but it does have the significant advantage of being
a minimal change.

Regards
Mark

Librarian-chef does not currently support dependency replacements, but
there's no reason it couldn't in the future.

Cheers,
Jay

On Thu, Nov 15, 2012 at 9:00 PM, Mark Van De Vyver mark@taqtiqa.com wrote:

On Thu, Nov 15, 2012 at 6:31 AM, Bryan McLellan btm@loftninjas.org
wrote:

On Tue, Nov 13, 2012 at 5:47 PM, Jeffrey Hulten
jeffh@automatedlabs.com wrote:

I have run across a couple of cases where this bit me or others. Should
the name attribute be added to the boilerplate metadata.rb?

Patch already provided here awaiting review:
http://tickets.opscode.com/browse/CHEF-3562

There's an issue open that asks if name should be a required
attribute: http://tickets.opscode.com/browse/CHEF-3490

And yet another ticket to make name be the name of the cookbook rather
than the directory: http://tickets.opscode.com/browse/CHEF-3307

Assume dependency resolution is handled by separate tools (Librarian,
Berkshelf, etc.)
There are two types of names:
a) what is the name of this cookbook (some have the convention of the
folder or repo name), e.g. chef-ant or cookbook-ant, etc.
b) What is the name of this cookbook when someone is trying to
satisfy the depends in another cookbook, e.g ant

It seems sensible to leave the the current name as optional with
meaning unchanged, and introduce depends_name (as a requirement?)
Where depends_name is the name of this cookbook when someone tries
to satisfy a depends requirement stated in another cookbook.

So you could have metadata.rb:

name chef-ant
depends_name ant

I'm only part way through writing a Librarian-chef source so I leave
it to more experienced hands to comment authoritatively, but so far it
seems that this is a useful addition that reflects the fact that
dependency resolution is often handled by tools that need to know
'what should other cookbooks know this cookbook as', yet are dealing
with source repo's and archives that have idiosyncratic naming
conventions.

Hopefully that makes sense.

Regards
Mark

Bryan