[SERVER-1690] CLI subcommands produce confusing failures when puppetserver config corrupted Created: 2016/12/05 Updated: 2017/06/28 Resolved: 2016/12/08
|Fix Version/s:||SERVER 5.0.0|
|Reporter:||Jeremy Barlow||Assignee:||Jeremy Barlow|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Release Notes:||Bug Fix|
|Release Notes Summary:||When puppetserver CLI commands were invoked they did not account for errors raised when loading and validating the puppetserver config. Because of this if an invalid configuration was present and a CLI subcommand was run, the subcommand would crash with an unhelpful error message unrelated to the actual config validation failure. This has been fixed so that errors with an unexpected format, such as errors generated while validating the config, are propagated up the stack without modification.|
|QA Risk Assessment:||Needs Assessment|
When one of the CLI subcommands is run and a puppetserver config file which has content that violates a schema is parsed, the resulting failure shown on the command line does not give any indication of what the real error is.
For example, I ran the following steps in Puppet Server at the 2.7.1 tag, from source:
1) Set the following bogus variable value in the ./dev/puppetserver.conf file:
2) Ran the gem subcommand as follows:
An error message indicating something about the corrupt master-conf-dir variable value.
|Comment by Jeremy Barlow [ 2016/12/08 ]|
Merged to puppetserver#master at 54ec8ff.
Tests all passing through the full Jenkins pipeline: https://jenkins-master-prod-1.delivery.puppetlabs.net/view/puppetserver/view/all/job/platform_puppetserver_integration-system_no-conditional_full-master/51/.
Loaded puppetserver 2.7.2.master.SNAPSHOT.2016.12.08T1059 on a CentOS 7 VM and re-ran the test scenario from the description. Note that the error message is more informative with this change, even if still not the most user-friendly as is the case with Prismatic schema-derived messages in general: