On Friday, August 17, 2012 1:26:21 PM UTC-5, Tim Mooney wrote:
>
>
> Consider:
>
> :hierarchy: - secure/fqdn/%{clientcert}
> - fqdn/%{clientcert}
> - secure/location/%{location}
> - location/%{location}
> - secure/common
> - common
>
>
> common.yaml:
> ---
> ntp:
> type: client
> servers:
> - 10.0.0.1
> - 10.0.0.2
>
> location/datacenter1.yaml:
> ntp:
> servers:
> - 10.1.0.101
> - 10.1.0.102
>
> fqdn/clock1.example.com.yaml:
> ntp:
> type: server
>
>
>
>
> Hopefully, the intent is relatively clear: the defaults for all systems
> are to be an ntp client and to use ntp servers with the IP addresses from
> the common.yaml, however everyone in location=datacenter1 should have
> the list of servers overridden, and the one system with
> fqdn=clock1.example.com should have its type=server.
>
> As hiera currently works, I don't believe there's any way to "merge" these
> types of nested data from multiple sources in the hierarchy. If I try
> lookup ntp['type'] for any of the systems in location=datacenter1, it
> will be empty, because type is not specified (duplicated) for the
> location/datacenter1.yaml.
>
> Because of this, what ends up happening is that you instead need to use
> a flat namespace
>
Well, yes, because a flat namespace is all that hiera natively provides.
Although an hierarchical namespace might be useful,
1. I am not in favor of implementing such a thing via the same
structures that are used to define complex data values. When I write or
read an Hiera YAML file, I don't want to be uncertain about what is data
and what is name.
2. You can use the structure of your data names to provide for
namespacing, however, as in fact your example does. Although that seems
unnatural to you, it seems perfectly natural to me. Perhaps it's just a
question of mindset and perspective.
3. Alternatively, you could use hiera_array() to obtain all the
applicable values for the "namespace" object you want, and merge them via a
separate function call. I wouldn't think the needed function would be hard
to write. Inasmuch as that function would look a lot like parts of hiera's
existing internals, perhaps it would make sense to have hiera provide it.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/vhlm56eROs4J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
