[chef] Re: Re: Re: conflict between using environments to manage cookbook releases and to manage application environments

[Bryan Berry < >]

gotta say I really like Peter's solution, will have to look at it in more detail

To answer Adam's, question I use manual upload for my cookbooks

The big cause of the instability in my cookbooks is that I am essentially learning these applications at the same time that I write cookbooks for them, not the ideal situation. I am also under a lot of pressure to set up a quite complicated  architecture in a very short period of time. Consequently, many of my initial configuration choices are less than ideal. Going back and fixing those choices w/out breaking running apps is a challenge. The obvious answer here is to implement automated cookbook testing w/ minitest/cucumber and toft/vagrant. Once my cookbooks are more stable and tested, i should be able to move many of those attributes that I have in data_bags over to environments. The only drawback is that I will have a long duplicated list of cookbook version constraints in each environment.

On Wed, May 2, 2012 at 2:02 AM, AJ Christensen < " target="_blank"> > wrote:

Peter,

That's an awesome assertion to have as part of your run_list -- may be
stealing this one for ourselves!

--AJ

On 2 May 2012 11:43, Peter Donald < "> > wrote:
> Hi,
>
> We have a very similar requirements here but the way we represent it
> in chef is with different environments. We do not allow the _default
> environment and instead have the following set
>
> * production
> * staging (still needed as some of the infrastructure is still part of
> a manual non-chef managed release process)
> * uat
> * development
> * ci (aka integration tests)
> * desktop (i.e our desktop managed machines)
> * chef_dev (i.e. when developing cookbooks)
>
> For each of these environments we have flags indicating the
> datacenter/location of the environment and the equivalent of a
> "stable" flag. If the "stable" flag is set then we require that the
> environment explicitly lists a version of a cookbook and that the
> cookbook version is frozen. This workflow is enforced by a recipe that
> included at the start of every chef run. You can see a snippet that
> illustrates the idea at [1].
>
> [1] https://gist.github.com/2048310
>
> On Tue, May 1, 2012 at 6:47 PM, Bryan Berry < "> > wrote:
>> Dear Chefs,
>>
>> I am flummoxed by my conflicting needs for Chef environments. I currently
>> have 2 environments:
>>
>> _default
>> QA:   cookbooks that I am testing,  I know exactly which nodes are in here
>> and they can tolerate a service restart or two. No important nodes belong to
>> this environment
>>
>> PROD: Only stable, tested cookbook versions here, the vast majority of nodes
>> belong to this environment
>>
>> on the other hand, my organization has 4, count 'em, 4
>> application_environments
>>
>> PROD - production
>> QA   - user-facing tests
>> TS    - integration tests
>> DV    - development servers
>>
>> All of these servers should be using stable, tested cookbooks as my devs
>> don't want to be disrupted by a misbehaving cookbook. Thus all of them
>> belong to PROD chef_environment, besides the couple that I am using to test
>> cookbooks at a given moment.
>>
>> I currently manage application_environments with data bags that look like
>> this
>>
>> apps/esb.json
>> {
>>    "pr": {
>>           "database_schema": "production_schema"
>>      },
>>      "qa": {
>>           "database_schema": "qa_schema"
>>      }
>>     . . . .
>> }
>>
>> additionally, I add a top-level attribute to each node "app_env"  that
>> indicates which application_environment a node belongs to
>>
>> Some cookbooks, such as the haproxy cookbook, treat chef_environments like
>> application_environments
>>
>> I would love to treat chef_environments like application_environments but
>> that would completely break my workflow. How are others dealing w/ the
>> issues I have brought up here?
>>
>>
>
>
>
> --
> Cheers,
>
> Peter Donald