In regard to: [Puppet Users] Re: Getting all variable occurrences from...:
That yaml file should keep alle the specific params of that host. and
every other module should be able to take advantage of that information.
This is not only the case for dhcp, but for dns as well. and of course the
/etc/network/interfaces file of the host itself.
And to avoid needless redundancy of information, certain values should be
written into that file maximum once. so, the ipaddress for example must not
be written in some dns config yaml file as well. and in the hostname.yaml.
Should you decide to change the ipaddress, you definitely forget either the
bind or the dhcp config.
Certainly data duplication should be avoided, and that could be aided by
putting all information for each host into a single hash for that host.
Those per-host hashes could equally well (for this purpose) appear in
separate YAML files or all together as values in a larger hash in one YAML
file.
Agreed, for the original case.
However, the original suggestion matches closely with an issue I've run
into as well, which also had me thinking that something like "hiera_all"
(I was thinking it should be "hiera_merge") would be needed.
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, so you design things like this
common.yaml:
ntp_type: client
ntp_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
As I've said before on the list, this strikes me as a bit unnatural.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
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.
