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

[Adam Jacob < >]

Nothing wrong with manual uploading of cookbooks - the important step
is that you are taking the cookbook policy and promoting it through to
other environments, essentially.

Adam

On Wed, May 2, 2012 at 10:19 PM, Bryan Berry 
<
 >
 wrote:
> 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 
> <
 >
>  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
>
>



-- 
Opscode, Inc.
Adam Jacob, Chief Customer Officer
T: (206) 619-7151 E: