[PUP-7165] a hiera.yaml v3 in the root of an env should be under control of --strict Created: 2017/02/02  Updated: 2017/02/10  Resolved: 2017/02/07

Status: Closed
Project: Puppet
Component/s: None
Affects Version/s: PUP 4.9.0
Fix Version/s: PUP 4.9.2

Type: Bug Priority: Major
Reporter: Henrik Lindberg Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Acceptance Criteria:

--strict controls if a hiera.yaml v3 in an environment root leads to error or warning.

Epic Link: Productize 'lookup'
Team: Puppet Developer Experience
Story Points: 1
Sprint: PDE 2017-02-08
Release Notes: Bug Fix
Release Notes Summary: Having a hiera.yaml (version 3) in the root of an environment led to a hard error since hiera 5 requires that such a file has format 5 for it to be used with the new features in hiera.
This is now changed so that a version 3 file is ignored and a warning is issued if --strict=warning, and an error is raised only if --strict==error.
QA Risk Assessment: No Action
QA Risk Assessment Reason: covered by unit tests


Many people use a pattern of having a hiera.yaml (v3) in the root of their control repo for the purpose of symlinking it to the global hiera.yaml location setting path.

Puppet 4.9.0 takes a hiera.yaml in an environment root as an error if the file is of version 3.
This means that users upgrading to puppet 4.9.0 may have a large number of environments to clean up before they can run puppet 4.9.0.

We should fix this problem by letting the --strict flag control the behavior. When it is set to error it should behave as it is currently doing in 4.9.0. When set to warning it should log a warning, and continue as if the file was not there.

Comment by Thomas Hallgren [ 2017/02/02 ]

I assume that this should be controlled by the global hiera_config setting? I.e. it appoints a hiera.conf in the environment, then it's a warning (or error when --strict). If it doesn't, then it's an error regardless of strict setting.

Comment by Thomas Hallgren [ 2017/02/02 ]

Also, I assume that the same is true regardless of what version the hiera.conf file is. It's simply not OK to have the hiera_config setting point into an environment root (or a module root for that matter).

Comment by Henrik Lindberg [ 2017/02/02 ]

No, not correct. People keep a hiera.yaml file there for the purpose of copying it manually (or symlinking it). The fact that hiera_config points there or someplace else (most likely someplace else) is irrelevant.

The issue is not that hiera_config points into an environment (a seriously stupid thing to do), but that is not what needs to be fixed. Leave that as it is.

Comment by Thomas Hallgren [ 2017/02/02 ]

OK, but if pointing to a root is a seriously stupid thing to do, then why not warn about that too? I bet there are use-cases out there that does that instead of symlinking.

Comment by Thomas Hallgren [ 2017/02/02 ]

Henrik Lindberg, just to clarify, --strict set to off would just silently ignore the file?

Comment by Henrik Lindberg [ 2017/02/02 ]

better to warn even if --strict is set to off I think

Comment by Henrik Lindberg [ 2017/02/02 ]

The other issue - don't point into the env for the global hiera is a separate issue and it needs to be discussed - people may do that and have only a single environment etc. so needs to be communicated first with a wider audience. It is probably not worth the trouble.

Comment by Henrik Lindberg [ 2017/02/02 ]

merged to stable at: 30064fa

Generated at Tue Jul 14 03:30:07 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.