[chef] Re: Re: Re: Re: Knife monitoring

[Gregory Patmore < >]

we have a private github server, so the issue isn't as critical for us since we have control over access to the server. 

Revision control is relatively simple on the source side, and as long as you can guarantee that anyone with a knife account will no go off reservation it will suffice, but as the team, infrastructure, and various environments grow it becomes more of an exercise in faith then a reliable system (this is just my experience). 

I've been pondering the same questions you have lately. Employing tools like chef-zero and other chef helpers require local access to node information, which, as you point out, can be represented incompletely. 

The only idea I've had that I haven't dismissed is tracking the node objects in a different repo then your cookbooks, but even that doesn't quite cut it if I understand you're meaning. 

Sent from my iPhone

On May 23, 2014, at 3:14 PM, Tristan Keen < "> > wrote:

  We're looking into how to do something similar in using git to be the primary record of state (including audit-ability & changelog), i.e. cookbooks in separate repos, and a chef-data repo for databags, environments, etc. (we don't use roles).

  But storing nodes troubles me - a lot of tools & cookbooks expect to store state in the "normal" priority attributes, which are persisted in Chef Server's node database.  Transient state is generated by cookbooks at the other priority levels, which can be used to implement Search and other data publishing/metrics activity.  All that would get blitzed if we store all the nodes in the same chef-data repo, and did a blanket upload of all nodes (along with databags & environments) from the git repo whenever someone pushed a single new node/databag/whatever.

  Any suggestions on how do to cope with this?

Tristan.

On 23 May 2014 14:38, Jeff Byrnes < " target="_blank"> > wrote:

We went a similar route, though we aren’t using Jenkins, but instead, have “chefhooks” bit running on a worker server. It will apply any change that’s pushed to our git repo, so it’s very trusting, but since it’s so easy to update environments, data bags, etc., nobody does it using knife (with the exception of encrypted data bags, which must be edited via knife).

We don’t, however, handle cookbooks that way; those are all driven by a Berkshelf workflow that relies on Travis to test things using Test Kitchen & the EC2 driver.

-- 

Jeff Byrnes
@berkleebassist

Operations Engineer

EverTrue

704.516.4628

On May 23, 2014 at 8:08:04 AM, Mike Splain ( " target="_blank"> ) wrote:

We tried to tackle that problem and had similar issues. Instead, we're going the automated route, only Jenkins can make changes to chef: automated pushes of cookbooks, environments, roles, etc. that tracking and history are built into Jenkins and only occur after a proper merge has been done in GitHub. 

I know that's not exactly what you're asking but just something to think about. 

Good luck!

Mike

On Friday, May 23, 2014, Gregory Patmore < " target="_blank"> > wrote:

Hey all,

As our chef repos grow and becomes more collaborative, a need to track activity on the chef server is rising in priority for me.

We've wrapped the knife util to track activity, but can't enforce that people will use the wrapped util. Is there any way anyone is doing this? I'd like to implement tracking at the chef server side. Any plugin or advice would be appreciated.

Gregory Patmore