Only accept MM/DD/YYYY for windows_task start_day

[jaym]

DateTime.parse is not really that well defined. It accepts a lot
of different dates, however not MM/DD/YYYY. It does DD/MM/YYYY.
We should be very specific in the format we accept, and continue
to support MM/DD/YYYY as it was in the cookbook

Fixes chef-boneyard/chef-client#523

[harikesh-kolekar]

@jaym If we fix the start_day format to mm/dd/yyyy, won't it break the windows_task resource for some users whose system date format wasn't mm/dd/yyyy? e.g. suppose the system date format for a particular region was dd/mm/yyyy and some users in that region were using windows_task resource with dd/mm/yyyy date format only. In this case, their recipes would have been working earlier but will break after this change.

[NimishaS]

Please note that windows_cookbook documentation also mentioned that the format for start_day should be mm/dd/yyyy: https://github.com/chef-cookbooks/windows#properties-12.
We can probably go with assumption that people should have been using the same format as documented.

[jaym]

If DD/MM/YYYY happened to work for those who used the windows cookbook, this change will break them. Since the documentation says MM/DD/YYYY, I think they were relying on a bug for things to work, so the question is do we want to be bug backwards compatible?

[tas50]

Seems like this might break users that were using the previous undocumented behavior, but that's the least bad end result.

[Chef-Mike]

I have some nodes affected by this. Will there be a new chef-client installer released?
or how can I get this resolved?
Do we need to increment metadata.rb on the chef-client cookbook to 8.1.9?

[tas50]

If you want to give it a try checkout a build from our current channel at https://downloads.chef.io/chef/current

[Chef-Mike]

it works, thanks!

[lamont-granquist]

ETA is most likely early next month for a release (we have a monthly release tempo for everything other than high severity security issues)

[spotlesscoder]

Any chance this gets released earlier? That was already the third major problem I had with chef within the last 2 days.

The chef_client cookbook also is based on the windows cookbook. Due to that date format change, I could not bootstrap my Win2012R2 nodes in such a way that they make use of the chef-client recipe in my role which should have configured them in such a way that they would run chef-client every 5 minutes.

At the moment, I need to install the prerelease (13.5.22) version of chef-client manually on every bootstrapped node and run chef-client manually once more to make it work again. This just takes too much time.

[btm]

@CodingSpiderFox how are you installing Chef? You could use knife bootstrap --bootstrap-version 13.5.22 --prerelease to install a specific version rather than installing the latest stable and reinstalling another version later.

The cadence for Chef releases is monthly. 13.5 was released 16 days ago, a bit late. The next 13 release should be happening soon.

[spotlesscoder]

Ah, I was missing the --prerelease, that's why it didn't work with specifying the 13.5.22 version.
Maybe knife could at least have warned me that I'm trying to install a prelease version and I need to add "--prerelease" to do so. Especially people new to chef don't know all the options

[spotlesscoder]

@btm: It did not help to bootstrap with specifying v. 13.5.22.

knife bootstrap windows winrm <IP> -x '<DOMAIN>\<USER>' --bootstrap-proxy <PROXY> --bootstrap-no-proxy '<chef_server_ip>,<local_networks>' --run-list 'role[<ROLE>],' --node-ssl-verify-mode none --environment <ENVIRONMENT> --node-name <HOSTNAME> --bootstrap-version=13.5.22 --prerelease -V

The windows task for chef-client run is created but when it executes the first time after 5 minutes (and every further time), I get the following error:

(see attached client.log and stacktrace.out)

System language is English but date/time/currency etc. is German. OS ist Windows Server 2012 R2

client.log
stracktrace.txt

This has become a major issue for us.

Bootstrapping with the version 13.4 (resolved to 13.4.24) worked for us but the newer versions need to be fixed.

[btm]

@CodingSpiderFox Can you please open a separate issue up and include a client log with -l debug? I'll get it on a team board soon.

[spotlesscoder]

So simply run the chef client manually with -l debug attached to the command I use?

[btm]

@CodingSpiderFox yup! chef-client -l debug .... will produce much more verbose output and will save the developer working on it from having to ask a number of questions.

[spotlesscoder]

What kind of confidential data do I need to wipe out in the logs?

What about the X-Ops-Authorization-1 etc. headers? Should I remove them?

[spotlesscoder]

Opened issue: #6513