Puppet users - Aug 2012 - Getting all variable occurrences from Hiera

Hello,

We''ve been using Hiera for a while and one of the things I''d
like to do is
use the data we have in the YAML backend and generate our BIND zonefiles 
and DHCPD.conf from it.

Every node has a stanza defined with it''s ''primary''
IP-address and
MAC-address like so:
hostname.yaml:
---
m_interface:
  - ip: 127.0.0.1
  - mac_address: aa:bb:cc:dd:ee:ff

Based on that information and the YAML file it was found in (so the node in 
our case) I''d like to generate a dhcpd.conf like this:

host hostname(.yaml) {
  fixed-address: m_interface[ip]
  hardware ethernet: m_interface[mac_address]

Now, this can be done for a single node, however, I need a way to get that 
information for every node. As far as I understand both hiera_hash and 
hiera_array only walk the hierarchy upwards, not outwards (which is usually 
what you want anyway).

I''m looking for something like a hiera_all that would return a hash
with
the node name as key and value the m_interface stanza for that node.

At this point I''m not even sure this can be done so, anyone got any
bright
ideas?


Kind regards,

-- 
Daniele Sluijters

-- 
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/-/UujM_sYrG7QJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thursday, August 16, 2012 3:37:23 AM UTC-5, Daniele Sluijters
wrote:
>
> Hello,
>
> We''ve been using Hiera for a while and one of the things
I''d like to do is
> use the data we have in the YAML backend and generate our BIND zonefiles 
> and DHCPD.conf from it.
>
> Every node has a stanza defined with it''s
''primary'' IP-address and
> MAC-address like so:
> hostname.yaml:
> ---
> m_interface:
>   - ip: 127.0.0.1
>   - mac_address: aa:bb:cc:dd:ee:ff
>
> Based on that information and the YAML file it was found in (so the node 
> in our case) I''d like to generate a dhcpd.conf like this:
>
> host hostname(.yaml) {
>   fixed-address: m_interface[ip]
>   hardware ethernet: m_interface[mac_address]
>
> Now, this can be done for a single node, however, I need a way to get that 
> information for every node. As far as I understand both hiera_hash and 
> hiera_array only walk the hierarchy upwards, not outwards (which is usually
> what you want anyway).
>
> I''m looking for something like a hiera_all that would return a
hash with
> the node name as key and value the m_interface stanza for that node.
>
> At this point I''m not even sure this can be done so, anyone got
any bright
> ideas?
>
>
At first glance this looks like a good use case for exported resources and 
the Concat module.  Each node would export a file fragment containing its 
stanza of dhcpd.conf.  The DHCP server would collect all the fragments and 
use them to define the target file.

If you''re not already using [thin] storeconfigs, however, then you will
need to set that up to use exported resources.  That is not entirely 
trivial to set up or to run.  Also, this solution requires that nodes be 
able sync with the master before their information is added to the DHCP 
server, and given the nature of DHCP, that might not be possible.

On the other hand, if all the hiera data is for the DHCP server''s
benefit
in the first place, instead of for the nodes themselves, then it may be 
easier simply to restructure the data.  Instead of putting all your node 
information into separate files, you could put it all into one hash in one 
file:

interfaces.yaml:
---
interfaces: {
    host1: {
        ip: 127.0.0.1
        mac_address: aa:bb:cc:dd:ee:ff
      }
    host2: {
        ip: 127.0.0.2
        mac_address: aa:bb:cc:dd:ee:fe
      }
  }

You would then load the hash via a single hiera() call, and use a template 
to unpack and format the results.

That sort of arrangement of your data could even be made to work if the 
individual nodes and the DHCP server need to share.  The nodes would have 
to extract the data differently (get the hash via hiera(), then select 
their own entry, and within it the particular values they want), but it 
should be doable.


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/-/1q9B2CURtBoJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi,

We already used stored configs but we can''t use it for DHCP and DNS
because
those records need to be created before the node actually syncs for the 
first time, even before it''s installed with an OS to begin with.

I hadn''t thought of just separating that information into its own YAML 
file, that''s an interesting solution and one I''ll definitely
be looking
into to.

-- 
Daniele Sluijters

On Thursday, 16 August 2012 10:37:23 UTC+2, Daniele Sluijters
wrote:
>
> Hello,
>
> We''ve been using Hiera for a while and one of the things
I''d like to do is
> use the data we have in the YAML backend and generate our BIND zonefiles 
> and DHCPD.conf from it.
>
> Every node has a stanza defined with it''s
''primary'' IP-address and
> MAC-address like so:
> hostname.yaml:
> ---
> m_interface:
>   - ip: 127.0.0.1
>   - mac_address: aa:bb:cc:dd:ee:ff
>
> Based on that information and the YAML file it was found in (so the node 
> in our case) I''d like to generate a dhcpd.conf like this:
>
> host hostname(.yaml) {
>   fixed-address: m_interface[ip]
>   hardware ethernet: m_interface[mac_address]
>
> Now, this can be done for a single node, however, I need a way to get that 
> information for every node. As far as I understand both hiera_hash and 
> hiera_array only walk the hierarchy upwards, not outwards (which is usually
> what you want anyway).
>
> I''m looking for something like a hiera_all that would return a
hash with
> the node name as key and value the m_interface stanza for that node.
>
> At this point I''m not even sure this can be done so, anyone got
any bright
> ideas?
>
>
> Kind regards,
>
> -- 
> Daniele Sluijters
>
-- 
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/-/oujPthWMq6wJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

>
>
> I hadn''t thought of just separating that information into its own
YAML
> file, that''s an interesting solution and one I''ll
definitely be looking
> into to.
>
> But then, information about one host is kept in multiple files and it 
would be my aim to wrap all specific info for one host into one yaml. so 
that once you remove the host, you only have to remove that file.
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.

I realize that this might lead into a feature req for Hiera. 
There must simply be a way to tell the dhcp and bind modules to have a look 
in all hostname.yaml files to collect all ipaddresses and macaddresses and 
hostnames.

Best regards,
Alex

-- 
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/-/u-KBZGO95uoJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi,

True, however, that is already the case. A host right now is made up of two 
YAML files. Nevertheless I agree it would be nice to keep all information 
relevant to a specific node contained in its own YAML.

I could easily create something that would just parse the files and 
generate DHCPD and DNS files from them without going through Puppet but 
that defeats the purpose. Plus one''d have to remember to run that code 
before committing.

-- 
Daniele Sluijters

On Thursday, 16 August 2012 23:08:26 UTC+2, Alexander Swen
wrote:
>
>
>> I hadn''t thought of just separating that information into its
own YAML
>> file, that''s an interesting solution and one I''ll
definitely be looking
>> into to.
>>
>> But then, information about one host is kept in multiple files and it 
> would be my aim to wrap all specific info for one host into one yaml. so 
> that once you remove the host, you only have to remove that file.
> 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.
>
> I realize that this might lead into a feature req for Hiera. 
> There must simply be a way to tell the dhcp and bind modules to have a 
> look in all hostname.yaml files to collect all ipaddresses and macaddresses
> and hostnames.
>
> Best regards,
> Alex
>
-- 
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/-/hW_VCzOnl4MJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thursday, August 16, 2012 4:08:26 PM UTC-5, Alexander Swen
wrote:
>
>
>> I hadn''t thought of just separating that information into its
own YAML
>> file, that''s an interesting solution and one I''ll
definitely be looking
>> into to.
>>
>> But then, information about one host is kept in multiple files and it 
> would be my aim to wrap all specific info for one host into one yaml. so 
> that once you remove the host, you only have to remove that file.
>

As much or as little information about the hosts as is wanted can be put in 
the one big hash, so host information does not need to be split up.  If 
everything went into one hash then removing info for a host would involve 
removing one block of lines from one file.  That''s only a little less 
convenient than removing a single file, and it could be automated 
relatively easily.

Please understand that I don''t have any stake in what approach Daniele 
chooses.  I am not advocating for a particular approach, nor asserting it 
superior over any other that also achieves the desired result, but I do 
hope that Daniele and others who may read this thread will base their 
decisions on solid reasoning.

 
> 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.

 
>
> I realize that this might lead into a feature req for Hiera. 
> There must simply be a way to tell the dhcp and bind modules to have a 
> look in all hostname.yaml files to collect all ipaddresses and macaddresses
> and hostnames.
>
>
I suppose you''re suggesting another function similar to hiera_hash(),
in
that it provides the result in the form of a hash that associates the data 
from each yaml with a key that corresponds to the filename.  Hmm, where did 
I see such a data structure described before?

Inasmuch as you can achieve the output you want now, by structuring your 
data the way you want it in the first place, I think this is by no means a 
must-have feature.  If the mode of file organization you describe would be 
of such high value to you, however, then Hiera supports pluggable 
back-ends, so you can easily add that capability.  You could probably get 
80% of the way there by deriving your custom back-end from the current YAML 
back-end.


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/-/lsYFiVADptYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thanks for your reply John,
 
> As much or as little information about the hosts as is wanted can be put 
> in the one big hash, so host information does not need to be split up.  If 
> everything went into one hash then removing info for a host would involve 
> removing one block of lines from one file.  That''s only a little
less
> convenient than removing a single file, and it could be automated 
> relatively easily.
>
> That might be a nice workarround.
Please understand that I don''t have any stake in what approach Daniele
> chooses.  I am not advocating for a particular approach, nor asserting it 
> superior over any other that also achieves the desired result, but I do 
> hope that Daniele and others who may read this thread will base their 
> decisions on solid reasoning.
>
> same here 
>  
>
>>
>>
> 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.
>
> true,  
>  
>
>> I suppose you''re suggesting another function similar to
hiera_hash(), in
>> that it provides the result in the form of a hash that associates the
data
>> from each yaml with a key that corresponds to the filename.  Hmm, where
did
>> I see such a data structure described before?
>>
>
no idea, enlighten me ;-)
>
> Inasmuch as you can achieve the output you want now, by structuring your 
> data the way you want it in the first place, I think this is by no means a 
> must-have feature.  If the mode of file organization you describe would be 
> of such high value to you, however, then Hiera supports pluggable 
> back-ends, so you can easily add that capability.  You could probably get 
> 80% of the way there by deriving your custom back-end from the current YAML
> back-end.
>
Well, I think it is a must-have feature. Just by adding an option, you 
won''t force anyone to actually use it should one not want that off
course.

Best regards, Alex

-- 
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/-/OmH27hXfNIQJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.Mooney@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

>
> 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.

 I''ve just filed a feature 
request: http://projects.puppetlabs.com/issues/16033 please vote on it when 
you need it as well.

-- 
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/-/0_d3_ynteOAJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I''ll comment in the ticket as well, but one problem I have with this 
approach is that hiera doesn''t necessarily have a list of all the
nodes.
It''s an artifact of your data design that the mac/ip for each node is 
available as an enumerable list. In Tim Mooney''s example, which I think
is
the usual case for hiera data, hiera doesn''t have an enumeration of all
the
''type: client'' nodes, nor should it.  

You could pretty easily write a custom parser function to return the data 
structures you want. 

On Monday, August 20, 2012 2:53:20 AM UTC-7, Alexander Swen
wrote:
>
> 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.
>
>
>  I''ve just filed a feature request: 
> http://projects.puppetlabs.com/issues/16033 please vote on it when you 
> need it as well.
>
-- 
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/-/TyA5C59_OgYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

In regard to: Re: [Puppet Users] Re: Getting all variable occurrences from...:
> I''ll comment in the ticket as well,
I see you have, and you''ve closed it out.
> In Tim Mooney''s example, which I think is
> the usual case for hiera data, hiera doesn''t have an enumeration
of all the
> ''type: client'' nodes, nor should it.
What I''m asking for (or at least, about) is indeed somewhat different
than
what Alexander was asking for.

I''m a little surprised at the quick dismissal.  It seems reasonable to
me
that since at least YAML supports data structures *and* puppet supports
hashes and arrays and nesting of same, one might choose to design the
configuration "namespace" for a particular class to use an actual data
structure in hiera.  I''ve been watching the list very closely
for several months for any official statement from Puppetlabs folks about
best practices with hiera data, and your statement is really the first
I''ve seen.

What you''ve said has a pretty clear implication: don''t use
nested data
structures in hiera, because they''re not going to work in the way that
I think most people would expect them to work -- you can''t merge
different
sub-keys from different parts of your hierarchy.

In other words, we shouldn''t use something like this:

ntp:
   type: ''client''
   servers:
     - 10.1.2.3
     - 10.1.2.4
   allow_query:
     - ''10.1.0.0/255.255.0.0''
     - ''10.2.0.0/255.255.0.0''
     - ''10.3.0.0/255.255.0.0''
     - ''2001:4930::/ffff:ffff::''

We should instead use:

ntp_type: ''client''
ntp_servers:
   - 10.1.2.3
   - 10.1.2.4
ntp_allow_query:
   - ''10.1.0.0/255.255.0.0''
   - ''10.2.0.0/255.255.0.0''
   - ''10.3.0.0/255.255.0.0''
   - ''2001:4930::/ffff:ffff::''
> You could pretty easily write a custom parser function to return the data
> structures you want.
Perhaps if I was as adept in ruby as many of the Puppetlabs employees,
that would be pretty easy, but unfortunately I''m not.

I do appreciate the response!  It''s really nice to know the thoughts of
the people that are the experts on this.  It helps me to plan the
direction for our environment.

Tim
-- 
Tim Mooney                                             Tim.Mooney@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Aug 22, 2012, at 3:38 PM, Tim Mooney wrote:
> What I''m asking for (or at least, about) is indeed somewhat
different than
> what Alexander was asking for.
> 
> I''m a little surprised at the quick dismissal.
I do not disagree with what you''ve described below, but I do not think
it''s covered by the problem statement in #16003 -- perhaps I
didn''t understand the implications of Alexander''s request or
maybe these are two different things we''re conflating. I read #16003 as
wanting a way, from hiera, to enumerate all the nodes hiera considers itself
authoritative for.

>  It seems reasonable to me
> that since at least YAML supports data structures *and* puppet supports
> hashes and arrays and nesting of same, one might choose to design the
> configuration "namespace" for a particular class to use an actual
data
> structure in hiera.  I''ve been watching the list very closely
> for several months for any official statement from Puppetlabs folks about
> best practices with hiera data, and your statement is really the first
> I''ve seen.
> 
> What you''ve said has a pretty clear implication: don''t
use nested data
> structures in hiera, because they''re not going to work in the way
that
> I think most people would expect them to work -- you can''t merge
different
> sub-keys from different parts of your hierarchy.
Now I really think we''re talking about different things, because this
data design seems quite reasonable and I agree that merging a various
intermediate keys from a nested data structure ought to work. Indeed this seems
like something that is back-end dependent, i.e. a different yaml backend could
behave exactly this way behind the scenes when you request the
''ntp'' hash for a node, without needing a different hiera_*
function at all.

So I guess I should ask, Alexander did I misunderstand what you were asking
about in #16003?

Eric Sorenson - eric.sorenson@puppetlabs.com
PuppetConf''12 - 27-28 Sep in SF - http://bit.ly/pcsig12

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

In regard to: Re: [Puppet Users] Getting all variable occurrences from...:
> Now I really think we''re talking about different things, because
this
> data design seems quite reasonable and I agree that merging a various
> intermediate keys from a nested data structure ought to work. Indeed
> this seems like something that is back-end dependent, i.e. a different
> yaml backend could behave exactly this way behind the scenes when you
> request the ''ntp'' hash for a node, without needing a
different hiera_*
> function at all.
Agreed.
> So I guess I should ask, Alexander did I misunderstand what you were
> asking about in #16003?
My impression is that you understood #16003 correctly, and that the
use-case I was asking about is in reality different.  I hope Alexander
chimes in to confirm or refute that, but I think we''re asking about
things that seem related but aren''t.

Keep in mind that I''m not saying I think hiera *must* work the way
I''ve
described, I''m just asserting that I can see people potentially
thinking
it would work that way and I can see some potential benefits to having
it work that way.  What I''m really asking for, more than anything, is
a stance from the designers and architects saying either "bad idea,
don''t
do it" or "yeah, should work and we''re not opposed to
it".

If I need to open a separate ticket to get that kind of directional
clarity, I would be happy to do so.

Tim
-- 
Tim Mooney                                             Tim.Mooney@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wednesday, August 22, 2012 6:01:06 PM UTC-7, Tim Mooney
wrote:
>
>
> If I need to open a separate ticket to get that kind of directional 
> clarity, I would be happy to do so. 
>
>
A ticket specifically about this use-case would be awesome. Thanks, Tim!

-=Eric 

-- 
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/-/fXzBYo-mUiAJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

In regard to: Re: [Puppet Users] Getting all variable occurrences from...:
> On Wednesday, August 22, 2012 6:01:06 PM UTC-7, Tim Mooney wrote:
>>
>>
>> If I need to open a separate ticket to get that kind of directional
>> clarity, I would be happy to do so.
>>
>>
> A ticket specifically about this use-case would be awesome. Thanks, Tim!
 	http://projects.puppetlabs.com/issues/16107

Sorry about how the config ended up in that ticket, I didn''t realize
how
it was going to be wiki-fied.  I can update the ticket with fixed
formatting if necessary.

Tim
-- 
Tim Mooney                                             Tim.Mooney@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.