We are happy to announce the release of Chef Automate 0.7.85. This is primarily a critical bugfix release due to an error introduced in 0.7.61, where FIPS 140-2 mode was accidentally enabled for all new runner installations. The release is available for download from Download Chef Automate | Chef.
New Features
Preview of New UI
We are starting work to improve the look-and-feel of Chef Automate, so you will see some UI changes in the Nodes tab.
Configurable Elasticsearch snapshot timeouts
In cases where the Chef Automate Elasticsearch cluster has several hundred snapshots, the data deltas between snapshots are significant in size, and the snapshot repository is in s3, we've encountered cases where the default Faraday gem transport timeout of 60 seconds is too small which causes the snapshot utility to raise an error and fail. We've introduced configuration attributes for controlling the Faraday request timeout and the nginx Elasticsearch proxy timeouts. These have been bumped to 300 seconds by default, which should resolve this issue for most cases. Extremely busy Chef Automate clusters or instances with low I/O to S3 may need to bump them. It also increases the default timeout from 60 to 300. They can be configured in delivery.rb as follows:
elasticsearch['proxy_send_timeout'] = 300
elasticsearch['proxy_read_timeout'] = 300
backup['elasticsearch']['request_timeout'] = '300'
Bug Fixes
Runners no longer install in FIPS mode when FIPS is not enabled
Chef Automate 0.7.61, which shipped with FIPS 140-2 early access, would install all runners in FIPS mode, regardless of whether FIPS was enabled or not. This has now been corrected.
Run history now defaults to last 24h
Previously, Chef Automate would default to displaying run history data for the current day, cutting off at the prior midnight. Automate now defaults to displaying run history data for the past 24h instead.
Improved pre-flight-check memory detection
For operating systems reporting available memory in KB instead of GB, Chef Automate’s preflight check reported sufficient memory even though it did not meet the minimum requirements. This version of Chef Automate corrects the problem.
We encourage you to upgrade often. As always, we welcome your feedback and invite you to contact us directly or participate in our feedback forum. Thanks for using Chef Automate!
Opsworks: Chef Automate backups occasionally aren't deleted
Occasionally the Chef Automate backup archives were not being deleted. This is likely due to the fact that retries and exponential retry backoff was only being used for upload S3 operations.
We've consolidated all S3 operations into the Backup::S3Client class which defaults to exponential backoff with five retries.
Automate backup lists are limited to 1000
The maximum response size when using the V2 S3 list objects API is 1000. We've added paging support for listing objects to support extremely rare cases where a user may have more than 1000 backups.
automate-ctl delete-backups exits with 0 if no match is found
We've changed the delete-backups command to exit with 1 when given a pattern.