- From: Bryan Berry <
>
- To:
- Subject: [chef] Re: Re: Re: Re: [chef-dev] Re: ideas for chef-hackday at Chefconf, Tuesday afternoon, May 15
- Date: Wed, 25 Apr 2012 20:55:59 +0200
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
<
>
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
>
<
>
>
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
>
> <
>
>
> 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
>
> >
>
>
Archive powered by MHonArc 2.6.16.