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

[Tim Smith < >]

Per environment run_lists would be a possible solution, but with 20
environments to manage it seems like a management nightmare to be juggling
run lists in that form.  It also really seems backwards from how Chef
generally gates change.  Environments dictate cookbook versions.  No one
would ever think of having particular parts of cookbooks that would run
depending on what environment they're in.  I hope that Opscode sees the
light here and adds some simple cookbook style version pinning.  It would
make a lot of people happy.

Tim Smith
Operations Engineer, SaaS Operations
M: +1 707.738.8132
TW: @tas50
webtrends <http://www.webtrends.com/>
Real-Time Relevance. Remarkable ROI.
London | Portland | San Francisco | Melbourne | Tokyo



On 11/21/12 9:54 AM, "Mike" 
<
 >
 wrote:

>Tim:
>For environments specific run lists, use Environment Run Lists.
>http://wiki.opscode.com/display/chef/Environments#Environments-PerEnvironm
>entRunListsinRoles
>
>-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
>>>>
>>