I understand the desire to keep roles simple and generic, but the lack of versioning in roles is a really huge pain point in working with Chef. I never add attributes to my roles to eliminate configuration from the roles, but there is often a need to change the run list portion of the roles. I use a single Chef server for my staging and production environments so I need to be able to test changes for a release before pushing those changes to prod. Right now if someone on my Dev team makes any modifications to the run list in a role I either have to push it to production immediately or undergo very manual renaming of roles / node changes. Versions would eliminate these problems entirely as I could use version 1 of a role in production while changing run lists entirely in a dev environment.
From: Jay Feldblum <email@example.com:firstname.lastname@example.org>
Reply-To: "email@example.com:firstname.lastname@example.org" <email@example.com:firstname.lastname@example.org>
Date: Wednesday, November 21, 2012 8:37 AM
To: "email@example.com:firstname.lastname@example.org" <email@example.com:firstname.lastname@example.org>
Subject: [chef] Re: Re: Re: Roles and Versioning
The boundary between interface and implementation depends on the context or on the viewpoint, and we need to be able to discover where that boundary is in the various cases we actually end up dealing with.
For me, default and override attributes in a role seem generally to lie on the implementation side of that boundary. That much seems, in most cases, open-and-shut. But the content of the run-list is more of an open question to me, and I suppose that, at least for now, I would end up deciding that on a case-by-case basis.
Keep in mind that something might, from one viewpoint, be an interface but, from another viewpoint, be an implementation.
This is of course applicable to code-type roles (roles that you keep in git), and not applicable to data-type roles (roles that are not kept in git).
On Wed, Nov 21, 2012 at 10:25 AM, Kevin Christen <email@example.com:firstname.lastname@example.org> wrote:
Can you elaborate on what you mean by treating a role as interface? It seems to me that a run_list is implementation. Or are you thinking that a run_list containing other roles is an interface, while a run_list containing recipes is an implementation?
On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum <email@example.com:firstname.lastname@example.org> wrote:
If you treat roles as implementation, then you will need to start versioning them.
If you treat roles as interface, as a declaration of intent only, and remove all implementation from them, then you will need to implement them with an implementation cookbook, so to speak. The role will not need to be versioned itself; only the implementation cookbook will need to be versioned.