Ideas for chef-hackday at Chefconf, Tuesday afternoon, May 15


#1

Yo Chefs!

Somehow I have been drafted into organizing a Chef hackday on the
Tuesday afternoon ahead of Chefconf. For this Hackday to be somewhat
productive, esp. in such a short window of time, it needs to be very
focused. My initial thoughts are to focus on testing as that is my own
current focus. What would you Chef-devs like to see such an event
focus on?

My idea so far is to focus on testing the application cookbook in
every possible configuration using various methodologies such as
vagrant, toft, chefspec, etc. Even better test it on different
platforms. As Jay Feldblum has suggested in the past, each cookbook
needs to be a self-contained project, including with its own set of
battle-hardened integration tests. My only concern about focusing on
the application cookbook is that it is currently undergoing a lot of
change.

I would love to hear from you guys what you would like to see such an
event focus on. Perhaps testing is boring and we should have an
installfest putting omnibus through its paces!

I have created this planning document here:

yours in cookery,

BryanWB


#2

On Tuesday, April 24, 2012 at 1:17 PM, Bryan Berry wrote:

Yo Chefs!

Somehow I have been drafted into organizing a Chef hackday on the
Tuesday afternoon ahead of Chefconf. For this Hackday to be somewhat
productive, esp. in such a short window of time, it needs to be very
focused. My initial thoughts are to focus on testing as that is my own
current focus. What would you Chef-devs like to see such an event
focus on?

My idea so far is to focus on testing the application cookbook in
every possible configuration using various methodologies such as
vagrant, toft, chefspec, etc. Even better test it on different
platforms. As Jay Feldblum has suggested in the past, each cookbook
needs to be a self-contained project, including with its own set of
battle-hardened integration tests. My only concern about focusing on
the application cookbook is that it is currently undergoing a lot of
change.

I would love to hear from you guys what you would like to see such an
event focus on. Perhaps testing is boring and we should have an
installfest putting omnibus through its paces!

Testing was a hot topic at the Community Summit, and I think the crowd at a Hackday would be pretty similar in skill level and interests. You can take a look at the session topics and write-ups and see if anything else looks interesting:

http://wiki.opscode.com/display/chef/Opscode+Community+Summit+1

I have created this planning document here:
https://github.com/bryanwb/chef-hackday/blob/master/Planning.md

yours in cookery,

BryanWB


Dan DeLeo


#3

thanks kallistec! i will look through that

On Tue, Apr 24, 2012 at 10:23 PM, Daniel DeLeo dan@kallistec.com wrote:

On Tuesday, April 24, 2012 at 1:17 PM, Bryan Berry wrote:

Yo Chefs!

Somehow I have been drafted into organizing a Chef hackday on the
Tuesday afternoon ahead of Chefconf. For this Hackday to be somewhat
productive, esp. in such a short window of time, it needs to be very
focused. My initial thoughts are to focus on testing as that is my own
current focus. What would you Chef-devs like to see such an event
focus on?

My idea so far is to focus on testing the application cookbook in
every possible configuration using various methodologies such as
vagrant, toft, chefspec, etc. Even better test it on different
platforms. As Jay Feldblum has suggested in the past, each cookbook
needs to be a self-contained project, including with its own set of
battle-hardened integration tests. My only concern about focusing on
the application cookbook is that it is currently undergoing a lot of
change.

I would love to hear from you guys what you would like to see such an
event focus on. Perhaps testing is boring and we should have an
installfest putting omnibus through its paces!

Testing was a hot topic at the Community Summit, and I think the crowd at a Hackday would be pretty similar in skill level and interests. You can take a look at the session topics and write-ups and see if anything else looks interesting:

http://wiki.opscode.com/display/chef/Opscode+Community+Summit+1

I have created this planning document here:
https://github.com/bryanwb/chef-hackday/blob/master/Planning.md

yours in cookery,

BryanWB


Dan DeLeo


#4

I’m also planning a Chef hackday for Monday evening in San Francisco. It is
very difficult for most people in SF to get down to the south bay during a
week evening, much less week day. My focus will be on improving existing
cookbooks / contributing back changes we haven’t (personally, the haproxy
cookbook).

I’ll post this on the SF DevOps meetup page today.

James


#5

hey James count me in for Monday as I will be SF on Monday

funny you mention the haproxy cookbook as I am currently working on that :slight_smile:

On Tue, Apr 24, 2012 at 11:12 PM, James js@aegisco.com wrote:

I’m also planning a Chef hackday for Monday evening in San Francisco. It is
very difficult for most people in SF to get down to the south bay during a
week evening, much less week day. My focus will be on improving existing
cookbooks / contributing back changes we haven’t (personally, the haproxy
cookbook).

I’ll post this on the SF DevOps meetup page today.
;
James


#6

I’m up for the monday as well. Btw, somebody had said something on
Twitter and the IRC about a Chef Hackathon that Monday.

On Tue, Apr 24, 2012 at 10:17 PM, Bryan Berry bryan.berry@gmail.com wrote:

hey James count me in for Monday as I will be SF on Monday

funny you mention the haproxy cookbook as I am currently working on that :slight_smile:

On Tue, Apr 24, 2012 at 11:12 PM, James js@aegisco.com wrote:

I’m also planning a Chef hackday for Monday evening in San Francisco. It is
very difficult for most people in SF to get down to the south bay during a
week evening, much less week day. My focus will be on improving existing
cookbooks / contributing back changes we haven’t (personally, the haproxy
cookbook).

I’ll post this on the SF DevOps meetup page today.
;
James


Juanje


#7

On Wed, Apr 25, 2012 at 4:17 AM, Bryan Berry bryan.berry@gmail.com wrote:

Yo Chefs!

Somehow I have been drafted into organizing a Chef hackday on the
Tuesday afternoon ahead of Chefconf. For this Hackday to be somewhat
productive, esp. in such a short window of time, it needs to be very
focused. My initial thoughts are to focus on testing as that is my own
current focus. What would you Chef-devs like to see such an event
focus on?

My idea so far is to focus on testing the application cookbook in
every possible configuration using various methodologies such as
vagrant, toft, chefspec, etc. Even better test it on different
platforms. As Jay Feldblum has suggested in the past, each cookbook
needs to be a self-contained project, including with its own set of
battle-hardened integration tests. My only concern about focusing on
the application cookbook is that it is currently undergoing a lot of
change.

I think this is a brilliant idea; too bad I won’t be there :frowning:

The application cookbook sounds like a good choice; I expect the
refactoring will be finished by then.


#8

On 2012-04-25, at 17:11, Andrea Campi wrote:

On Wed, Apr 25, 2012 at 4:17 AM, Bryan Berry bryan.berry@gmail.com wrote:

Yo Chefs!

Somehow I have been drafted into organizing a Chef hackday on the
Tuesday afternoon ahead of Chefconf. For this Hackday to be somewhat
productive, esp. in such a short window of time, it needs to be very
focused. My initial thoughts are to focus on testing as that is my own
current focus. What would you Chef-devs like to see such an event
focus on?

My idea so far is to focus on testing the application cookbook in
every possible configuration using various methodologies such as
vagrant, toft, chefspec, etc. Even better test it on different
platforms. As Jay Feldblum has suggested in the past, each cookbook
needs to be a self-contained project, including with its own set of
battle-hardened integration tests. My only concern about focusing on
the application cookbook is that it is currently undergoing a lot of
change.

I think this is a brilliant idea; too bad I won’t be there :frowning:

The application cookbook sounds like a good choice; I expect the
refactoring will be finished by then.

woot!


#9

On Apr 24, 2012, at 1:17 PM, Bryan Berry wrote:

Somehow I have been drafted into organizing a Chef hackday on the
Tuesday afternoon ahead of Chefconf. For this Hackday to be somewhat
productive, esp. in such a short window of time, it needs to be very
focused. My initial thoughts are to focus on testing as that is my own
current focus. What would you Chef-devs like to see such an event
focus on?

Here is the official session schedule link BTW:
http://chefconf2012.sched.org/

My idea so far is to focus on testing the application cookbook in
every possible configuration using various methodologies such as
vagrant, toft, chefspec, etc. Even better test it on different
platforms. As Jay Feldblum has suggested in the past, each cookbook
needs to be a self-contained project, including with its own set of
battle-hardened integration tests. My only concern about focusing on
the application cookbook is that it is currently undergoing a lot of
change.

I would love to hear from you guys what you would like to see such an
event focus on. Perhaps testing is boring and we should have an
installfest putting omnibus through its paces!

I have created this planning document here:
https://github.com/bryanwb/chef-hackday/blob/master/Planning.md

yours in cookery,

BryanWB


#10

+1. This is a hot topic for us right now.

Another topic to consider is the each-cookbook-in-its-own-repo thing:
we’re trying to figure out a good workflow for that.

-Jim

On 4/24/12 1:17 PM, “Bryan Berry” bryan.berry@gmail.com wrote:

Yo Chefs!

Somehow I have been drafted into organizing a Chef hackday on the
Tuesday afternoon ahead of Chefconf. For this Hackday to be somewhat
productive, esp. in such a short window of time, it needs to be very
focused. My initial thoughts are to focus on testing as that is my own
current focus. What would you Chef-devs like to see such an event
focus on?

My idea so far is to focus on testing the application cookbook in
every possible configuration using various methodologies such as
vagrant, toft, chefspec, etc. Even better test it on different
platforms. As Jay Feldblum has suggested in the past, each cookbook
needs to be a self-contained project, including with its own set of
battle-hardened integration tests. My only concern about focusing on
the application cookbook is that it is currently undergoing a lot of
change.

I would love to hear from you guys what you would like to see such an
event focus on. Perhaps testing is boring and we should have an
installfest putting omnibus through its paces!

I have created this planning document here:
https://github.com/bryanwb/chef-hackday/blob/master/Planning.md

yours in cookery,

BryanWB


#11

yes, very sad u won’t be there :frowning:

If no one has any objections, we can focus on testing the application cookbook

On Wed, Apr 25, 2012 at 7:11 PM, Andrea Campi
andrea.campi@zephirworks.com wrote:

On Wed, Apr 25, 2012 at 4:17 AM, Bryan Berry bryan.berry@gmail.com wrote:

Yo Chefs!

Somehow I have been drafted into organizing a Chef hackday on the
Tuesday afternoon ahead of Chefconf. For this Hackday to be somewhat
productive, esp. in such a short window of time, it needs to be very
focused. My initial thoughts are to focus on testing as that is my own
current focus. What would you Chef-devs like to see such an event
focus on?

My idea so far is to focus on testing the application cookbook in
every possible configuration using various methodologies such as
vagrant, toft, chefspec, etc. Even better test it on different
platforms. As Jay Feldblum has suggested in the past, each cookbook
needs to be a self-contained project, including with its own set of
battle-hardened integration tests. My only concern about focusing on
the application cookbook is that it is currently undergoing a lot of
change.

I think this is a brilliant idea; too bad I won’t be there :frowning:

The application cookbook sounds like a good choice; I expect the
refactoring will be finished by then.


#12

Take a look at runit-man cookcookhttps://github.com/Undev/runit-man-cookbook.
One of features is having of embedded Vagrantfile to test it in minutes.

So I think that Vagrant with multtiple VMs per installation is most
interesting choice.

2012/4/25 Bryan Berry bryan.berry@gmail.com

Yo Chefs!

Somehow I have been drafted into organizing a Chef hackday on the
Tuesday afternoon ahead of Chefconf. For this Hackday to be somewhat
productive, esp. in such a short window of time, it needs to be very
focused. My initial thoughts are to focus on testing as that is my own
current focus. What would you Chef-devs like to see such an event
focus on?

My idea so far is to focus on testing the application cookbook in
every possible configuration using various methodologies such as
vagrant, toft, chefspec, etc. Even better test it on different
platforms. As Jay Feldblum has suggested in the past, each cookbook
needs to be a self-contained project, including with its own set of
battle-hardened integration tests. My only concern about focusing on
the application cookbook is that it is currently undergoing a lot of
change.

I would love to hear from you guys what you would like to see such an
event focus on. Perhaps testing is boring and we should have an
installfest putting omnibus through its paces!

I have created this planning document here:
https://github.com/bryanwb/chef-hackday/blob/master/Planning.md

yours in cookery,

BryanWB


#13

It may be wise to structure the Git repository of tested cookbooks
according to the following convention:

/
cookbooks/
# .gitignore’d
# for cookbooks installed via librarian-chef
# this is an assumption librarian-chef currently makes
cookbook/
COOKBOOK-NAME/
attributes/
definitions/
files/
libraries/
providers/
recipes/
resources/
templates/
metadata.rb
test/
integration/
some_integration_test.rb
some_other_integration_test.rb
.gitignore
# includes:
# cookbooks/
# Cheffile.lock
Cheffile
# to support Vagrantfile
# the cookbook under test may depend on other cookbooks
Cheffile.lock
# .gitignore’d
# don’t add to git in a cookbook repo
# only add to git in an infrastructure repo
Rakefile
# has a task for zipping up the content of cookbooks/COOKBOOK-NAME
# and optionally for releasing to the Opscode Community Site
Vagrantfile
# if using Vagrant for testing
# references cookbooks located in cookbooks/ (dependencies) and
cookbook/ (under test)

If people think this is a good idea, I may add intelligence to
Librarian-Chef’s git source to try to find the cookbook inside
cookbook/COOKBOOK-NAME/ if it can’t find the cookbook at the top-level of
the git repo. However, for now, people can always use the format:

cookbook “COOKBOOK-NAME”,
:git => “git://github.com/user/COOKBOOK-NAME”,
:path => “cookbook/COOKBOOK-NAME”

Cheers,
Jay


#14

hmm, I have something different in mind

Jay, like we talked on the podcast, I think cookbooks need to be
self-contained. Here is how I think it should be laid out

I definitely think that the Vagrantfile, Toftfile (my own invention),
and Cheffile should live at the cookbook/COOKBOOK-NAME/ level

cookbook/COOKBOOK-NAME/
attributes/
definitions/
files/
libraries/
providers/
recipes/
resources/
temp/ # cache
cookbooks sourced by Cheffile
tests/ #
tests or test? don’t know the convention
minitest/
recipe1/

      some_test.rb

      some_test2.rb
                                                                  recipe2/

     . . .
                                                    cucumber/
                                                    rspec/
                                          Cheffile
                                          Cheffile.lock
                                          Rakefile
                                          Toftfile

same as Vagrantfile but for toft

                                          Vagrantfile

The Cheffile at the at COOKBOOK-NAME level would be used by
Vagrantfile or Toftfile to source the other cookbooks needed to run
integration tests.

that’s my euro 0,02

On Wed, Apr 25, 2012 at 7:53 PM, Jay Feldblum y_feldblum@yahoo.com wrote:

It may be wise to structure the Git repository of tested cookbooks according
to the following convention:

/
cookbooks/
# .gitignore’d
# for cookbooks installed via librarian-chef
# this is an assumption librarian-chef currently makes
cookbook/
COOKBOOK-NAME/
attributes/
definitions/
files/
libraries/
providers/
recipes/
resources/
templates/
metadata.rb
test/
integration/
some_integration_test.rb
some_other_integration_test.rb
.gitignore
# includes:
# cookbooks/
# Cheffile.lock
Cheffile
# to support Vagrantfile
# the cookbook under test may depend on other cookbooks
Cheffile.lock
# .gitignore’d
# don’t add to git in a cookbook repo
# only add to git in an infrastructure repo
Rakefile
# has a task for zipping up the content of cookbooks/COOKBOOK-NAME
# and optionally for releasing to the Opscode Community Site
Vagrantfile
# if using Vagrant for testing
# references cookbooks located in cookbooks/ (dependencies) and
cookbook/ (under test)

If people think this is a good idea, I may add intelligence to
Librarian-Chef’s git source to try to find the cookbook inside
cookbook/COOKBOOK-NAME/ if it can’t find the cookbook at the top-level of
the git repo. However, for now, people can always use the format:

cookbook “COOKBOOK-NAME”,
:git => “git://github.com/user/COOKBOOK-NAME”,
:path => “cookbook/COOKBOOK-NAME”

Cheers,
Jay


#15

Bryan,

Thanks for the comments.

The way I was thinking of it is that the individual cookbook is embedded in
a larger surrounding project, so that the “core” cookbook directory could
be pulled out and zipped up without much logic concerning which
files/directories belong to the “core” cookbook and which files/directories
belong to the larger surrounding project. This would make the work of a
"rake upload" type task much easier.

If, instead, everything is at the toplevel, that will require extra logic
when zipping and pushing a release. But it will make the project structure
simpler.

I wouldn’t embed everything deep down in cookbook/COOKBOOK-NAME; unless
there’s something I’m missing, I would either embed just the "core"
cookbook there or keep everything at the top-level. This is for repos
containing exactly one cookbook, following the repo-per-cookbook pattern.

Either way, let me know how easy/hard it is to integrate Vagrant & Toft
with the Cheffile (in case you or others plan to have one), and based on
your experimental results what can be done to improve that integration.

One thing I am considering is a metadata DSL method that would read the
metadata.rb from the same directory, so you wouldn’t have to spell out all
the dependencies in the metadata.rb and then do so again in the Cheffile.
This would follow the pattern of Bundler’s gemspec DSL method. I can see
this being useful for the Cheffile belonging to an individual cookbook repo.

site "http://community.opscode.com/api/v1"

# apply all the dependencies listed in ./metadata.rb
# these all use the default source listed above
metadata

# override the source for one of the cookbooks listed in ./metadata.rb
# e.g. in case we need a specific fix when developing & testing the

cookbook
cookbook “apache2”,
:git => “https://github.com/opscode-cookbooks/apache2”,
:ref => “be12fede2e99aff3029360df38366a3b8a34171f”

Cheers,
Jay

On Wed, Apr 25, 2012 at 2:14 PM, Bryan Berry bryan.berry@gmail.com wrote:

hmm, I have something different in mind

Jay, like we talked on the podcast, I think cookbooks need to be
self-contained. Here is how I think it should be laid out

I definitely think that the Vagrantfile, Toftfile (my own invention),
and Cheffile should live at the cookbook/COOKBOOK-NAME/ level

cookbook/COOKBOOK-NAME/
attributes/
definitions/
files/
libraries/
providers/
recipes/
resources/
temp/ # cache
cookbooks sourced by Cheffile
tests/ #
tests or test? don’t know the convention
minitest/

recipe1/

     some_test.rb

     some_test2.rb

recipe2/

    . . .
                                                   cucumber/
                                                   rspec/
                                         Cheffile
                                         Cheffile.lock
                                         Rakefile
                                         Toftfile

same as Vagrantfile but for toft

                                         Vagrantfile

The Cheffile at the at COOKBOOK-NAME level would be used by
Vagrantfile or Toftfile to source the other cookbooks needed to run
integration tests.

that’s my euro 0,02

On Wed, Apr 25, 2012 at 7:53 PM, Jay Feldblum y_feldblum@yahoo.com
wrote:

It may be wise to structure the Git repository of tested cookbooks
according
to the following convention:

/
cookbooks/
# .gitignore’d
# for cookbooks installed via librarian-chef
# this is an assumption librarian-chef currently makes
cookbook/
COOKBOOK-NAME/
attributes/
definitions/
files/
libraries/
providers/
recipes/
resources/
templates/
metadata.rb
test/
integration/
some_integration_test.rb
some_other_integration_test.rb
.gitignore
# includes:
# cookbooks/
# Cheffile.lock
Cheffile
# to support Vagrantfile
# the cookbook under test may depend on other cookbooks
Cheffile.lock
# .gitignore’d
# don’t add to git in a cookbook repo
# only add to git in an infrastructure repo
Rakefile
# has a task for zipping up the content of cookbooks/COOKBOOK-NAME
# and optionally for releasing to the Opscode Community Site
Vagrantfile
# if using Vagrant for testing
# references cookbooks located in cookbooks/ (dependencies) and
cookbook/ (under test)

If people think this is a good idea, I may add intelligence to
Librarian-Chef’s git source to try to find the cookbook inside
cookbook/COOKBOOK-NAME/ if it can’t find the cookbook at the top-level of
the git repo. However, for now, people can always use the format:

cookbook “COOKBOOK-NAME”,
:git => “git://github.com/user/COOKBOOK-NAME”,
:path => “cookbook/COOKBOOK-NAME”

Cheers,
Jay


#16

I feel pretty strongly that everything required to test a cookbook
live within the cookbook’s git repository, that each cookbook has to
be its own project. Isn’t every gem its own project?

Once something is common to various parts of your infrastructure, the
chance that it will be shared to the broader Chef community rapidly
approaches zero. This is just my experience. I have shared multiple
cookbooks but yet to share a single role, data_bag, environment or
even knife script w/ the broader Chef community.

Let me know if I have misunderstood you.

On Wed, Apr 25, 2012 at 8:47 PM, Jay Feldblum y_feldblum@yahoo.com wrote:

Bryan,

Thanks for the comments.

The way I was thinking of it is that the individual cookbook is embedded in
a larger surrounding project, so that the “core” cookbook directory could be
pulled out and zipped up without much logic concerning which
files/directories belong to the “core” cookbook and which files/directories
belong to the larger surrounding project. This would make the work of a
"rake upload" type task much easier.

If, instead, everything is at the toplevel, that will require extra logic
when zipping and pushing a release. But it will make the project structure
simpler.

I wouldn’t embed everything deep down in cookbook/COOKBOOK-NAME; unless
there’s something I’m missing, I would either embed just the “core” cookbook
there or keep everything at the top-level. This is for repos containing
exactly one cookbook, following the repo-per-cookbook pattern.

Either way, let me know how easy/hard it is to integrate Vagrant & Toft with
the Cheffile (in case you or others plan to have one), and based on your
experimental results what can be done to improve that integration.

One thing I am considering is a metadata DSL method that would read the
metadata.rb from the same directory, so you wouldn’t have to spell out all
the dependencies in the metadata.rb and then do so again in the Cheffile.
This would follow the pattern of Bundler’s gemspec DSL method. I can see
this being useful for the Cheffile belonging to an individual cookbook repo.

site "http://community.opscode.com/api/v1"

# apply all the dependencies listed in ./metadata.rb
# these all use the default source listed above
metadata

# override the source for one of the cookbooks listed in ./metadata.rb
# e.g. in case we need a specific fix when developing & testing the

cookbook
cookbook “apache2”,
:git => “https://github.com/opscode-cookbooks/apache2”,
:ref => “be12fede2e99aff3029360df38366a3b8a34171f”

Cheers,
Jay

On Wed, Apr 25, 2012 at 2:14 PM, Bryan Berry bryan.berry@gmail.com wrote:

hmm, I have something different in mind

Jay, like we talked on the podcast, I think cookbooks need to be
self-contained. Here is how I think it should be laid out

I definitely think that the Vagrantfile, Toftfile (my own invention),
and Cheffile should live at the cookbook/COOKBOOK-NAME/ level

cookbook/COOKBOOK-NAME/
attributes/
definitions/
files/
libraries/
providers/
recipes/
resources/
temp/ # cache
cookbooks sourced by Cheffile
tests/ #
tests or test? don’t know the convention
minitest/

recipe1/

     some_test.rb

     some_test2.rb

recipe2/

    . . .
                                                   cucumber/
                                                   rspec/
                                         Cheffile
                                         Cheffile.lock
                                         Rakefile
                                         Toftfile

same as Vagrantfile but for toft

                                         Vagrantfile

The Cheffile at the at COOKBOOK-NAME level would be used by
Vagrantfile or Toftfile to source the other cookbooks needed to run
integration tests.

that’s my euro 0,02

On Wed, Apr 25, 2012 at 7:53 PM, Jay Feldblum y_feldblum@yahoo.com
wrote:

It may be wise to structure the Git repository of tested cookbooks
according
to the following convention:

/
cookbooks/
# .gitignore’d
# for cookbooks installed via librarian-chef
# this is an assumption librarian-chef currently makes
cookbook/
COOKBOOK-NAME/
attributes/
definitions/
files/
libraries/
providers/
recipes/
resources/
templates/
metadata.rb
test/
integration/
some_integration_test.rb
some_other_integration_test.rb
.gitignore
# includes:
# cookbooks/
# Cheffile.lock
Cheffile
# to support Vagrantfile
# the cookbook under test may depend on other cookbooks
Cheffile.lock
# .gitignore’d
# don’t add to git in a cookbook repo
# only add to git in an infrastructure repo
Rakefile
# has a task for zipping up the content of cookbooks/COOKBOOK-NAME
# and optionally for releasing to the Opscode Community Site
Vagrantfile
# if using Vagrant for testing
# references cookbooks located in cookbooks/ (dependencies) and
cookbook/ (under test)

If people think this is a good idea, I may add intelligence to
Librarian-Chef’s git source to try to find the cookbook inside
cookbook/COOKBOOK-NAME/ if it can’t find the cookbook at the top-level
of
the git repo. However, for now, people can always use the format:

cookbook “COOKBOOK-NAME”,
:git => “git://github.com/user/COOKBOOK-NAME”,
:path => “cookbook/COOKBOOK-NAME”

Cheers,
Jay


#17

Bryan,

The original structure I outlined was a proposed structure for a single
cookbook repo - a repo whose purpose is the development and testing of a
single cookbook -, and was not a structure for a repo hosting multiple
cookbooks or for a full infrastructure.

In that proposed structure, the single “core” cookbook lives in a
subdirectory, while the surrounding boilerplate/tests/caches live either at
the top-level (e.g. the Rakefile) or in different subdirectories (e.g. the
test cases). That structure means you can pull out and tarball a single
subdirectory of the cookbook’s repo in order to capture the self-contained
cookbook, while skipping the boilerplate/tests/caches for the cookbook
which are outside of that single subdirectory.

There would of course be no roles, environments, data-bags, etc., in that
proposed structure, since it’s for developing & testing a single cookbook
in isolation rather than developing & testing an infrastructure.

The proposed structure mirrors the usual structure for most Ruby gems, but
replacing lib/GEM-NAME/ with cookbook/COOKBOOK-NAME/ (and replacing Gemfilewith
Cheffile for those who are so inclined).

Cheers,
Jay

On Wed, Apr 25, 2012 at 2:55 PM, Bryan Berry bryan.berry@gmail.com wrote:

I feel pretty strongly that everything required to test a cookbook
live within the cookbook’s git repository, that each cookbook has to
be its own project. Isn’t every gem its own project?

Once something is common to various parts of your infrastructure, the
chance that it will be shared to the broader Chef community rapidly
approaches zero. This is just my experience. I have shared multiple
cookbooks but yet to share a single role, data_bag, environment or
even knife script w/ the broader Chef community.

Let me know if I have misunderstood you.

On Wed, Apr 25, 2012 at 8:47 PM, Jay Feldblum y_feldblum@yahoo.com
wrote:

Bryan,

Thanks for the comments.

The way I was thinking of it is that the individual cookbook is embedded
in
a larger surrounding project, so that the “core” cookbook directory
could be
pulled out and zipped up without much logic concerning which
files/directories belong to the “core” cookbook and which
files/directories
belong to the larger surrounding project. This would make the work of a
"rake upload" type task much easier.

If, instead, everything is at the toplevel, that will require extra logic
when zipping and pushing a release. But it will make the project
structure
simpler.

I wouldn’t embed everything deep down in cookbook/COOKBOOK-NAME; unless
there’s something I’m missing, I would either embed just the "core"
cookbook
there or keep everything at the top-level. This is for repos containing
exactly one cookbook, following the repo-per-cookbook pattern.

Either way, let me know how easy/hard it is to integrate Vagrant & Toft
with
the Cheffile (in case you or others plan to have one), and based on your
experimental results what can be done to improve that integration.

One thing I am considering is a metadata DSL method that would read the
metadata.rb from the same directory, so you wouldn’t have to spell out
all
the dependencies in the metadata.rb and then do so again in the Cheffile.
This would follow the pattern of Bundler’s gemspec DSL method. I can see
this being useful for the Cheffile belonging to an individual cookbook
repo.

site "http://community.opscode.com/api/v1"

# apply all the dependencies listed in ./metadata.rb
# these all use the default source listed above
metadata

# override the source for one of the cookbooks listed in

./metadata.rb

# e.g. in case we need a specific fix when developing & testing the

cookbook
cookbook “apache2”,
:git => “https://github.com/opscode-cookbooks/apache2”,
:ref => “be12fede2e99aff3029360df38366a3b8a34171f”

Cheers,
Jay

On Wed, Apr 25, 2012 at 2:14 PM, Bryan Berry bryan.berry@gmail.com
wrote:

hmm, I have something different in mind

Jay, like we talked on the podcast, I think cookbooks need to be
self-contained. Here is how I think it should be laid out

I definitely think that the Vagrantfile, Toftfile (my own invention),
and Cheffile should live at the cookbook/COOKBOOK-NAME/ level

cookbook/COOKBOOK-NAME/
attributes/
definitions/
files/
libraries/
providers/
recipes/
resources/
temp/ # cache
cookbooks sourced by Cheffile
tests/ #
tests or test? don’t know the convention
minitest/

recipe1/

     some_test.rb

     some_test2.rb

recipe2/

    . . .
                                                   cucumber/
                                                   rspec/
                                         Cheffile
                                         Cheffile.lock
                                         Rakefile
                                         Toftfile

same as Vagrantfile but for toft

                                         Vagrantfile

The Cheffile at the at COOKBOOK-NAME level would be used by
Vagrantfile or Toftfile to source the other cookbooks needed to run
integration tests.

that’s my euro 0,02

On Wed, Apr 25, 2012 at 7:53 PM, Jay Feldblum y_feldblum@yahoo.com
wrote:

It may be wise to structure the Git repository of tested cookbooks
according
to the following convention:

/
cookbooks/
# .gitignore’d
# for cookbooks installed via librarian-chef
# this is an assumption librarian-chef currently makes
cookbook/
COOKBOOK-NAME/
attributes/
definitions/
files/
libraries/
providers/
recipes/
resources/
templates/
metadata.rb
test/
integration/
some_integration_test.rb
some_other_integration_test.rb
.gitignore
# includes:
# cookbooks/
# Cheffile.lock
Cheffile
# to support Vagrantfile
# the cookbook under test may depend on other cookbooks
Cheffile.lock
# .gitignore’d
# don’t add to git in a cookbook repo
# only add to git in an infrastructure repo
Rakefile
# has a task for zipping up the content of
cookbooks/COOKBOOK-NAME

#   and optionally for releasing to the Opscode Community Site
Vagrantfile
#   if using Vagrant for testing
#   references cookbooks located in cookbooks/ (dependencies) and

cookbook/ (under test)

If people think this is a good idea, I may add intelligence to
Librarian-Chef’s git source to try to find the cookbook inside
cookbook/COOKBOOK-NAME/ if it can’t find the cookbook at the top-level
of
the git repo. However, for now, people can always use the format:

cookbook “COOKBOOK-NAME”,
:git => “git://github.com/user/COOKBOOK-NAME”,
:path => “cookbook/COOKBOOK-NAME”

Cheers,
Jay


#18

dammit as usual, when I disagree w/ Jay, it’s only because I misunderstand
him :wink:

you deserve the Golden Spatula for sure!

this also begs the question of why we don’t package our cookbooks as ruby
gems. I am not familiar enough with gems to know their weaknesses. Adam
Jacob told me on Twitter once that “we can do better” than gems, and I hope
he is right.

On Wed, Apr 25, 2012 at 9:34 PM, Jay Feldblum y_feldblum@yahoo.com wrote:

Bryan,

The original structure I outlined was a proposed structure for a single
cookbook repo - a repo whose purpose is the development and testing of a
single cookbook -, and was not a structure for a repo hosting multiple
cookbooks or for a full infrastructure.

In that proposed structure, the single “core” cookbook lives in a
subdirectory, while the surrounding boilerplate/tests/caches live either at
the top-level (e.g. the Rakefile) or in different subdirectories (e.g. the
test cases). That structure means you can pull out and tarball a single
subdirectory of the cookbook’s repo in order to capture the self-contained
cookbook, while skipping the boilerplate/tests/caches for the cookbook
which are outside of that single subdirectory.

There would of course be no roles, environments, data-bags, etc., in that
proposed structure, since it’s for developing & testing a single cookbook
in isolation rather than developing & testing an infrastructure.

The proposed structure mirrors the usual structure for most Ruby gems, but
replacing lib/GEM-NAME/ with cookbook/COOKBOOK-NAME/ (and replacing
Gemfile with Cheffile for those who are so inclined).

Cheers,
Jay

On Wed, Apr 25, 2012 at 2:55 PM, Bryan Berry bryan.berry@gmail.comwrote:

I feel pretty strongly that everything required to test a cookbook
live within the cookbook’s git repository, that each cookbook has to
be its own project. Isn’t every gem its own project?

Once something is common to various parts of your infrastructure, the
chance that it will be shared to the broader Chef community rapidly
approaches zero. This is just my experience. I have shared multiple
cookbooks but yet to share a single role, data_bag, environment or
even knife script w/ the broader Chef community.

Let me know if I have misunderstood you.

On Wed, Apr 25, 2012 at 8:47 PM, Jay Feldblum y_feldblum@yahoo.com
wrote:

Bryan,

Thanks for the comments.

The way I was thinking of it is that the individual cookbook is
embedded in
a larger surrounding project, so that the “core” cookbook directory
could be
pulled out and zipped up without much logic concerning which
files/directories belong to the “core” cookbook and which
files/directories
belong to the larger surrounding project. This would make the work of a
"rake upload" type task much easier.

If, instead, everything is at the toplevel, that will require extra
logic
when zipping and pushing a release. But it will make the project
structure
simpler.

I wouldn’t embed everything deep down in cookbook/COOKBOOK-NAME; unless
there’s something I’m missing, I would either embed just the "core"
cookbook
there or keep everything at the top-level. This is for repos containing
exactly one cookbook, following the repo-per-cookbook pattern.

Either way, let me know how easy/hard it is to integrate Vagrant & Toft
with
the Cheffile (in case you or others plan to have one), and based on your
experimental results what can be done to improve that integration.

One thing I am considering is a metadata DSL method that would read the
metadata.rb from the same directory, so you wouldn’t have to spell out
all
the dependencies in the metadata.rb and then do so again in the
Cheffile.
This would follow the pattern of Bundler’s gemspec DSL method. I can see
this being useful for the Cheffile belonging to an individual cookbook
repo.

site "http://community.opscode.com/api/v1"

# apply all the dependencies listed in ./metadata.rb
# these all use the default source listed above
metadata

# override the source for one of the cookbooks listed in

./metadata.rb

# e.g. in case we need a specific fix when developing & testing the

cookbook
cookbook “apache2”,
:git => “https://github.com/opscode-cookbooks/apache2”,
:ref => “be12fede2e99aff3029360df38366a3b8a34171f”

Cheers,
Jay

On Wed, Apr 25, 2012 at 2:14 PM, Bryan Berry bryan.berry@gmail.com
wrote:

hmm, I have something different in mind

Jay, like we talked on the podcast, I think cookbooks need to be
self-contained. Here is how I think it should be laid out

I definitely think that the Vagrantfile, Toftfile (my own invention),
and Cheffile should live at the cookbook/COOKBOOK-NAME/ level

cookbook/COOKBOOK-NAME/
attributes/
definitions/
files/
libraries/
providers/
recipes/
resources/
temp/ # cache
cookbooks sourced by Cheffile
tests/ #
tests or test? don’t know the convention
minitest/

recipe1/

     some_test.rb

     some_test2.rb

recipe2/

    . . .
                                                   cucumber/
                                                   rspec/
                                         Cheffile
                                         Cheffile.lock
                                         Rakefile
                                         Toftfile

same as Vagrantfile but for toft

                                         Vagrantfile

The Cheffile at the at COOKBOOK-NAME level would be used by
Vagrantfile or Toftfile to source the other cookbooks needed to run
integration tests.

that’s my euro 0,02

On Wed, Apr 25, 2012 at 7:53 PM, Jay Feldblum y_feldblum@yahoo.com
wrote:

It may be wise to structure the Git repository of tested cookbooks
according
to the following convention:

/
cookbooks/
# .gitignore’d
# for cookbooks installed via librarian-chef
# this is an assumption librarian-chef currently makes
cookbook/
COOKBOOK-NAME/
attributes/
definitions/
files/
libraries/
providers/
recipes/
resources/
templates/
metadata.rb
test/
integration/
some_integration_test.rb
some_other_integration_test.rb
.gitignore
# includes:
# cookbooks/
# Cheffile.lock
Cheffile
# to support Vagrantfile
# the cookbook under test may depend on other cookbooks
Cheffile.lock
# .gitignore’d
# don’t add to git in a cookbook repo
# only add to git in an infrastructure repo
Rakefile
# has a task for zipping up the content of
cookbooks/COOKBOOK-NAME

#   and optionally for releasing to the Opscode Community Site
Vagrantfile
#   if using Vagrant for testing
#   references cookbooks located in cookbooks/ (dependencies) and

cookbook/ (under test)

If people think this is a good idea, I may add intelligence to
Librarian-Chef’s git source to try to find the cookbook inside
cookbook/COOKBOOK-NAME/ if it can’t find the cookbook at the
top-level

of
the git repo. However, for now, people can always use the format:

cookbook “COOKBOOK-NAME”,
:git => “git://github.com/user/COOKBOOK-NAME”,
:path => “cookbook/COOKBOOK-NAME”

Cheers,
Jay


#19

I have no problem with the directory structure of a rubygem. The
comment was more about what it means to distribute and share cookbooks

  • rubygems are the wrong model, and the wrong ecosystem, to use inside
    Chef. Doesn’t mean there isn’t a bunch of good stuff to crib. (Just
    like there is good stuff to crib from CPAN - who doesn’t want CPAN
    Testers for cookbooks? I totally do.)

Adam

On Wed, Apr 25, 2012 at 12:47 PM, Bryan Berry bryan.berry@gmail.com wrote:

dammit as usual, when I disagree w/ Jay, it’s only because I misunderstand
him :wink:

you deserve the Golden Spatula for sure!

this also begs the question of why we don’t package our cookbooks as ruby
gems. I am not familiar enough with gems to know their weaknesses. Adam
Jacob told me on Twitter once that “we can do better” than gems, and I hope
he is right.

On Wed, Apr 25, 2012 at 9:34 PM, Jay Feldblum y_feldblum@yahoo.com wrote:

Bryan,

The original structure I outlined was a proposed structure for a single
cookbook repo - a repo whose purpose is the development and testing of a
single cookbook -, and was not a structure for a repo hosting multiple
cookbooks or for a full infrastructure.

In that proposed structure, the single “core” cookbook lives in a
subdirectory, while the surrounding boilerplate/tests/caches live either at
the top-level (e.g. the Rakefile) or in different subdirectories (e.g. the
test cases). That structure means you can pull out and tarball a single
subdirectory of the cookbook’s repo in order to capture the self-contained
cookbook, while skipping the boilerplate/tests/caches for the cookbook which
are outside of that single subdirectory.

There would of course be no roles, environments, data-bags, etc., in that
proposed structure, since it’s for developing & testing a single cookbook in
isolation rather than developing & testing an infrastructure.

The proposed structure mirrors the usual structure for most Ruby gems, but
replacing lib/GEM-NAME/ with cookbook/COOKBOOK-NAME/ (and replacing Gemfile
with Cheffile for those who are so inclined).

Cheers,
Jay

On Wed, Apr 25, 2012 at 2:55 PM, Bryan Berry bryan.berry@gmail.com
wrote:

I feel pretty strongly that everything required to test a cookbook
live within the cookbook’s git repository, that each cookbook has to
be its own project. Isn’t every gem its own project?

Once something is common to various parts of your infrastructure, the
chance that it will be shared to the broader Chef community rapidly
approaches zero. This is just my experience. I have shared multiple
cookbooks but yet to share a single role, data_bag, environment or
even knife script w/ the broader Chef community.

Let me know if I have misunderstood you.

On Wed, Apr 25, 2012 at 8:47 PM, Jay Feldblum y_feldblum@yahoo.com
wrote:

Bryan,

Thanks for the comments.

The way I was thinking of it is that the individual cookbook is
embedded in
a larger surrounding project, so that the “core” cookbook directory
could be
pulled out and zipped up without much logic concerning which
files/directories belong to the “core” cookbook and which
files/directories
belong to the larger surrounding project. This would make the work of a
"rake upload" type task much easier.

If, instead, everything is at the toplevel, that will require extra
logic
when zipping and pushing a release. But it will make the project
structure
simpler.

I wouldn’t embed everything deep down in cookbook/COOKBOOK-NAME; unless
there’s something I’m missing, I would either embed just the "core"
cookbook
there or keep everything at the top-level. This is for repos containing
exactly one cookbook, following the repo-per-cookbook pattern.

Either way, let me know how easy/hard it is to integrate Vagrant & Toft
with
the Cheffile (in case you or others plan to have one), and based on
your
experimental results what can be done to improve that integration.

One thing I am considering is a metadata DSL method that would read the
metadata.rb from the same directory, so you wouldn’t have to spell out
all
the dependencies in the metadata.rb and then do so again in the
Cheffile.
This would follow the pattern of Bundler’s gemspec DSL method. I can
see
this being useful for the Cheffile belonging to an individual cookbook
repo.

site "http://community.opscode.com/api/v1"

# apply all the dependencies listed in ./metadata.rb
# these all use the default source listed above
metadata

# override the source for one of the cookbooks listed in

./metadata.rb
# e.g. in case we need a specific fix when developing & testing the
cookbook
cookbook “apache2”,
:git => “https://github.com/opscode-cookbooks/apache2”,
:ref => “be12fede2e99aff3029360df38366a3b8a34171f”

Cheers,
Jay

On Wed, Apr 25, 2012 at 2:14 PM, Bryan Berry bryan.berry@gmail.com
wrote:

hmm, I have something different in mind

Jay, like we talked on the podcast, I think cookbooks need to be
self-contained. Here is how I think it should be laid out

I definitely think that the Vagrantfile, Toftfile (my own invention),
and Cheffile should live at the cookbook/COOKBOOK-NAME/ level

cookbook/COOKBOOK-NAME/
attributes/
definitions/
files/
libraries/
providers/
recipes/
resources/
temp/ # cache
cookbooks sourced by Cheffile
tests/ #
tests or test? don’t know the convention
minitest/

recipe1/

     some_test.rb

     some_test2.rb

recipe2/

    . . .
                                                   cucumber/
                                                   rspec/
                                         Cheffile
                                         Cheffile.lock
                                         Rakefile
                                         Toftfile

same as Vagrantfile but for toft

                                         Vagrantfile

The Cheffile at the at COOKBOOK-NAME level would be used by
Vagrantfile or Toftfile to source the other cookbooks needed to run
integration tests.

that’s my euro 0,02

On Wed, Apr 25, 2012 at 7:53 PM, Jay Feldblum y_feldblum@yahoo.com
wrote:

It may be wise to structure the Git repository of tested cookbooks
according
to the following convention:

/
cookbooks/
# .gitignore’d
# for cookbooks installed via librarian-chef
# this is an assumption librarian-chef currently makes
cookbook/
COOKBOOK-NAME/
attributes/
definitions/
files/
libraries/
providers/
recipes/
resources/
templates/
metadata.rb
test/
integration/
some_integration_test.rb
some_other_integration_test.rb
.gitignore
# includes:
# cookbooks/
# Cheffile.lock
Cheffile
# to support Vagrantfile
# the cookbook under test may depend on other cookbooks
Cheffile.lock
# .gitignore’d
# don’t add to git in a cookbook repo
# only add to git in an infrastructure repo
Rakefile
# has a task for zipping up the content of
cookbooks/COOKBOOK-NAME
# and optionally for releasing to the Opscode Community Site
Vagrantfile
# if using Vagrant for testing
# references cookbooks located in cookbooks/ (dependencies)
and
cookbook/ (under test)

If people think this is a good idea, I may add intelligence to
Librarian-Chef’s git source to try to find the cookbook inside
cookbook/COOKBOOK-NAME/ if it can’t find the cookbook at the
top-level
of
the git repo. However, for now, people can always use the format:

cookbook “COOKBOOK-NAME”,
:git => “git://github.com/user/COOKBOOK-NAME”,
:path => “cookbook/COOKBOOK-NAME”

Cheers,
Jay


Opscode, Inc.
Adam Jacob, Chief Customer Officer
T: (206) 619-7151 E: adam@opscode.com


#20

Bryan,

Great question. Indeed, because Bundler rocked the gems world, @hedgehog
kicked off the idea of bundling up your cookbooks (props!) with his fork of
Bundler and a convention for treating cookbooks as gems (
http://hedgehogshiatus.com/carving-chefs-cookbooks). This was a great
solution, especially in Chef’s early days, and was an inspiration for me
thinking that we should be bundling the cookbooks we use.

But cookbooks are not gems. They don’t have lib directories, the gemspecs
do not expose enough of the metadata that cookbooks provide, they would
conflict with actual gems, etc. The principle is that form must follow
function: any packaging/bundling system for cookbooks must follow the
actual characteristics of cookbooks in order to be useful. Indeed, this is
what I have tried to do with Librarian-Chef: deal with cookbooks as they
are while following Bundler’s overarching principles (of course, that work
is ongoing and far from complete, whereas @hedgehog’s solution has been out
for a few years already).

Having multiple packaging/bundling systems for different kinds of
packagables isn’t really a problem to me - at least, the price is worth it.
The world is distributed. The things we make and use are replicated and
forked. Everybody learns from everybody else. Sure, now there’s a lot more
to learn and remember, but that’s the price you pay for continual
innovation everywhere. That’s why we have Chef, when there already was a
plethora of configuration management systems.

We should certainly package up (and distribute) ohai plugins, knife
plugins, and some chef report & exception handlers as gems, though.

Apologies for the length of my replies.

Cheers,
Jay

On Wed, Apr 25, 2012 at 3:47 PM, Bryan Berry bryan.berry@gmail.com wrote:

dammit as usual, when I disagree w/ Jay, it’s only because I misunderstand
him :wink:

you deserve the Golden Spatula for sure!

this also begs the question of why we don’t package our cookbooks as ruby
gems. I am not familiar enough with gems to know their weaknesses. Adam
Jacob told me on Twitter once that “we can do better” than gems, and I hope
he is right.

On Wed, Apr 25, 2012 at 9:34 PM, Jay Feldblum y_feldblum@yahoo.comwrote:

Bryan,

The original structure I outlined was a proposed structure for a single
cookbook repo - a repo whose purpose is the development and testing of a
single cookbook -, and was not a structure for a repo hosting multiple
cookbooks or for a full infrastructure.

In that proposed structure, the single “core” cookbook lives in a
subdirectory, while the surrounding boilerplate/tests/caches live either at
the top-level (e.g. the Rakefile) or in different subdirectories (e.g. the
test cases). That structure means you can pull out and tarball a single
subdirectory of the cookbook’s repo in order to capture the self-contained
cookbook, while skipping the boilerplate/tests/caches for the cookbook
which are outside of that single subdirectory.

There would of course be no roles, environments, data-bags, etc., in that
proposed structure, since it’s for developing & testing a single cookbook
in isolation rather than developing & testing an infrastructure.

The proposed structure mirrors the usual structure for most Ruby gems,
but replacing lib/GEM-NAME/ with cookbook/COOKBOOK-NAME/ (and replacing
Gemfile with Cheffile for those who are so inclined).

Cheers,
Jay

On Wed, Apr 25, 2012 at 2:55 PM, Bryan Berry bryan.berry@gmail.comwrote:

I feel pretty strongly that everything required to test a cookbook
live within the cookbook’s git repository, that each cookbook has to
be its own project. Isn’t every gem its own project?

Once something is common to various parts of your infrastructure, the
chance that it will be shared to the broader Chef community rapidly
approaches zero. This is just my experience. I have shared multiple
cookbooks but yet to share a single role, data_bag, environment or
even knife script w/ the broader Chef community.

Let me know if I have misunderstood you.

On Wed, Apr 25, 2012 at 8:47 PM, Jay Feldblum y_feldblum@yahoo.com
wrote:

Bryan,

Thanks for the comments.

The way I was thinking of it is that the individual cookbook is
embedded in
a larger surrounding project, so that the “core” cookbook directory
could be
pulled out and zipped up without much logic concerning which
files/directories belong to the “core” cookbook and which
files/directories
belong to the larger surrounding project. This would make the work of a
"rake upload" type task much easier.

If, instead, everything is at the toplevel, that will require extra
logic
when zipping and pushing a release. But it will make the project
structure
simpler.

I wouldn’t embed everything deep down in cookbook/COOKBOOK-NAME; unless
there’s something I’m missing, I would either embed just the "core"
cookbook
there or keep everything at the top-level. This is for repos containing
exactly one cookbook, following the repo-per-cookbook pattern.

Either way, let me know how easy/hard it is to integrate Vagrant &
Toft with
the Cheffile (in case you or others plan to have one), and based on
your
experimental results what can be done to improve that integration.

One thing I am considering is a metadata DSL method that would read the
metadata.rb from the same directory, so you wouldn’t have to spell out
all
the dependencies in the metadata.rb and then do so again in the
Cheffile.
This would follow the pattern of Bundler’s gemspec DSL method. I can
see
this being useful for the Cheffile belonging to an individual cookbook
repo.

site "http://community.opscode.com/api/v1"

# apply all the dependencies listed in ./metadata.rb
# these all use the default source listed above
metadata

# override the source for one of the cookbooks listed in

./metadata.rb

# e.g. in case we need a specific fix when developing & testing the

cookbook
cookbook “apache2”,
:git => “https://github.com/opscode-cookbooks/apache2”,
:ref => “be12fede2e99aff3029360df38366a3b8a34171f”

Cheers,
Jay

On Wed, Apr 25, 2012 at 2:14 PM, Bryan Berry bryan.berry@gmail.com
wrote:

hmm, I have something different in mind

Jay, like we talked on the podcast, I think cookbooks need to be
self-contained. Here is how I think it should be laid out

I definitely think that the Vagrantfile, Toftfile (my own invention),
and Cheffile should live at the cookbook/COOKBOOK-NAME/ level

cookbook/COOKBOOK-NAME/
attributes/
definitions/
files/
libraries/
providers/
recipes/
resources/
temp/ # cache
cookbooks sourced by Cheffile
tests/ #
tests or test? don’t know the convention
minitest/

recipe1/

     some_test.rb

     some_test2.rb

recipe2/

    . . .
                                                   cucumber/
                                                   rspec/
                                         Cheffile
                                         Cheffile.lock
                                         Rakefile
                                         Toftfile

same as Vagrantfile but for toft

                                         Vagrantfile

The Cheffile at the at COOKBOOK-NAME level would be used by
Vagrantfile or Toftfile to source the other cookbooks needed to run
integration tests.

that’s my euro 0,02

On Wed, Apr 25, 2012 at 7:53 PM, Jay Feldblum y_feldblum@yahoo.com
wrote:

It may be wise to structure the Git repository of tested cookbooks
according
to the following convention:

/
cookbooks/
# .gitignore’d
# for cookbooks installed via librarian-chef
# this is an assumption librarian-chef currently makes
cookbook/
COOKBOOK-NAME/
attributes/
definitions/
files/
libraries/
providers/
recipes/
resources/
templates/
metadata.rb
test/
integration/
some_integration_test.rb
some_other_integration_test.rb
.gitignore
# includes:
# cookbooks/
# Cheffile.lock
Cheffile
# to support Vagrantfile
# the cookbook under test may depend on other cookbooks
Cheffile.lock
# .gitignore’d
# don’t add to git in a cookbook repo
# only add to git in an infrastructure repo
Rakefile
# has a task for zipping up the content of
cookbooks/COOKBOOK-NAME

#   and optionally for releasing to the Opscode Community Site
Vagrantfile
#   if using Vagrant for testing
#   references cookbooks located in cookbooks/ (dependencies)

and

cookbook/ (under test)

If people think this is a good idea, I may add intelligence to
Librarian-Chef’s git source to try to find the cookbook inside
cookbook/COOKBOOK-NAME/ if it can’t find the cookbook at the
top-level

of
the git repo. However, for now, people can always use the format:

cookbook “COOKBOOK-NAME”,
:git => “git://github.com/user/COOKBOOK-NAME”,
:path => “cookbook/COOKBOOK-NAME”

Cheers,
Jay