Fully agree. In fact there seems to be something missing inbetween cookbooks and roles that dosen't have a name yet.
Peter calls it "role cookbooks", and the guys at riotGames call them "application cookbooks" I believe (not to be confused with _the_ "application" cookbook).
However it is called it seems to be a common pattern because you typically want to compose individual cookbooks. So you start with a role, but then you notice that
- roles are not versioned
- so you can't dependency manage roles
- so they don't live in their own git repository but rather in a specific chef repo
- so they are not reusable across chef repositories
- etc..
Initially I thought that putting version numbers in roles and extending tools like librarian and berkshelf to support role dependency management would be a good idea. But then I noticed that a "role cookbook" would be way better, because:
- its already supported with the tools we have now
- you typically need a place where you use the LWRPs provided by other cookbooks - you can't do that in roles
- having it as a cookbook it can live in its own git repo, can be tested in isolation, can be dependency-managed and easily reused across chef repos
- until some days ago I also thought this would be the only way to strictly version dependencies (via metadata.rb), but then I learned that there is a syntax in roles as well that allows you to pin down cookbook (or rather recipe) versions (e.g. "
"), so this dosen't really count
- finally, when aggregating multiple cookbooks / recipes, you typically want to expose only a subset of the included cookbook's attributes for configuration. This is the chance to explicitly define and document the configurable attributes in the "role cookbook" if you prefer
Once you have a "role cookbook" it typically maps 1:1 to a role, but I could also imagine roles which have a "role cookbook" and some extra recipes in their runlist.
I haven't seen this pattern documented anywhere, except that it comes up on the mailing list every now an then. Wouldn't this be something for the Opscode Wiki?
And what would be a good name for it, e.g. "application cookbook", "role cookbook", "fancy cookbook", or something like "aggregation cookbook"?
Cheers, Torben
Am 14.10.2012 23:38 schrieb "Peter Donald" <
">
>:
>
> Hi,
>
>
> On Sun, Oct 14, 2012 at 1:32 AM, Bryan Brandau <
">
> wrote:
>>
>> It would be incredibly nice if Chef had the same versioning concept for roles or environments that cookbooks have.
>>
>
> I wonder if that is really needed. As soon as you version roles is there any real difference between them and cookbooks? Initially our infrastructure included a heap of roles that included attributes and recipes. As we evolved we found the need to version of the attributes and recipes. Slowly our roles evolved to what they are today. So our "graphite" role simply includes the "base_linux_server" role and the "fisg-graphite" recipe and all of our configuration and recipe inclusion occurs within "fisg-graphite". Except for a few of our windows nodes, all of our roles have a 1-to-1 mapping to cookbooks. The role is simply a simplified tag that includes the relevant "role cookbook".
>
> That way we can version the role cookbooks using the same mechanism we version the other cookbooks
>
> --
> Cheers,
>
> Peter Donald
Archive powered by MHonArc 2.6.16.