[chef] Re: Re: Re: Chef in "Pure Infrastructure-As-Code" Mode?

[Dan Adams < >]

On 24.06.2012 10:04, Torben Knerr wrote:

> Yes, that would be pretty close. I'm basically interested in keeping
> track of any recipe / attribute / databag changes on my
> nodes. Ideally I want these changes happening only via git commits
> and prevent these changes happening via knife / REST API. 
>
> Currently I have $CHEF_REPO/nodes/<nodename>.json for each of my
> nodes which should reflect the current state of the node in chef
> server. Whenever I modify the node's run_list or attributes etc. I
> have to make sure to keep it in sync manually by doing the commit AND
> the upload via knife.
>
> Btw: do you have any preventative measures to disallow the "knife
> edit" type workflow, or is convention enough for you?

So the way we solve this is that everyone works in git and everything 
is driven by git. When someone pushes to origin in git, then a git 
commit hook on push grabs all the changes and generates the knife 
commands (which it then executes automatically) to import the necessary 
files into couch/solr. This means that there is an active disincentive 
to use knife directly - if you do, your changes will be overwritten the 
next time someone commits a change to the same resource. Between that 
and convention I really haven't found a need to actively lock out knife 
commands - people are used to using git, and the process is so easy and 
automated they are actively disincentivised from trying to get around 
it.


> > May be a noob question, but why do you need the client's PEM files
> > in your chef repo?

Because we try to follow fairly religiously the "rebuild anything from 
bare metal and a repo of code" mentality - so if a chef server or chef 
client dies I have a copy of its private and public PEM files and can 
get it back in the same state as before quickly without having to 
regenerate and re-issue keys at one end or the other.

>  As for the after-commit hook, I'm
> > ugh to not
> > introduce lots of artificial changes (guess it would re-upload
> > _all_
> > cookbooks, roles, databags, nodes, etc even if I change only a tiny
> > bit in a single node json).

I'm not following you here. It does not do this. Our git commit hook 
finds only what has changed, and then calculates what needs to be 
updated based on that. So if you edit an environment file, only the 
environment file is updated, if you edit a node file, only the node file 
is updated. The different here is that we don't store nodes as a single 
JSON file, we use the standard chef git repo structure of node, env, 
cookbook, client etc files.

> > The Rakefile inside the chef repo is written in a way so that if you
> > run `rake install` it would upload _everything_ in the chef repo
> > (i.e. cookbooks, roles, environments, databags) to chef server. I
> > guess it is not smart enough to upload only
> at have changed.
>
> So your commit hook script would be exactly what I was looking for. 
> +1
> for putting it on github :-)
>
> I'm also wondering if other's haven't had the same requirements and
> maybe built something similar already?

Yes, I'm sure this is a common requirement and must be written over and 
over in many shops. I'll upload what I have to github and wait for 
someone to shoot it down with something far simpler, quicker, more 
efficient and more elegant :-)

Dan