[chef] Re: on the general usage of chef


Chronological Thread 
  • From: Sam Darwin < >
  • To: " " < >
  • Subject: [chef] Re: on the general usage of chef
  • Date: Tue, 14 Jan 2014 13:22:03 +0100

ok, I see this was all already discussed yesterday!   nevermind then.

I suppose my point is in relation to that comment/quote in the last
thread which went   "to err is human, to propagate your error to 1000
machines automatically is devops."     if you are a cookbook author,
and you are designing complex cookbooks, and changing them often,
and then...        it has to be kept in mind.



On Tue, Jan 14, 2014 at 1:02 PM, Sam Darwin 
< >
 wrote:
>
> it seems like the ideal case of using chef, would be to run it as a cronjob
> every day on the servers, to keep the servers in their proper and perfect
> configuration.
>
> In practice, we are currently not doing this.   there is more than just one
> simple reason for it.
>
> - the recipes would need to always be in a perfect and functional state.
> let's say that you were experimenting with something.   and then every 
> single
> server in your environment grabs that recipe and runs it.    this could 
> affect
> the entire system, every single server.
>
> - even if you had two separate chef servers, one for production and one for
> testing...  so that the production server was designed to always be correct.
> even then, there is some small chance for human error, and it would 
> propagate
> automatically and without necessarily being watched at that moment, to every
> single server in the environment.
>
> -  you might have recipes that are designed to handle 95% of the tasks, but
> there is still a bit of human intervention, or the developers are still 
> logging
> into the servers and tweaking things .      an automated chef run might 
> cause a
> conflict between the recipe and the manually added changes.
>
> - the recipes are in a state of flux, you might apply them carefully and
> methodically to only a few servers at a time.
>
> thoughts on this topic?



Archive powered by MHonArc 2.6.16.

§