Re: [etch-users] Push Configuration

[Jason H. <jh...@ap...>]

On Mar 26, 2012, at 7:35 PM, Phillip Smith wrote:

> Just found etch the other day and it looks great... I've had puppet on my "todo" list for a while, but etch is simpler but still sufficient for what I want.

Just my personal opinion, but if you decide etch isn't your thing you should look at chef rather than puppet.  It's still too complicated, but more understandable than puppet.

> One query though, there appears to be no way to push config to a client (ie, the client has to connect to the server and pull it's config).
> 
> Are there any workarounds or plans to implement a push system so when a config is changed on the server, it pushes it to the client immediately without having to either a) login to the client and pull it or b) wait for a scheduled cron pull or similar?
> 
> It's not so bad for 1 client, but if you update a file that affects multiple clients, it would be (number_of_clients) times easier to be able to push it from the one location than having to login to each client :)


This comes up every once in a while, but so far I don't think anyone has found it to be an issue in practice.  Usually if you really need something to go out quickly you just need in on a manageable number of hosts (less than 100) and can use a for loop and ssh to the boxes to run etch out of cycle.  In really large environments (1000s or 10000s of hosts) the risk of pushing something quickly to all hosts is just too great, so you learn to accept the delay.

But for sake of argument I can talk a bit about how you might approach this if you really want it.  From a purely technical standpoint you have two major approaches:

* Run something in cron on the clients more frequently (every minute or every 5 minutes for example) that checks for special, out-of-cycle update requests.
* Poke the clients to run etch out of cycle.

The problem with the first approach is that you're going to beat up your etch servers with the heavy polling, most of which is useless (since you will be pushing out of cycle updates very infrequently relative to the polling frequency).  If your environment is relatively small this may be acceptable though.  I can imagine ways to use the existing "tag" functionality to make this work.  For example, you could have in cron:

* * * * *   etch --generate-all --tag urgent
0 * * * *  etch --generate-all

/etc/etchserver/urgent could normally be an empty directory, but if you had something urgent to push you could populate that directory with an updated config repository.  Once all the clients had picked up the change and the change had propagated into your normal tags then you could clean the urgent directory out again.  You could get fancier with adding a timestamp to the tag (i.e. urgent-`date +%Y%m%d%H%M`) and then you wouldn't have to bother with cleaning out the directory.

The problem with the second approach (as you mentioned) is that for a non-trivial number of hosts the time to run a for loop over all of them is probably longer than you'd like, requires the ability to ssh in and run something as root (which is often locked down for security reasons), etc.  I've thought about building a special daemon that just listens on a port and if it gets a connection it runs etch.  That would probably be faster than using ssh, but in the end I've always decided it's not worth the effort.  It would be pretty easy to do though if you wanted that approach.