[chef] Re: Re: Re: Re: Re: Roles and Versioning


Chronological Thread 
  • From: Mike < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Roles and Versioning
  • Date: Wed, 21 Nov 2012 12:54:11 -0500

Tim:
For environments specific run lists, use Environment Run Lists.
http://wiki.opscode.com/display/chef/Environments#Environments-PerEnvironmentRunListsinRoles

-M


On Wed, Nov 21, 2012 at 12:50 PM, Tim Smith 
< >
 wrote:
> 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 
> < >
> wrote:
>>
>> Jay,
>>
>> 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?
>>
>> Thanks,
>> Kevin Christen
>>
>>
>> On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum 
>> < >
>> wrote:
>>>
>>> Kevin,
>>>
>>> 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.
>>>
>>> Cheers,
>>> Jay
>>>
>



Archive powered by MHonArc 2.6.16.

§