I'm bootstrapping infrastructure environments (Windows Server instances on EC2) that run cookbooks during the Acceptance, Union, Rehearsal, and Delivered stages from the Chef Automate pipeline.
I've been able to do this using Linux instances (tried CentOS 7 and Ubuntu 14.04) without issue. However, when I tried Windows, 2 of my 4 environments failed due to Timeout::Error:
My concern is that this happened two times out of four. Setting up push jobs client on Windows Server is part of an upcoming Learn Chef tutorial, and I fear this issue will affect tutorial users.
Because running chef-client does not repair the system, I've needed to spin up brand new instances in order to continue. This is not an acceptable work-around for users.
Can this issue be fixed? If not, is there a reasonable workaround?
Steps to Reproduce:
You can likely reproduce this in a local environment, but here are the steps I'm using:
Spin up a Windows Server 2012 R2 instance on EC2. I'm using a t2.medium instance size.
Open ports 443 (HTTPS), 3389 (RDP), and 5985 (WinRM) through the security group.
Upload the push-jobs cookbook to Chef server. I'm using delivery-base, which includes push-jobs.
Bootstrap your node, including the push-jobs cookbook in the run-list. The gist above has an example.
If the bootstrap process fails, run chef-client a second time. The gist above has an example.
Expected Result:
Push jobs should be set up on the Windows Server node.
Actual Result:
For me, more than 50% of the time the bootstrap process fails due to Timeout::Error, and chef-client is unable to repair the configuration.
Cookbook version
3.3.0, included by using
delivery-base
0.2.2Chef-client version
12.18.31
Platform Details
Windows Server 2012 R2 on EC2
Scenario:
I'm bootstrapping infrastructure environments (Windows Server instances on EC2) that run cookbooks during the Acceptance, Union, Rehearsal, and Delivered stages from the Chef Automate pipeline.
I've been able to do this using Linux instances (tried CentOS 7 and Ubuntu 14.04) without issue. However, when I tried Windows, 2 of my 4 environments failed due to
Timeout::Error
:https://gist.github.com/tpetchel/c0624428d4859e6d6704655beb181dd3#file-knife-bootstrap
Running
chef-client
a second time on the node is unable to patch the system.https://gist.github.com/tpetchel/c0624428d4859e6d6704655beb181dd3#file-knife-winrm
My concern is that this happened two times out of four. Setting up push jobs client on Windows Server is part of an upcoming Learn Chef tutorial, and I fear this issue will affect tutorial users.
Because running
chef-client
does not repair the system, I've needed to spin up brand new instances in order to continue. This is not an acceptable work-around for users.Can this issue be fixed? If not, is there a reasonable workaround?
Steps to Reproduce:
You can likely reproduce this in a local environment, but here are the steps I'm using:
t2.medium
instance size.push-jobs
cookbook to Chef server. I'm usingdelivery-base
, which includespush-jobs
.push-jobs
cookbook in the run-list. The gist above has an example.chef-client
a second time. The gist above has an example.Expected Result:
Push jobs should be set up on the Windows Server node.
Actual Result:
For me, more than 50% of the time the bootstrap process fails due to
Timeout::Error
, andchef-client
is unable to repair the configuration.