-
Type:
Bug
-
Status: Closed
-
Priority:
Normal
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: PUP 4.10.10, PUP 5.3.4, PUP 5.4.0
-
Component/s: None
-
Labels:None
-
Template:customfield_10700 224656
-
Team:Platform Core
-
Sprint:Platform Core KANBAN
-
Method Found:Needs Assessment
-
Release Notes:Bug Fix
-
Release Notes Summary:The validation of uri/uris in a hiera 5 hiera.yaml was too strict and did not allow reference / partial URIs to be used (for example only containing a path).
-
QA Risk Assessment:No Action
The documentation for configuring a Hiera 5 hierarchy level can be found here. In these docs, the uris key is described as appropriate for "[...] any kind of data source. Hiera doesn’t ensure URIs are resolvable before calling the backend, and doesn’t need to understand any given URI schema."
However, in implementation the uris key is not implemented this way, and seems to require that values match a preconception of what a URI is.
---
|
version: 5
|
|
|
defaults:
|
datadir: "data"
|
|
|
hierarchy:
|
- name: 'Consul backend'
|
lookup_key: consul_lookup_key
|
uris:
|
- "/v1/kv/configuration/%{fqdn}"
|
- "/v1/kv/configuration/common"
|
[cloud-user@master-of-puppets-aws-1 work]$ puppet lookup --hiera_config=hiera.yaml --modulepath=modules test --explain
|
Error: Could not run: Lookup of key 'lookup_options' failed: The Lookup Configuration at '/home/cloud-user/work/hiera.yaml' has wrong type, entry 'hierarchy' index 0 entry 'uri' exp
|
ects a match for Pcore::URI = Pattern[/(?x-mi:
|
([a-zA-Z][\-+.a-zA-Z\d]*): (?# 1: scheme)
|
(?:
|
((?:[\-_.!~*'()a-zA-Z\d;?:@&=+$,]|%[a-fA-F\d]{2})(?:[\-_.!~*'()a-zA-Z\d;\/?:@&=+$,\[\]]|%[a-fA-F\d]{2})*) (?# 2: opaque)
|
|
|
(?:(?:
|
\/\/(?:
|
(?:(?:((?:[\-_.!~*'()a-zA-Z\d;:&=+$,]|%[a-fA-F\d]{2})*)@)? (?# 3: userinfo)
|
(?:((?:(?:[a-zA-Z0-9\-.]|%\h\h)+|\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}|\[(?:(?:[a-fA-F\d]{1,4}:)*(?:[a-fA-F\d]{1,4}|\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})|(?:(?:[a-fA-F\d]{1,4}:)*[a-fA-F\d]{1,4})?::(?:(?:[a-fA-F\d]{1,4}:)*(?:[a-fA-F\d]{1,4}|\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}))?)\]))(?::(\d*))?))? (?# 4: host, 5: port)
|
|
|
((?:[\-_.!~*'()a-zA-Z\d$,;:@&=+]|%[a-fA-F\d]{2})+) (?# 6: registry)
|
)
|
|
|
(?!\/\/)) (?# XXX: '\/\/' is the mark for hostport)
|
(\/(?:[\-_.!~*'()a-zA-Z\d:@&=+$,]|%[a-fA-F\d]{2})*(?:;(?:[\-_.!~*'()a-zA-Z\d:@&=+$,]|%[a-fA-F\d]{2})*)*(?:\/(?:[\-_.!~*'()a-zA-Z\d:@&=+$,]|%[a-fA-F\d]{2})*(?:;(?:[\-_.!~*'()a-zA-Z\d:@&=+$,]|%[a-fA-F\d]{2})*)*)*)? (?# 7: path)
|
)(?:\?((?:[\-_.!~*'()a-zA-Z\d;\/?:@&=+$,\[\]]|%[a-fA-F\d]{2})*))? (?# 8: query)
|
)
|
(?:\#((?:[\-_.!~*'()a-zA-Z\d;\/?:@&=+$,\[\]]|%[a-fA-F\d]{2})*))? (?# 9: fragment)
|
)/], got '/v1/kv/configuration/common'
|
As a custom backend author, I read the documentation for uris as a standardized key that I can use to specify "levels" for my backend, where the format and validation of strings representing levels is left to me. However, the implementation prevents this.
There should be a standard key that can be used to describe levels, for which format and validation of entries is left to the backend. If uris is already this key, the undocumented type checking is a bug that needs to be removed before it can be effectively used.
