Answers: <p>The safest assumption to make here is that the configuration is not applied completely and you should try again once the network is back.  You can set things up to work without the network, but why go to that work when it will try again for you in a few minutes?</p>
  
  <h1>Chef</h1>
  
  <p>Chef tends to be run in the client-server mode as you describe so the <code>chef-client</code> agent on the "controlled" machine would keep running.  It would get stuck when it needed to get cookbooks or figure out which roles were assigned.  It will eventually time out and the chef run will fail.  Then it would try again in a few minutes.  By default the agent tries to do a chef run every 30 minutes.</p>
  
  <p>If you're using <code>chef-zero</code> instead of the client-server style of chef then you could have everything staged on the "controlled" machine so that any network interruption wouldn't break it because of chef itself.  You might still have network dependancies in the cookbooks used.</p>
  
  <h1>Ansible ssh // push</h1>
  
  <p>Ansible started off by doing everything via <code>ssh</code>.  In this style of Ansible the completion state on the "controlled" node would be unknown but from the perspective of the user running ansible that node would clearly need to be retried.  Ansible creates a file for you with all of the hosts that need to be retried.</p>
  
  <h1>Ansible in cron // pull</h1>
  
  <p>If you're running Ansible from a <code>cron</code> job then it will face similar issues to the classic <code>chef-client</code>.  The node will need to phone home to find roles and updates, but it will time out and retry later.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-02-17T13:12:19.180Z
Answers: Thank you very much. This answer gives me a very helpful mindset. Maybe rather than depending on whether the tool makes sure configuration is applied no matter what, sysadmin should make sure of that themselves (by re-applying the config, such as with the case of Ansible). I guess official reference is hard to find, anyway.
Answers: Tran Triet
Answers: CC BY-SA 4.0
Answers: 2019-02-17T15:22:17.333Z
Answers: I missed that you asked for references too.  I've spent lots of times in the docs for ansible and chef and I don't recall anything that would help with this.
Answers: chicks
Answers: CC BY-SA 4.0
Answers: 2019-02-16T17:15:28.557Z
Answers: 2019-02-16T17:15:28.557Z
Answers: chicks
Body: <p><strong>Scenario</strong></p>
  
  <p>Configuration management tools like Ansible or Chef often have a master/controlling machine and the machines they are controlling (agents). </p>
  
  <p><strong>Question</strong></p>
  
  <p>What if the connection between master and agents is lost during pulling or pushing configuration? Will the agents themselves carry on applying the configuration or will they stop?</p>
  
  <p>Please give me the answer for the above question in regard to Ansible and Chef with reference.</p>
  
Tags: <ansible><chef><configuration-management>
Title: Chef vs Ansible: will configuration be applied if connection is lost during configuration pulling/pushing?
UserDisplayName: Tran Triet
ThreadText: # Chef vs Ansible: will configuration be applied if connection is lost during configuration pulling/pushing?
  
  (Asked by: username_0 on 2019-02-16)
  
  **Scenario**
  
  Configuration management tools like Ansible or Chef often have a master/controlling machine and the machines they are controlling (agents).
  
  **Question**
  
  What if the connection between master and agents is lost during pulling or pushing configuration? Will the agents themselves carry on applying the configuration or will they stop?
  
  Please give me the answer for the above question in regard to Ansible and Chef with reference.
  
  **Tags:** ansible, chef, configuration-management
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-02-16. Score: 1 | Accepted answer
  
  The safest assumption to make here is that the configuration is not applied completely and you should try again once the network is back. You can set things up to work without the network, but why go to that work when it will try again for you in a few minutes?
  
  # Chef
  
  Chef tends to be run in the client-server mode as you describe so the `chef-client` agent on the "controlled" machine would keep running. It would get stuck when it needed to get cookbooks or figure out which roles were assigned. It will eventually time out and the chef run will fail. Then it would try again in a few minutes. By default the agent tries to do a chef run every 30 minutes.
  
  If you're using `chef-zero` instead of the client-server style of chef then you could have everything staged on the "controlled" machine so that any network interruption wouldn't break it because of chef itself. You might still have network dependancies in the cookbooks used.
  
  # Ansible ssh // push
  
  Ansible started off by doing everything via `ssh`. In this style of Ansible the completion state on the "controlled" node would be unknown but from the perspective of the user running ansible that node would clearly need to be retried. Ansible creates a file for you with all of the hosts that need to be retried.
  
  # Ansible in cron // pull
  
  If you're running Ansible from a `cron` job then it will face similar issues to the classic `chef-client`. The node will need to phone home to find roles and updates, but it will time out and retry later.
  
  > **Comments:**
  > **username_0**: Thank you very much. This answer gives me a very helpful mindset. Maybe rather than depending on whether the tool makes sure configuration is applied no matter what, sysadmin should make sure of that themselves (by re-applying the config, such as with the case of Ansible). I guess official reference is hard to find, anyway.  
  > **username_1**: I missed that you asked for references too.  I've spent lots of times in the docs for ansible and chef and I don't recall anything that would help with this.  
  
  ---
  
  