3

Say that a puppet agent is in the middle of a refresh and I stop the puppet master service. Is there any point that it would potentially cause an incomplete or corrupt setup to be pushed out like I describe below?

Background:

I'm using continuous integration and version control (Bamboo and Stash) for my puppet config files.

I've run into issues that during the redeployment process. It is most noticeable when I do a pull request for my production branch but it occurs elsewhere as well. A puppet agent may be trying to access a resource file that has been deleted before it has been pushed back out. Although quite rare this has caused havoc of all kinds, especially in modules that use a file statement to push out an entire directory.

The most sensible thing I've come up with would be to stop the puppet master service for the duration of the deploy and then kick it back on but I'm not seeing anything about the ramifications of stopping the puppetmaster while it may still be being used.

2
  • Yes it is certainly possible to build a config that would result in bad things happening if/when agenct communication is interrupted in the middle of a run. With a recursive file deploy no individual file will be corrupt, they should either be the old or new version, but you could get a miss-matched set. One approach to handle this might be to use that recursive file to deploy to an intermediate directory on the client, and then setup things so that files are transferred from the intermediate to the production directory on a fully successful transfer of all resources.
    – Zoredache
    Nov 27, 2013 at 17:33
  • @Zoredache thanks. For a recursive deploy shouldn't it be a non issue assuming that none of the files changed during the last run, therefore the file set from before would be the same as from after? Nov 27, 2013 at 18:21

2 Answers 2

3

For a recursive deploy shouldn't it be a non issue assuming that none of the files changed during the last run, therefore the file set from before would be the same as from after?

Right. The decision to replace a file is made based on a comparison of the md5 hashes from the client and the server. If you stop the master mid-run, it should just error out on all the remaining file resources - you won't end up with a partial copy of a file in place.

1

There are several distinct parts of a puppet run.

  1. The node retrieves its facts from its self and sends them to the puppet master server
  2. The puppet master server accepts those facts from a server and compiles a catalog that should be run on the node that reported its facts. This includes the contents of the files that are managed.
  3. The catalog is sent to the node and the node applies its catalog locally.
  4. The node reports its run

So depending where you are in this process either the run will fail outright or the node's run will continue and fail at reporting.

There shouldn't be an issue with corrupted files like you are mentioning.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .