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 <
">
>
Reply-To: " "> " < "> > Date: Wednesday, November 21, 2012 8:37 AM To: " "> " < "> > Subject: [chef] Re: Re: Re: Roles and Versioning Kevin,
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).
Cheers,
Jay
On Wed, Nov 21, 2012 at 10:25 AM, Kevin Christen
<
" target="_blank">
> wrote:
Jay, |
Archive powered by MHonArc 2.6.16.