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:

Feature #18793

Hiera deep merge on hash doesn't have a "whiteout" or "remove this key" value

Added by Anonymous over 3 years ago. Updated over 2 years ago.

Status:Needs More InformationStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:hiera
Target version:-
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-128


Description

Issue #16107 is a great improvement to Hiera, and almost meets my needs. All I need now is for you to add the ability to remove a key as you merge down hash values, and it would be awesome.

Basically, allow me to specify that the merge should “remove” a key, or a branch, rather than just plain overwriting it.

(It would be great to implement the full suite of set operations, of course; and, or, xor, and not, but just allowing not would be a great start.)


Related issues

Related to Hiera - Feature #16107: hiera should support merging different keys from nested d... Closed 08/23/2012
Related to Hiera - Feature #10362: Type resolution should be outside of the backend Investigating 10/28/2011

History

#1 Updated by Anonymous about 3 years ago

  • Tracker changed from Bug to Feature
  • Description updated (diff)
  • Status changed from Unreviewed to Investigating
  • Assignee set to Anonymous

How would you imagine specifying the “not” behavior? Would this be a part of making the query? Perhaps something like:

... = hiera_hash('interfaces', 'without eth1')

Or would this be part of the hierarchy declaration:

:hierarchy: - global
                 - local:
                     without: eth1

#2 Updated by Anonymous about 3 years ago

  • Status changed from Investigating to Needs More Information

#3 Updated by Anonymous about 3 years ago

Sorry to have missed the earlier question. This is the obvious extension to the feature added in #16107, so to use their example:

In common.yaml we see these defaults:

---
sandbox_tvm:
  master:
    version: 1.2.3
    name: foo.bar.edu

…and I wish to have a fqdn/foo.bar.edu.yaml that results in the same final set of values that this YAML would:

---
sandbox_tvm:
  master:
    name: foo.bar.edu

That is, I have “removed” the version key from the master map, by declaring in the fqdn/%{clientcert} file that it should be absent.

This allows defaults to be established with exceptions for specific nodes, rather than having to duplicate data; the alternative where some-but-not-all nodes need a version is to copy the same version data into every single node file by hand, which isn’t exactly awesome, or to add another layer of complexity to the hierarchy to merge in that one key for some-but-not-all nodes.

#4 Updated by Anonymous over 2 years ago

Redmine Issue #18793 has been migrated to JIRA:

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

Also available in: Atom PDF