The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Bug #20199

There's no way to set resolution_type when using data bindings

Added by eric sorenson about 3 years ago. Updated over 2 years ago.

Status:InvestigatingStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:2.0.0
Keywords: Affected Hiera Version:
Branch:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket is now tracked at: https://tickets.puppetlabs.com/browse/HI-118


Description

Because it’s the responsibility of the caller to set resolution_type in hiera, and there is no explicit caller when using data bindings, there’s no way to tell hiera to use the array (append) or hash (merge) resolutions. This is a pretty bad flaw as it prevents sophisticated lookups like deep merges (or, well, any merges at all) when using the fancy data bindings.

History

#1 Updated by Anonymous about 3 years ago

eric sorenson wrote:

Because it’s the responsibility of the caller to set resolution_type in hiera, and there is no explicit caller when using data bindings, there’s no way to tell hiera to use the array (append) or hash (merge) resolutions. This is a pretty bad flaw as it prevents sophisticated lookups like deep merges (or, well, any merges at all) when using the fancy data bindings.

IMO, this shows up because Hiera puts the merge decision in the wrong damn place. It carefully builds a system where you cannot use Hiera to separate implementation and configuration between the module author and the person supplying data via Hiera. Why?

Because the resolution_type decision is a data structuring decision, but it is expressed in the implementation. That is, the author of the Puppet code – the consumer of Hiera functions – makes the decision about how hash and array handling is done. Boom, now they have dictated the logical structure and use of data in Hiera. You wanted to have manual overrides? Bad luck, we merge here. Oh, you wanted to accumulate data? Bad luck, we just use the closes match in this module.

Much better, instead, to accept that this highlights the correct division of responsibility: resolution_type belongs in the hands of the person supplying the data. The Puppet code – the module – should just ask for the data, and document what it does with the final, flattened result.

That actually separates the roles: now the module author isn’t deciding that this value is generated by collecting all unique values up the hierarchy (which they don’t define) based on the way I lay out my Hiera data (which they don’t define). They give me the control to express that.

This is more complex, in places, because now the Hiera data inputs need to define not only the data, and the hierarchy, but how they merge those hierarchical values in exceptional cases – but it leads to a meaningful separation of responsibility.

Without it, the idea that code and data are separated with Hiera remains a pretty illusion.

#2 Updated by eric sorenson over 2 years ago

Redmine Issue #20199 has been migrated to JIRA:

https://tickets.puppetlabs.com/browse/HI-118

Also available in: Atom PDF