On Oct 15, 2012, at 4:18 AM, Jay Feldblum <firstname.lastname@example.org:email@example.com> wrote:
Roles are data, not code.
Code is often packaged-up and redistributed, but data typically isn’t. A code package will have a version, and will depend on other code packages, but data won’t.
The goal should be to minimize the input data, which is roles. You can do this by moving as much as you can into code, using sensible defaults, computing derived values from given values, writing infrastructure-specific non-redistributable cookbooks, etc. That way you can pull the implementation details out of your roles as much as possible, since roles are not data. That way your roles are just there to group related nodes under the same name, but not really to do the heavy lifting, and your input data is minimized.
On Mon, Oct 15, 2012 at 3:16 AM, Torben Knerr <firstname.lastname@example.org:email@example.com> wrote:
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
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. “firstname.lastname@example.org:email@example.com”), 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”?
Am 14.10.2012 23:38 schrieb “Peter Donald” <firstname.lastname@example.org:email@example.com>:
On Sun, Oct 14, 2012 at 1:32 AM, Bryan Brandau <firstname.lastname@example.org:email@example.com> 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