[chef] RE: Re: Re: Automated check-ins or not...

[Phillip Roberts < >]

The problem isn’t my coworker, the problem is a lack of understanding the tool.

 

Chef is my baby, and I am perfectly fine with automated check-in’s, however, just like any business, there are politics at play. There are fears due to a lack of understanding as well.

 

I am purposely asking for others use cases because I am interested in them to help me form my arguments as to why chef nodes should be checking in (running chef-client) automatically.

 

I am not asking for anyone to tell me whether we should be using chef, or how we should be using chef, I am interested in how it is being used in other environments. I have seen plenty of other environments where I have implemented chef, however, in all cases, I have implemented chef and the policies that surround chef. In all cases, this question has never come up, or this argument.

 

I appreciate the responses thus far.

 

Thanks,

 

Phillip Roberts | Sr. Linux Systems Administrator

San Mateo | Ann Arbor | New York | London

O 734.922.7014 | C 614.423.9871 | www.MyBuys.com

 

From: Christopher Armstrong [mailto:
Sent: Monday, January 13, 2014 4:09 PM
To:
Subject: [chef] Re: Re: Automated check-ins or not...

 

Chef as a tool is used for orchestration, converging nodes to a desired state. If your coworker doesn't want nodes checking in automatically, then perhaps Chef isn't the ideal tool for you. What does your use case look like?

 

On Mon, Jan 13, 2014 at 1:05 PM, Ranjib Dey < " target="_blank"> > wrote:

by check in do you mean chef runs or chef registrations. I am aware of 3 different ways 

 

1) on demand: use rundeck, or mco or capistrano like tools to invoke chef run. pros: on demand :-), which helps if you deploy your application via chef. also you can eliminate the need of a validation certificate. cons: requires additional tooling, special security considerations etc. 

 

2) as service : specify a splay time, and use the standard init scripts to run chef client as service. pros:  no additional configuration required, no dependency on any other tools. cons: memory leak, stale processes used to be a pain.

 

3) as a scheduled job : use cron or rufus like system to run chef on periodic interval. pros: simple, less prone to memory leaks., cons: infra has to be designed as evantually consistent, on demand application deployment can not be done., additional considerations needed on deciding cron times on individual servers, else u'll storm the chef server.

 

 

i have used pretty much all three of these. and i think all of them has merits. choose any one depending upon what you do, how you are doing it and how comfortable you are with chef and those tools. most of the issues with running chef as service are now sorted (or workarounds are known).

 

best

ranjib

 

 

On Mon, Jan 13, 2014 at 12:52 PM, Phillip Roberts < " target="_blank"> > wrote:

I am interested in hearing what others are doing in terms of allowing nodes to automatically check in with chef or not. It has recently come up as a concern with a party in our company, he would prefer to not see nodes check in automatically with chef (I currently have a cron job that runs chef-client every X number of minutes).

 

I am just interested in hearing how others manage this, I am not certain that I think that manually running chef-client is a good solution.

 

I am being slightly vague on purpose, because I am looking for full case examples from others using chef and how they are using it.

 

Thanks,

 

Phillip Roberts | Sr. Linux Systems Administrator

San Mateo | Ann Arbor | New York | London

O 734.922.7014 | C 614.423.9871 | www.MyBuys.com