Re: [Puppet Users] Puppet 5 Stdlib IP address parsing

[John Baird]

Do you have any recommendations for validating a custom top-scope fact?  
Meaning, it's not a module scope, how can I verify a top-scope variable if 
I can't put that in the class params?

On Thursday, February 15, 2018 at 8:01:57 AM UTC-6, R.I. Pienaar wrote:
>
>
>
> On Thu, 15 Feb 2018, at 14:50, John Baird wrote: 
> > R.I, 
> > 
> > Can you point me to some docs on exactly how to use those?  I have 
> looked 
> > and I only see references to using them, but not how to actually use 
> them 
> > within a manifest for validation.  Any places you can point me to would 
> be 
> > much appreciated! 
>
> class thing( 
>   Stdlib::Compat::Ipv4 $ipaddress 
> ) { 
>
> } 
>
> this is how you tell it the class param has to be a ipv4, any attempt to 
> pass anything else is a compile error 
>
> https://puppet.com/docs/puppet/5.3/lang_data_type.html 
>
> > 
> > Also, thanks for all of the useful modules you have written over the 
> years, 
> > I recognized your name instantly!  Thanks for getting back to me! 
> > 
> > John Baird 
> > 
> > On Thursday, February 15, 2018 at 12:19:30 AM UTC-6, R.I. Pienaar wrote: 
> > > 
> > > Use the Stdlib::Compat::Ipv4, ::Ipv6 and ::Ip_address data types 
> > > 
> > > --- 
> > > R.I.Pienaar 
> > > 
> > > On 15 Feb 2018, at 01:41, John Baird <john.w...@gmail.com 
> > 
> > > wrote: 
> > > 
> > > 
> > > According to the stdlib docs, "is_ip_address" is deprecated.  There is 
> no 
> > > mention of how to replace it without using "validate_legacy" which 
> itself 
> > > will ultimately be deprecated. 
> > > 
> > > Is there a better/proper approach to validating IPv4 and/or IPv6 
> syntax 
> > > with Puppet 5 ? 
> > > ` 
> > > is_ip_address 
> > > 
> > > *Deprecated. Will be removed in a future version of stdlib. 
> > > See validate_legacy 
> > > <https://forge.puppet.com/puppetlabs/stdlib#validate_legacy>.* 
> > > 
> > > Returns true if the string passed to this function is a valid IP 
> address. 
> > > 
> > > *Type*: rvalue. 
> > > 
> > > ` 
> > > 
> > > -- 
> > > You received this message because you are subscribed to the Google 
> Groups 
> > > "Puppet Users" group. 
> > > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > > email to puppet-users...@googlegroups.com . 
> > > To view this discussion on the web visit 
> > > 
> https://groups.google.com/d/msgid/puppet-users/3275659c-d7c0-487f-979b-8e62da5a3cd1%40googlegroups.com
>  
> > > <
> https://groups.google.com/d/msgid/puppet-users/3275659c-d7c0-487f-979b-8e62da5a3cd1%40googlegroups.com?utm_medium=email_source=footer>
>  
>
> > > . 
> > > For more options, visit https://groups.google.com/d/optout. 
> > > 
> > > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Puppet Users" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to puppet-users...@googlegroups.com . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/puppet-users/273e4a69-f25a-4261-8bfd-25ff8cc74d6e%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
> -- 
> R.I.Pienaar / www.devco.net / @ripienaar 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/76c27569-da23-48cb-b05f-81929f144425%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet 5 Stdlib IP address parsing

[John Baird]

Ok, that works.  I appreciate the response, thanks!


On Thursday, February 15, 2018 at 8:01:57 AM UTC-6, R.I. Pienaar wrote:
>
>
>
> On Thu, 15 Feb 2018, at 14:50, John Baird wrote: 
> > R.I, 
> > 
> > Can you point me to some docs on exactly how to use those?  I have 
> looked 
> > and I only see references to using them, but not how to actually use 
> them 
> > within a manifest for validation.  Any places you can point me to would 
> be 
> > much appreciated! 
>
> class thing( 
>   Stdlib::Compat::Ipv4 $ipaddress 
> ) { 
>
> } 
>
> this is how you tell it the class param has to be a ipv4, any attempt to 
> pass anything else is a compile error 
>
> https://puppet.com/docs/puppet/5.3/lang_data_type.html 
>
> > 
> > Also, thanks for all of the useful modules you have written over the 
> years, 
> > I recognized your name instantly!  Thanks for getting back to me! 
> > 
> > John Baird 
> > 
> > On Thursday, February 15, 2018 at 12:19:30 AM UTC-6, R.I. Pienaar wrote: 
> > > 
> > > Use the Stdlib::Compat::Ipv4, ::Ipv6 and ::Ip_address data types 
> > > 
> > > --- 
> > > R.I.Pienaar 
> > > 
> > > On 15 Feb 2018, at 01:41, John Baird <john.w...@gmail.com 
> > 
> > > wrote: 
> > > 
> > > 
> > > According to the stdlib docs, "is_ip_address" is deprecated.  There is 
> no 
> > > mention of how to replace it without using "validate_legacy" which 
> itself 
> > > will ultimately be deprecated. 
> > > 
> > > Is there a better/proper approach to validating IPv4 and/or IPv6 
> syntax 
> > > with Puppet 5 ? 
> > > ` 
> > > is_ip_address 
> > > 
> > > *Deprecated. Will be removed in a future version of stdlib. 
> > > See validate_legacy 
> > > <https://forge.puppet.com/puppetlabs/stdlib#validate_legacy>.* 
> > > 
> > > Returns true if the string passed to this function is a valid IP 
> address. 
> > > 
> > > *Type*: rvalue. 
> > > 
> > > ` 
> > > 
> > > -- 
> > > You received this message because you are subscribed to the Google 
> Groups 
> > > "Puppet Users" group. 
> > > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > > email to puppet-users...@googlegroups.com . 
> > > To view this discussion on the web visit 
> > > 
> https://groups.google.com/d/msgid/puppet-users/3275659c-d7c0-487f-979b-8e62da5a3cd1%40googlegroups.com
>  
> > > <
> https://groups.google.com/d/msgid/puppet-users/3275659c-d7c0-487f-979b-8e62da5a3cd1%40googlegroups.com?utm_medium=email_source=footer>
>  
>
> > > . 
> > > For more options, visit https://groups.google.com/d/optout. 
> > > 
> > > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Puppet Users" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to puppet-users...@googlegroups.com . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/puppet-users/273e4a69-f25a-4261-8bfd-25ff8cc74d6e%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
> -- 
> R.I.Pienaar / www.devco.net / @ripienaar 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d5a409f1-ba2a-4898-8efa-a0498ece05e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet 5 Stdlib IP address parsing

[John Baird]

R.I,

Can you point me to some docs on exactly how to use those?  I have looked 
and I only see references to using them, but not how to actually use them 
within a manifest for validation.  Any places you can point me to would be 
much appreciated!

Also, thanks for all of the useful modules you have written over the years, 
I recognized your name instantly!  Thanks for getting back to me!

John Baird

On Thursday, February 15, 2018 at 12:19:30 AM UTC-6, R.I. Pienaar wrote:
>
> Use the Stdlib::Compat::Ipv4, ::Ipv6 and ::Ip_address data types 
>
> ---
> R.I.Pienaar
>
> On 15 Feb 2018, at 01:41, John Baird <john.w...@gmail.com > 
> wrote:
>
>
> According to the stdlib docs, "is_ip_address" is deprecated.  There is no 
> mention of how to replace it without using "validate_legacy" which itself 
> will ultimately be deprecated.
>
> Is there a better/proper approach to validating IPv4 and/or IPv6 syntax 
> with Puppet 5 ?
> `
> is_ip_address
>
> *Deprecated. Will be removed in a future version of stdlib. 
> See validate_legacy 
> <https://forge.puppet.com/puppetlabs/stdlib#validate_legacy>.*
>
> Returns true if the string passed to this function is a valid IP address.
>
> *Type*: rvalue.
>
> `
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/3275659c-d7c0-487f-979b-8e62da5a3cd1%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/puppet-users/3275659c-d7c0-487f-979b-8e62da5a3cd1%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/273e4a69-f25a-4261-8bfd-25ff8cc74d6e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet 5 Stdlib IP address parsing

[John Baird]

According to the stdlib docs, "is_ip_address" is deprecated.  There is no 
mention of how to replace it without using "validate_legacy" which itself 
will ultimately be deprecated.

Is there a better/proper approach to validating IPv4 and/or IPv6 syntax 
with Puppet 5 ?
`
is_ip_address

*Deprecated. Will be removed in a future version of stdlib. 
See validate_legacy 
.*

Returns true if the string passed to this function is a valid IP address.

*Type*: rvalue.

`

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/3275659c-d7c0-487f-979b-8e62da5a3cd1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet Feature Request (lookup with keys containing ".")

[John Baird]

Problem:
  So, currently as has been explained to me, doing a lookup with keys 
containing "." chops the key at first "." because of scoping and 
namespace.  This makes file-based lookups impossible (as far as I can 
tell).  I would like to be able to use HTTP or other backends to serve 
files, which by their very nature WILL contain file extensions.

lookup('/path/to/somefile.txt') will lookup "/path/to/somefile" 

Expectation:
  While I understand that changing the very function of lookup to 
accomodate this is out of scope, I would still think that providing a way 
to tell lookup to NOT chomp or namespace the lookup would be appropriate?  

Something like "lookup('/path/to/somefile.txt', scope=false)"... In this 
manner, the user and more specifically, each lookup call can determine 
whether or not to include the dotted key.

Is this something we could push forward?  How would I go about doing that ?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/c4e8c719-5367-4da4-a7d5-a95f0684e5ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Hiera 5 + Puppet 5 File Backend

[John Baird]

Justin,

I would love to see what you have done.  Would you be willing to send me 
what you've written.  It's possible I could extend what you've done to 
resolve my huge lingering issue, which is being able to some sort of 
file-based lookup WITH file extensions (as default lookup behavior chops at 
first '.').  Feel free to message directly if you wish.  Thanks for 
anything you can send my way!


On Saturday, September 16, 2017 at 3:02:10 AM UTC-5, Justin DynamicD wrote:
>
> I had a similar but "not quite the same" challenge.  Basically I just 
> added a custom ruby function to let you parse the data you're looking for. 
>  So in addition to lookup (), I now have things like consul_servicenames() 
> which dumps all services presented by a host in an array format (handy for 
> if $a in $b scenarios).  It basically means building a few custom parsers 
> in ruby into your backend module to cover common lookup "Styles" that match 
> your CM layout.  By storing them all in the backend module they are 
> available essentially globally and simply called differently.
>
>
>
> On Friday, September 15, 2017 at 10:18:03 AM UTC-7, John Baird wrote:
>>
>> Right, and that's exactly my concern with NOT being able to do exactly 
>> that.
>>
>> Scenarios
>> 1.  I wish to lookup a URI that is to be configured for a module.  The 
>> module name here is obviously not important, but let's call it "mymodule".  
>> In the manifest, I wish to lookup ssh keys being served up by Consul (as I 
>> am currently doing).  I would like to simply lookup('username') where 
>> 'username' is the user whose public key I would like to authorize onto my 
>> system.
>> 1a. This means, lookup('username') will only work for top scope.
>> 1b. Option 1, change scope of lookup.  my lookup now needs to be 
>> "sshkeys::username", but now my URI lookup path is going to be 
>> "/path/to/some/uri/sshkeys::username" in consul.  Surely there's a better 
>> way than having a bunch of k/v pairs with namespaced keys in them ?
>> 1c. Option 2, everything is top scope when I care about doing URI lookups.
>> 1d. This would be fine except if now I want to have a list of all active 
>> users on the system as a simple list in another module.  Now whichever URI 
>> path is first will return the data, and not necessarily the appropriate 
>> data for the lookup.
>>
>> I understand that it's not supposed to work the way it used to, but come 
>> one, this functionality almost seems common place.  Using an HTTP or file 
>> backend is CRITICAL in many ecosystems.
>>
>> I suppose I can write some regsub on the lookup to parse out the 
>> namespace prior to appending it to the URI, but that seems insanely 
>> hackish...  Personally, if I do a lookup from within a module, it should 
>> automatically append the current namespace to it for lookup, then this 
>> issue goes away.
>>
>> On Friday, September 15, 2017 at 10:54:19 AM UTC-5, Henrik Lindberg wrote:
>>>
>>> On 15/09/17 16:46, John Baird wrote: 
>>> > I just realized, while doing some other hiera work with a custom HTTP 
>>> > backend, that this won't work.  It's the same problem I have with the 
>>> > way scoping works for the HTTP backend.  If I don't specify the 
>>> lookup() 
>>> > key in the manifest with a scope, then puppet ONLY uses GLOBAL and 
>>> > ENVIRONMENT scope and ignores module scope.  This seems undesired.  In 
>>> > that manner, I would have to have my filenames (in the case of file 
>>> > backend) or URIs (as is the case with HTTP backend) contain module 
>>> > scoping in the lookup, so my filename would become 
>>> > lookup('somemodule::somefile.txt") which would THEN have to actually 
>>> > exist in that lookup... 
>>> > 
>>>
>>> yes, modules cannot bind to names in the global (top) name space. 
>>> If they could they would have the potential to step on each other and it 
>>> will become impossible to resolve a lookup without visiting every module 
>>> on the modulepath for every lookup. 
>>>
>>> hiera is not ignoring module scope - it is simply illegal to try to bind 
>>> to anything that is not in the module's namespace. 
>>>
>>> > I would expect Puppet to use module scope when a lookup is performed 
>>> > within the module if scope is not specified for this lookup. 
>>>
>>> It simply does not work that way. There are no "relative keys". 
>>>
>>> - henrik 
>>>
>>> -- 
>>>
>>> Visit my Blog "Puppet on the Edge" 
>>> http://puppet-on-the-edge.blogspot.se/ 
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/7fcc8552-7642-41b3-ae3b-01ff27e2257d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Hiera 5 + Puppet 5 File Backend

[John Baird]

Right, and that's exactly my concern with NOT being able to do exactly that.

Scenarios
1.  I wish to lookup a URI that is to be configured for a module.  The 
module name here is obviously not important, but let's call it "mymodule".  
In the manifest, I wish to lookup ssh keys being served up by Consul (as I 
am currently doing).  I would like to simply lookup('username') where 
'username' is the user whose public key I would like to authorize onto my 
system.
1a. This means, lookup('username') will only work for top scope.
1b. Option 1, change scope of lookup.  my lookup now needs to be 
"sshkeys::username", but now my URI lookup path is going to be 
"/path/to/some/uri/sshkeys::username" in consul.  Surely there's a better 
way than having a bunch of k/v pairs with namespaced keys in them ?
1c. Option 2, everything is top scope when I care about doing URI lookups.
1d. This would be fine except if now I want to have a list of all active 
users on the system as a simple list in another module.  Now whichever URI 
path is first will return the data, and not necessarily the appropriate 
data for the lookup.

I understand that it's not supposed to work the way it used to, but come 
one, this functionality almost seems common place.  Using an HTTP or file 
backend is CRITICAL in many ecosystems.

I suppose I can write some regsub on the lookup to parse out the namespace 
prior to appending it to the URI, but that seems insanely hackish...  
Personally, if I do a lookup from within a module, it should automatically 
append the current namespace to it for lookup, then this issue goes away.

On Friday, September 15, 2017 at 10:54:19 AM UTC-5, Henrik Lindberg wrote:
>
> On 15/09/17 16:46, John Baird wrote: 
> > I just realized, while doing some other hiera work with a custom HTTP 
> > backend, that this won't work.  It's the same problem I have with the 
> > way scoping works for the HTTP backend.  If I don't specify the lookup() 
> > key in the manifest with a scope, then puppet ONLY uses GLOBAL and 
> > ENVIRONMENT scope and ignores module scope.  This seems undesired.  In 
> > that manner, I would have to have my filenames (in the case of file 
> > backend) or URIs (as is the case with HTTP backend) contain module 
> > scoping in the lookup, so my filename would become 
> > lookup('somemodule::somefile.txt") which would THEN have to actually 
> > exist in that lookup... 
> > 
>
> yes, modules cannot bind to names in the global (top) name space. 
> If they could they would have the potential to step on each other and it 
> will become impossible to resolve a lookup without visiting every module 
> on the modulepath for every lookup. 
>
> hiera is not ignoring module scope - it is simply illegal to try to bind 
> to anything that is not in the module's namespace. 
>
> > I would expect Puppet to use module scope when a lookup is performed 
> > within the module if scope is not specified for this lookup. 
>
> It simply does not work that way. There are no "relative keys". 
>
> - henrik 
>
> -- 
>
> Visit my Blog "Puppet on the Edge" 
> http://puppet-on-the-edge.blogspot.se/ 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/80759536-03b7-4f9b-80ea-39e13dcf0ef8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Hiera 5 + Puppet 5 File Backend

[John Baird]

I just realized, while doing some other hiera work with a custom HTTP 
backend, that this won't work.  It's the same problem I have with the way 
scoping works for the HTTP backend.  If I don't specify the lookup() key in 
the manifest with a scope, then puppet ONLY uses GLOBAL and ENVIRONMENT 
scope and ignores module scope.  This seems undesired.  In that manner, I 
would have to have my filenames (in the case of file backend) or URIs (as 
is the case with HTTP backend) contain module scoping in the lookup, so my 
filename would become lookup('somemodule::somefile.txt") which would THEN 
have to actually exist in that lookup...

I would expect Puppet to use module scope when a lookup is performed within 
the module if scope is not specified for this lookup.
https://groups.google.com/forum/#!topic/puppet-users/9q__saaa26w



On Monday, August 21, 2017 at 3:03:15 PM UTC-5, John Baird wrote:
>
> There was an old hiera 3.X hiera-file backend now owned on github by 
> voxpupuli... does anyone have a working example of how to reproduce this in 
> Puppet 5 with the next data_hash contexts?  Puppet's documentation seems 
> woefully lacking in this area.
>
> Basically, I would like to be able to serve up `/etc/hosts` file from 
> hiera backend, for example.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/e2ee7ef3-1bc3-46b5-ba1d-2482347d502d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: hiera consul backend Puppet 4.10

[John Baird]

Justin,

I just wanted to say that I am currently working on implementing the 
hiera_http to interact with consul.  It's not nearly as clean/concise, but 
it works nonetheless.

https://github.com/crayfishx/hiera-http

Still implementing it at the moment and testing to make sure things work, 
but for now, assuming your scope is correct, works like a champ.  Maybe 
that would help?

On Thursday, August 31, 2017 at 10:10:22 PM UTC-5, Justin DynamicD wrote:
>
> Unfortunately puppet lookup doesn't work at all for me, instead it's 
> complaining about being unable to load some ruby gems that are related to a 
> windows chocolaty module that doesn't even get called in the current 
> environment.  Mind you simple puppet agent -t runs and everything else is 
> flawless ... but anything Hiera related has been an exercise in patience. 
>  Only way I've been able to test it to make a custom role::hieratest and 
> assign it to my server and just invoke puppet runs over and over to see how 
> the lookup works.  There isn't even a module on the forge for formatting 
> the global hiera.yaml on the puppet master (they all stop at v4).  Custom 
> template for that ... Once I get this consul integration doing what I want 
> I'll do everything in my power to avoid re-configuring hiera at all costs.  
>
> Integrating Consul has been a very frustrating journey, much more so than 
> I anticipated when I started.
>
> Does anyone even have a list of example code I can borrow from?  I can 
> find videos of peopel claiming it's awesome at puppet conf but they are all 
> horrifically devoid of any real detail or usable example.  I can't imagine 
> I'm the first person who's tried to lookup what services are registered to 
> a node yet ... can't find a single working example.
>
>
>
>
> On Thursday, August 31, 2017 at 5:47:09 PM UTC-7, John Baird wrote:
>>
>> Justin,
>>
>> Funny, i'm dealing with a somewhat similar scenario, but I should let you 
>> know that you CAN run lookup from CLI...
>>
>> "puppet lookup" should invoke exactly what "lookup" does from within 
>> puppet, that's actually something they did amazingly well...
>>
>> On Thursday, August 31, 2017 at 11:29:02 AM UTC-5, Justin DynamicD wrote:
>>>
>>> Appreciate your feedback.  After a bit of "mucking about" I've added a 
>>> v5 yaml to a branch and will probably merge it in soon, but have left the 
>>> global yaml inplace as v3 until I can do more testing ...
>>>
>>> That said the lookup() feature doesn't feel any easier than the old 
>>> hiera statement ... arguably harder actually.  hiera('var' , []) was easier 
>>> to me than lookup('var', data, 'first', []) but meh, overtime maybe I'll 
>>> appreciate it or at least accept it now that I can make per-environment 
>>> hiera changes.
>>>
>>> Yes, the lookup seems to work like you said it would, but it seems I've 
>>> only opened a can of worms:
>>>
>>> 1.  I can't run lookup from the cli, only hiera.  So guess I have to 
>>> figure out why (maybe because the global hiera is still v3?)
>>> 2.  the consul backend dumps an array of hashes ... eww ... looks like 
>>> Ill have to get really clever about how to manipulate things to get the 
>>> exact key/value I want ... out of scope of this question though.
>>>
>>> Thank you for your help.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/c0043719-c9a4-41ac-9b62-d038e2697b4c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet Lookup Behavior

[John Baird]

I am currently implementing the "hiera-http" custom backend written by 
crayfishx located: "https://github.com/crayfishx/hiera-http;.

I have some custom classes that need to run through an iteration of hiera 
hashes and perform lookups on the values of said hashes.  As a result, I 
would simply like to be able to have lookup('somestring') work from within 
a module.  When doing this, lookup fails to use the module-specific 
hiera.yaml.  I don't want ALL of my modules to use hiera-http as that is 
clearly overkill and prone to latency and longer puppet runs.  The only 
workaround at the moment is to lookup("mymodule::somestring") which then 
properly uses the module hiera.yaml and looks up the value in the 
module-specific YAML.   

As you can imagine, having an HTTP URI that contains "mymodule::somestring" 
is not exactly clean, nor desired.  Is there a way to specify the scope for 
lookup to force it to use the proper hiera.yaml ?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/b9e8b0dc-a4b4-426c-9caf-7987f2f4bcbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Hiera 5 + Puppet 5 File Backend

[John Baird]

Henrik,

I really appreciate your patience here, but I feel like there is something
obvious that I am either not grasping or isn't spelled out in the
documentation.

Let's say I make a function called `lookup_file` which will do the
File.Read in whatever manner I need.  I can call that from my manifests to
lookup the file, but how, then do I lookup the context from hiera?  It's
the combination of these two things that seems abstract to me and is
preventing me from moving forward.  I understand how to do both
individually, but I'm not sure how to retrieve the hiera context for the
path from within this "other" function

I can see that any file_backend function I create chomps the key on the
first "." as we previously discussed, which means that I need to call a
function BEFORE that in order to call my file_backend from within my
file_lookup function, for instance.

How do I get the options and context to be used from the function my
manifest will be using?  Let's assume in my manifest:
content => lookup_file('/tmp/somefile.txt')

does this work in my backend?

Puppet::Functions.create_function(:file_backend) do
  dispatch :file_backend do
param 'String', :key
param 'Hash', :options
param 'Puppet::LookupContext', :context
  end

  def file_backend(key, options, context)
searchroot = options['path']
filename = "#{searchroot}/#{filename}"
# If file is found, return contents of file
# If file is not found, context.not_found()
  end

  def lookup_file(key)
options = :options
context = :context
file_backend(key, :options, :context)
  end
end

I think that's the part I am struggling with... hiera knows about the
context and options, but my manifest knows (or should know) the proper key
to look up.  How do I combine them so I retrieve the contents of the file?

On Sat, Sep 2, 2017 at 3:29 AM Henrik Lindberg <henrik.lindb...@puppet.com>
wrote:

> On 01/09/17 01:32, John Baird wrote:
> > Henrik,
> >
> > I think the disconnect is coming from the fact that the documentation
> > only goes so far.  In that, I mean, what should my lookup be from my
> > manifest?
> >
> > Should my manifest be:
> > $somefile = lookup('/etc/example.txt')
> > and then specify the file_backend in my hiera.yaml?
> >
> > Or should my manifest be:
> > $somefile = file_backend('/etc/example.txt')
> > and then specify the file_backed in my hiera.yaml?
> >
> > If I do the former, is specifying the ":key" just implied?
> > If I do the latter, I end up in a situation where the file_backend
> > function is looking for more arguments than just the simple filename.
> >
> > I feel like that's what's not really clear, since the YAML and JSON
> > backends simply append the key to the options path without ever
> > specifying the actual key existing in the backend.  So it's a little
> > confusing how I should actually be interacting with the custom backend.
> >
>
> The big difference between the YAML and JSON backends is that they load
> files with keys in them. In your case the key is the "name" of the file!
>
> The JSON and YAML backends are of the data_hash kind. They are called
> once and must produce a hash of all the keys in the file pointed to by
> the path the backend is given. You do not want that since it would mean
> that you would have to slurp in all of the data files on the initial
> call. That could be a problem if you have lots of large files and they
> are not all needed for every compilation.
>
> Instead you need to deliver the value for a key per lookup of that key.
> The simple implementation takes the key appends it to the root path,
> reads that file and returns it as the value. If the file does not exist
> it should instead call $context.not_found().
>
> - henrik
>
>
> > On Monday, August 28, 2017 at 2:03:09 AM UTC-5, Henrik Lindberg wrote:
> >
> > On 28/08/17 00:45, John Baird wrote:
> >  > The backend function receives a path in the options hash -
> > that path is
> >  > guaranteed to exist - all non existing paths are simply
> > skipped by
> >  > hiera
> >  > (see the linked docs how it works). Thus, you do not need to
> > use any of
> >  > the find file, etc. You can use relative paths in the
> > hiera.yaml config
> >  > and hiera will figure it out (see the docs).
> >  >
> >  >
> >  > Henrik,
> >  >
> >  > I believe I fully understand the context here, however, is the
> > "options"
> >  > hash not fully referenced within the "hiera.yaml" ?  Basically,
> > 

Re: [Puppet Users] Re: hiera consul backend Puppet 4.10

[John Baird]

Justin,

Funny, i'm dealing with a somewhat similar scenario, but I should let you 
know that you CAN run lookup from CLI...

"puppet lookup" should invoke exactly what "lookup" does from within 
puppet, that's actually something they did amazingly well...

On Thursday, August 31, 2017 at 11:29:02 AM UTC-5, Justin DynamicD wrote:
>
> Appreciate your feedback.  After a bit of "mucking about" I've added a v5 
> yaml to a branch and will probably merge it in soon, but have left the 
> global yaml inplace as v3 until I can do more testing ...
>
> That said the lookup() feature doesn't feel any easier than the old hiera 
> statement ... arguably harder actually.  hiera('var' , []) was easier to me 
> than lookup('var', data, 'first', []) but meh, overtime maybe I'll 
> appreciate it or at least accept it now that I can make per-environment 
> hiera changes.
>
> Yes, the lookup seems to work like you said it would, but it seems I've 
> only opened a can of worms:
>
> 1.  I can't run lookup from the cli, only hiera.  So guess I have to 
> figure out why (maybe because the global hiera is still v3?)
> 2.  the consul backend dumps an array of hashes ... eww ... looks like Ill 
> have to get really clever about how to manipulate things to get the exact 
> key/value I want ... out of scope of this question though.
>
> Thank you for your help.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/28ef9a6b-4f27-4d06-be6d-cfa2de0bcc19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Hiera 5 + Puppet 5 File Backend

[John Baird]

Henrik,

I think the disconnect is coming from the fact that the documentation only 
goes so far.  In that, I mean, what should my lookup be from my manifest?

Should my manifest be:
$somefile = lookup('/etc/example.txt')
and then specify the file_backend in my hiera.yaml?

Or should my manifest be:
$somefile = file_backend('/etc/example.txt')
and then specify the file_backed in my hiera.yaml?

If I do the former, is specifying the ":key" just implied?
If I do the latter, I end up in a situation where the file_backend function 
is looking for more arguments than just the simple filename.

I feel like that's what's not really clear, since the YAML and JSON 
backends simply append the key to the options path without ever specifying 
the actual key existing in the backend.  So it's a little confusing how I 
should actually be interacting with the custom backend.

On Monday, August 28, 2017 at 2:03:09 AM UTC-5, Henrik Lindberg wrote:
>
> On 28/08/17 00:45, John Baird wrote: 
> > The backend function receives a path in the options hash - that path 
> is 
> > guaranteed to exist - all non existing paths are simply skipped by 
> > hiera 
> > (see the linked docs how it works). Thus, you do not need to use any 
> of 
> > the find file, etc. You can use relative paths in the hiera.yaml 
> config 
> > and hiera will figure it out (see the docs). 
> > 
> > 
> > Henrik, 
> > 
> > I believe I fully understand the context here, however, is the "options" 
> > hash not fully referenced within the "hiera.yaml" ?  Basically, how do I 
> > access the lookup of the key itself from within a puppet manifest as an 
> > appendage of the options['path'].  I really believe that is the piece I 
> > am just not able to connect.  Can you help me understand how to do this? 
> >   Thanks! 
> > 
>
> Not quite sure exactly where there is a piece of information missing, so 
> pardon if I explain too much here. 
>
> When hiera 5 processes a lookup it will visit each entry in the 
> hiera.yaml. Such an entry may use one out of several ways to specify a 
> set of file paths to check for existence (path, paths, glob). If the 
> path corresponds to something existing, a call is made to the function 
> associated with that entry. It receives an options hash where path is 
> set to the path that was found to be existing. This is repeated for all 
> the existing paths found in that entry. 
>
> A user may have given additional options in the options hash. 
>
> If the mode of the lookup is "priority" (first found) the search for a 
> value stops when a function produces a value for the key being searched 
> for. If the search is a kind of "merge" then the search continues until 
> all values for the key have been found. 
>
> You can use the fact that the hiera framework performs the existence 
> check. If you do a glob to match all of the files your function will be 
> called with each - then simply check if the leaf file name matches the 
> key being looked up. Call "not_found" for all others, and read and 
> return the content for the one that matches. 
>
> By doing that you get a small advantage in that you will not be 
> incurring checks for lots of file existence for all of the keys that are 
> irrelevant and never will have a matching file. 
>
> Does this help with what you were wondering about? 
> - henrik 
>
> -- 
>
> Visit my Blog "Puppet on the Edge" 
> http://puppet-on-the-edge.blogspot.se/ 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/9f084cd5-73b7-4b17-9c81-8a386af77dc4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Hiera 5 + Puppet 5 File Backend

[John Baird]

>
> The backend function receives a path in the options hash - that path is 
> guaranteed to exist - all non existing paths are simply skipped by hiera 
> (see the linked docs how it works). Thus, you do not need to use any of 
> the find file, etc. You can use relative paths in the hiera.yaml config 
> and hiera will figure it out (see the docs). 


Henrik,

I believe I fully understand the context here, however, is the "options" 
hash not fully referenced within the "hiera.yaml" ?  Basically, how do I 
access the lookup of the key itself from within a puppet manifest as an 
appendage of the options['path'].  I really believe that is the piece I am 
just not able to connect.  Can you help me understand how to do this? 
 Thanks! 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/fa227c63-e1cb-4073-80a8-0e5994efda94%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Hiera 5 + Puppet 5 File Backend

[John Baird]

Thank you.  I will take that and run with it.  I appreciate the comments.

On Thursday, August 24, 2017 at 9:27:31 AM UTC-5, Henrik Lindberg wrote:
>
> On 24/08/17 15:52, John Baird wrote: 
> > Henrik,  I feel like this is becoming overly complicated and perhaps 
> > that is my fault for lack of explanation. 
> > 
> >   I am simply trying to return the contents of a file that is stored in 
> > hiera... Perhaps my gist would make more sense ? 
> > 
> > https://gist.github.com/soudaburger/e253bdce191c731491581df0b0f99234 
> > 
> I commented on your gist 
> https://gist.github.com/soudaburger/e253bdce191c731491581df0b0f99234 
>
> (for others) I wrote this on the gist: 
>
> You need an additional function to transform a pathname with dots to one 
> where they are escaped. But skip that problem first and only test it 
> with a path that does not contain any dots 
>
> Your backend function does not have the correct kind, and signature 
> it should not be a 'data_hash' kind - use a 'lookup_key' kind of backend 
> function (you must otherwise return the content of all files as one hash) 
>
> read about how it should be written here: 
> https://docs.puppet.com/puppet/5.1/hiera_custom_lookup_key.html 
>
> Your backend function should not have a 'scope_param' in the dispatcher 
> Use Puppet::Filesystem.read(path) to read the content of the file 
> referenced by 'path' 
>
> The backend function receives a path in the options hash - that path is 
> guaranteed to exist - all non existing paths are simply skipped by hiera 
> (see the linked docs how it works). Thus, you do not need to use any of 
> the find file, etc. You can use relative paths in the hiera.yaml config 
> and hiera will figure it out (see the docs). 
>
> - henrik 
>
> -- 
>
> Visit my Blog "Puppet on the Edge" 
> http://puppet-on-the-edge.blogspot.se/ 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5024a1a9-ef0d-4c44-97d0-c3906fea1057%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Hiera 5 + Puppet 5 File Backend

[John Baird]

>
> Henrik,  I feel like this is becoming overly complicated and perhaps that 
> is my fault for lack of explanation.

 I am simply trying to return the contents of a file that is stored in 
hiera... Perhaps my gist would make more sense ?

https://gist.github.com/soudaburger/e253bdce191c731491581df0b0f99234

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/4f56d4c9-8f45-43b0-881b-fb1bb7ae73b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Hiera 5 + Puppet 5 File Backend

[John Baird]

Henrik,

Thanks for the feedback, while I wish there was a "better/native" way, I 
have accepted that I need to write my own function.  I would like to be 
able to use a similar syntax as "lookup()" and simply specify a filepath 
and have the contents returned as the content of the file being created.  I 
am fairly certain I can accomplish this, but I am not sure how I gain 
access to the hiera scope or hierarchy that is defined by either the module 
or the global/environment scope.  I want my custom module to be able to 
search the hiera path(s) for the necessary file structure.  How would I go 
about getting that scope into a custom function?  Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/abeb1ef0-f6e5-4d02-8b6d-0ed414a36f18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: puppet SSHD port based on hostname

[John Baird]

Honestly, I believe you would benefit from reading this over a bit...

https://docs.puppet.com/puppet/5.0/lang_template_erb.html


On Tuesday, August 22, 2017 at 4:37:35 PM UTC-5, John wrote:
>
> So I added the following to sshd_config.erb
>
> <%- if hostname = MyHost -%>
> Port = 
> <%- end -%>
>
> But it did not provide the expected results.  The puppet run finished 
> cleanly, but the sshd_config remained unchanged.
>
> Does that syntax look alright?
>
> TIA
>
> On Tuesday, August 22, 2017 at 12:36:15 PM UTC-4, John wrote:
>>
>> I've pulled down the SAZ SSH module and implemented across my network. 
>>  It works great.
>>
>> However, I need to implement the following change:
>>
>> If hostname = host1 or host2 or host3
>>   then
>> port = 
>> fi
>>
>> I just want to change the default sshd port for a few hosts.
>>
>> How do I do that?
>> 
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/4a22f5df-272b-4ce6-9cad-fd60e564440f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Hiera 5 + Puppet 5 File Backend

[John Baird]

Henrik,

Thanks for the feedback.  My concern stems, really, from being able to use 
this with Puppet.  I would think that I should be able to specify a 
filename and/or filepath that contain a "." without having to escape those 
myself.  The backend should handle that, in my opinion.  You can image if a 
user/developer wanted to have a domain-oriented folder structure with 
multiple domains, how that could get extremely hard to read quickly... 
"/path/to/file/domain1\.example\.com" and then the variable would have to 
be unescaped for all other references to that variable.  That seems silly. 
 I appreciate your time on this, but I feel like there has to be a better 
solution, I just haven't found it yet.  I am still working on making this 
code work...

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/049d195d-1ea0-4c00-9165-c195bf67ed01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: puppet SSHD port based on hostname

[John Baird]

It looks like you should be able to pass it as a Hash of "options"... 

https://github.com/saz/puppet-ssh/search?utf8=%E2%9C%93=port=

On Tuesday, August 22, 2017 at 11:36:15 AM UTC-5, John wrote:
>
> I've pulled down the SAZ SSH module and implemented across my network.  It 
> works great.
>
> However, I need to implement the following change:
>
> If hostname = host1 or host2 or host3
>   then
> port = 
> fi
>
> I just want to change the default sshd port for a few hosts.
>
> How do I do that?
> 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1c86488f-7d74-4b8f-a93f-5682e71d12e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Hiera 5 + Puppet 5 File Backend

[John Baird]

>
> Henrik,


I have something that appears to be at least "attempting" to find the 
proper files.  The issue I am currently running into is that the "key" or 
file that I am looking for is being "chopped" at the first ".", which in 
this case is actually in a folder name, not the file extension.  Do you 
know how to avoid that?

*# File Backend for Hiera*
*Puppet::Functions.create_function(:'file_backend') do*

*  dispatch :file_backend do*
*param "String", :key*
*param "Hash", :options*
*param "Puppet::LookupContext", :context*
*  end*

*  argument_mismatch :missing_path do*
*param 'Hash', :options*
*param 'Puppet::LookupContext', :context*
*  end*

*  def file_backend(key, options, context)*
*hieradir   = context.interpolate(options['hieradir'])*
*searchroot = context.interpolate(options['searchroot'])*
*searchpath = hieradir + searchroot*
*if (File.exists?("#{searchpath}/#{key}"))*
*  data = File.read("#{searchpath}/#{key}")*
*else*
*  context.explain() { "SearchPath: #{searchpath}, Key: #{key}"}*
*  context.not_found()*
*end*
*  end*

*  def missing_path(options, context)*
*"one of 'path', 'paths', 'glob', 'globs', or 'mapped_paths' must be 
declared in hiera.yaml when using this file_backend function"*
*  end*
*end*

When looking up '*/etc/dd-agent/checks.d/filename.py'* I receive a `*Function 
lookup() did not find a value for the name 
'/etc/dd-agent/checks.d/filename.py*`.

The debugging from the puppet lookup outputs *KEY: /etc/dd-agent/checks *which 
does not contain the rest of the filename or path.

Thoughts ?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/7a86b718-434c-42ff-ad50-649f276c75ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Hiera 5 + Puppet 5 File Backend

[John Baird]

Henrik,

Whether the existing YAML/JSON/HOCON backend is referenced, everything is 
using the context of `path` to do the lookups.  The issues with this in 
regards to a file backend, is I am unsure as to how to access the value or 
file being looked up.  The `path` for the other backends is statically 
defined and they load the content accordingly.  Do you know how to access 
the value being looked up or if that is even possible in this context ?


*context.cached_file_data(path) do |content|*

Path in this case is the full URI to the YAML file being ingested, for 
instance. But I need to append the variable being looked up to that in 
order to find the file I am seeking.
I believe that is the missing piece I need to make this all work. Any 
insight would be appreciated. Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/28c0c2d2-b350-47d6-a775-e282abd4f158%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Hiera 5 + Puppet 5 File Backend

[John Baird]

Henrik,

I would also like to add that having the ability to serve up binary files, 
not just ASCII files would also be a great bonus.  Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/7375977a-235a-4904-a7c6-07634a43e4c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Hiera 5 + Puppet 5 File Backend

[John Baird]

Henrik,

Thanks for helping... I tried originally using the hiera-file backend but, 
there's too much code to update since the repo hasn't been touched in 
nearly 2+ years.  So I went down the path of trying to modify the json_data 
and/or yaml_data backends to suit my needs, since I noticed the biggest 
delta between the two files was the loading of the respective JSON or YAML. 
 

I am unsure as to what the exact expectations are when returning the data 
within the *_data.rb backend.

If you can assist in starting with either the json_data or yaml_data ruby 
files and modifying them to work with what I need, I would be forever 
grateful.

Here are my requirements and expectations...
1. Using lookup() should return/query the same way as it currently does for 
variables.
2. I want to be able to specify a "filepath" like "/etc/hosts" which would 
then be appended at the end of the search path, so 
"environments/%{environment}", for example.
3. The contents of "environment/%{environment}/etc/hosts" would then be 
returned.
3. The backend should only return the contents of the first match, as I 
won't want duplicative entries within the files.
4. Anything else that may make sense to modify would be good.

I appreciate any assistance you can provide.  Thanks!

On Monday, August 21, 2017 at 3:34:41 PM UTC-5, Henrik Lindberg wrote:
>
> On 21/08/17 22:18, John Baird wrote: 
> > I see the "yaml_data" and "json_data" backends, but unfortunately, I'm 
> > not a Ruby developer and trying to mock those into a file_data backend 
> > is proving frustratingly obnoxious.  Honestly, I wish a "file_data" 
> > backend was included by default as I feel there a TON of value in it's 
> > existence, but that's another topic. 
> > 
> > Basically, from the documentation 
> > at https://docs.puppet.com/puppet/5.0/hiera_custom_data_hash.html, I am 
> > able to make a custom backend, but unable to get it to parse the 
> > directory structure properly and retrieve the entire contents of the 
> file. 
> > 
> > If you have something that would work, I would love to get it working on 
> > my end. 
> > 
>
> You can write functions in the puppet language as well as in Ruby if 
> that is more convenient for you. Then depending on what the format of 
> the data file you want read is, you could either use an existing 
> function that reads JSON/YAML etc. If there is no reader you would be 
> best off to write a separate function that can read a particular format, 
> and then use that to parse the file and serve data from it using a hiera 
> 5 backend compliant function. 
>
> The functions that just read a file and returns it a a hash are very 
> simple 
> (
> https://github.com/puppetlabs/puppet/blob/master/lib/puppet/functions/json_data.rb)
>  
>
> which is basically JSON.parse and some error handling around that. 
>
> I would expect a custom backend function that you write to be given an 
> argument that is the absolute path to the file you want read. That is 
> given in the hiera.yaml. 
>
> Is it that you want a structure that defines the keys and that the files 
> themselves are the resulting value? (Have not looked at hiera-file 
> backend). If so, then it sounds like just translating the key to lookup 
> to a path (splitting on '::' and and joining with '/') plus appending 
> that to a base path where the files are to be found (given as an option 
> when adding the function to the hiera.yaml hierarchy). Then reading that 
> file or producing a "not found" if the file does not exists. 
>
> If you have the start of this in Ruby somewhere I am happy to help you 
> review and point out what to change. 
>
> Best, 
> - henrik 
>
> > On Monday, August 21, 2017 at 3:14:42 PM UTC-5, Henrik Lindberg wrote: 
> > 
> > On 21/08/17 22:03, John Baird wrote: 
> >  > There was an old hiera 3.X hiera-file backend now owned on github 
> by 
> >  > voxpupuli... does anyone have a working example of how to 
> > reproduce this 
> >  > in Puppet 5 with the next data_hash contexts?  Puppet's 
> > documentation 
> >  > seems woefully lacking in this area. 
> >  > 
> >  > Basically, I would like to be able to serve up `/etc/hosts` file 
> > from 
> >  > hiera backend, for example. 
> >  > 
> > That should be incredibly simple to achieve with hiera 5. 
> > What is it that you feel is lacking in terms of documentation? 
> > 
> > - henrik 
> > 
> > 
> > -- 
> > 
> > Visit my Blog "Puppet on the Edge" 
> > http://puppet-on-the-edge.blogspot

Re: [Puppet Users] Hiera 5 + Puppet 5 File Backend

[John Baird]

I see the "yaml_data" and "json_data" backends, but unfortunately, I'm not 
a Ruby developer and trying to mock those into a file_data backend is 
proving frustratingly obnoxious.  Honestly, I wish a "file_data" backend 
was included by default as I feel there a TON of value in it's existence, 
but that's another topic.

Basically, from the documentation 
at https://docs.puppet.com/puppet/5.0/hiera_custom_data_hash.html, I am 
able to make a custom backend, but unable to get it to parse the directory 
structure properly and retrieve the entire contents of the file.

If you have something that would work, I would love to get it working on my 
end.

On Monday, August 21, 2017 at 3:14:42 PM UTC-5, Henrik Lindberg wrote:
>
> On 21/08/17 22:03, John Baird wrote: 
> > There was an old hiera 3.X hiera-file backend now owned on github by 
> > voxpupuli... does anyone have a working example of how to reproduce this 
> > in Puppet 5 with the next data_hash contexts?  Puppet's documentation 
> > seems woefully lacking in this area. 
> > 
> > Basically, I would like to be able to serve up `/etc/hosts` file from 
> > hiera backend, for example. 
> > 
> That should be incredibly simple to achieve with hiera 5. 
> What is it that you feel is lacking in terms of documentation? 
>
> - henrik 
>
>
> -- 
>
> Visit my Blog "Puppet on the Edge" 
> http://puppet-on-the-edge.blogspot.se/ 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/9154ad28-5f52-40b9-87a6-62ba6ac89e85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Hiera 5 + Puppet 5 File Backend

[John Baird]

There was an old hiera 3.X hiera-file backend now owned on github by 
voxpupuli... does anyone have a working example of how to reproduce this in 
Puppet 5 with the next data_hash contexts?  Puppet's documentation seems 
woefully lacking in this area.

Basically, I would like to be able to serve up `/etc/hosts` file from hiera 
backend, for example.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/3ecfec90-12ee-47c4-a29a-61799f4ddced%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet5 + Hiera not actually including classes during run

[John Baird]

Ok, so we can all move on, nothing to see here!  This appears to be an 
artifact of having previously (unintentionally) installed puppet 3.X.  As a 
result, hiera 2.0.0 was installed.  I believe that this version of hiera to 
be incompatible and as a result, after a clean rebuild, everything is 
running as expected...

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/f1d39d4e-5272-41b2-b613-0355790dd6a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet5 + Hiera not actually including classes during run

[John Baird]

I should also add, running masterless Puppet 5.0.1 on Ubuntu 16.04 if any 
of that matters.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/bdb1c4bb-8681-4e24-b3db-0627e39c02e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet5 + Hiera not actually including classes during run

[John Baird]

root@example1:~# puppet apply --noop -e 'class { apt: }' --modulepath 
/root/puppet/modules/ --environment=dev 
--environmentpath=/root/puppet/environments --hiera_config 
/root/puppet/hiera.yaml
Notice: Compiled catalog for example1 in environment dev in 0.13 seconds
Notice: /Stage[main]/Apt/File[preferences]/ensure: current_value 'absent', 
should be 'file' (noop)
Notice: 
/Stage[main]/Apt/Apt::Setting[conf-update-stamp]/File[/etc/apt/apt.conf.d/15update-stamp]/content:
 
current_value '{md5}b9de0ac9e2c9854b1bb213e362dc4e41', should be 
'{md5}0962d70c4ec78bbfa6f3544ae0c41974' (noop)
Notice: Class[Apt::Update]: Would have triggered 'refresh' from 2 events
Notice: /Stage[main]/Apt::Update/Exec[apt_update]: Would have triggered 
'refresh' from 1 event
Notice: Class[Apt::Update]: Would have triggered 'refresh' from 1 event
Notice: Apt::Setting[conf-update-stamp]: Would have triggered 'refresh' 
from 1 event
Notice: Class[Apt]: Would have triggered 'refresh' from 2 events
Notice: Stage[main]: Would have triggered 'refresh' from 2 events
Notice: Applied catalog in 0.03 seconds


root@example1:~# puppet lookup classes --hiera_config puppet/hiera.yaml 
--modulepath=/root/puppet/modules --environment=dev 
--environmentpath=/root/puppet/environments
---
- apt


root@example1:~# puppet apply --modulepath /root/puppet/modules/ 
--hiera_config /root/puppet/hiera.yaml --environment=dev 
--environmentpath="/root/puppet/environments" 
/root/puppet/environments/dev/site.pp
Notice: Compiled catalog for example1 in environment dev in 0.03 seconds
Notice: Applied catalog in 0.01 seconds

root@example1:~# cat /root/puppet/environments/dev/site.pp 
node default {
  lookup('classes')
}

root@example1:~# tree /root/hieradata/
/root/hieradata/
├── nodes
│   └── example1.yaml
└── README.md

root@example1:~# cat /root/hieradata/nodes/example1.yaml 
---
classes:
  - apt



So, I can see that hiera can find the proper class.  I can see that running 
in noop mode with the same options actually runs the class.  When I run 
puppet without manually running noop, nothing happens.  This is not limited 
to the apt class as there are about 10 classes that should clearly be 
installing/configuring, etc...  but there's nothing actually happening...

I feel like I missed something somewhere, but not seeing it.  Has anyone 
seen this before?


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/e0ddcded-1e38-41b3-8e60-d876a62b5b64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet Environment Classification Conflict

[John Baird]

I have followed the instructions 
here: 
https://docs.puppet.com/pe/2016.2/console_classes_groups.html#creating-environment-node-groups.
 
 This states that ALL environments that are created should be a child under 
"production".  This makes sense because I would want it to inherit all of 
the default things that puppet does to nodes out of the box.

When I add a node to the new environment, we shall call it 
"new_environment", puppet runs fine.

I then create a "node classification group" under "new_environment".  The 
existence of the group is not the issue until I assign the node to the 
"node classification group".  Puppet then complains about conflicts.  

I really haven't modified much for there to even be conflicts.  This seems 
like normal SOP and yet it's not resolving itself.  

I have set the variable "environment=new_environment" in the 
"new_environment" environment.  There are no other classes or variables 
assigned.

Do I need to include the two default classes from "PE Agent" and "PE 
Mcollective" in every environment I create??? That seems silly


*Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Failed when searching for node node1: Classification of node1 failed due to 
a classification conflict: The node was classified into groups named 
"new_class_group", "PE Agent", and "PE MCollective" that defined 
conflicting values for the environment.*

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d154af21-eabc-45a5-a765-3e395ca33c66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Hiera Lookups Fail with variables

[John Baird]

I was using calling_class as an example.  %{calling_module} used to work, 
but now does not.  Are you aware of what should be used instead?  Things 
like %{::hostname} do not work either.  

My other real concern is that when using something like 
"%{calling_module}/random_thing", there is no lookup for "/random_thing" 
when calling_module is not interpolated as I would expect it to since it 
should see it as a nil value.

On Tuesday, July 19, 2016 at 4:59:50 PM UTC-5, Gavin Williams wrote:
>
> John
>
> Yes, the 'common1' and 'common2' tiers are being ignored because 
> 'calling_class' doesn't expand to anything when running on the command line.
>
> Try running 
> hiera -d 'dhcpd::package_name' environment=production calling_class=*x*
> replacing x with the corresponding class_name you'd expect to be 
> resolving... 
>
> Gav
>
> On Tuesday, 19 July 2016 22:29:41 UTC+1, John Baird wrote:
>>
>> If you look at the hiera debug output from the last reply I posted, it 
>> clearly shows that several folders with variables are not looked at when it 
>> should be.  Even if it doesn't find data in those folders, hiera should 
>> still explicitly show that it is TRYING to look there, but that doesn't 
>> happen.  It clearly is not searching where it should be, which is why 
>> everything is failing unless it's all hard-coded, which is obviously not 
>> ideal.
>>
>> On Tuesday, July 19, 2016 at 2:16:10 AM UTC-5, John Baird wrote:
>>>
>>> Attempting to use hiera to hold all of my node-specific variables.  It 
>>> has been some time since I have run a puppet server, but I know it's not 
>>> THAT hard.  That being said, my modules run fine, but hiera is not looking 
>>> them up correctly.  It appears that any lines that contain any variables in 
>>> the hiera.yaml are ignore and are not searched.  Any assistance would be 
>>> great!  I'm sure it's something small, but sooo confused...
>>>
>>>
>>> HIERA.YAML
>>> --
>>> ---
>>> :backends:
>>>   - yaml
>>> :yaml:
>>>   :datadir: "/opt/local/modules/hieradata"
>>> :hierarchy:
>>>   - '%{calling_module}/%{::hostname}'
>>>   - '%{calling_module}/common'
>>>   - common
>>>
>>>
>>> hiera -d 'dhcpd::package_name' environment=production
>>> DEBUG: 2016-07-18 20:48:38 -0400: Hiera YAML backend starting
>>> DEBUG: 2016-07-18 20:48:38 -0400: Looking up dhcpd::package_name in YAML 
>>> backend
>>> DEBUG: 2016-07-18 20:48:38 -0400: Looking for data source common
>>> DEBUG: 2016-07-18 20:48:38 -0400: Cannot find datafile 
>>> /opt/local/modules/hieradata/common.yaml, skipping
>>> nil
>>>
>>>
>>> ---
>>> :backends:
>>>   - yaml
>>> :yaml:
>>>   :datadir: "/opt/local/modules/hieradata"
>>> :hierarchy:
>>>   - '%{calling_module}/%{::hostname}'
>>>   - '%{calling_module}/common'
>>>   - common
>>>   - puppet_test
>>>
>>> hiera -d 'dhcpd::package_name' environment=production
>>> DEBUG: 2016-07-18 20:49:30 -0400: Hiera YAML backend starting
>>> DEBUG: 2016-07-18 20:49:30 -0400: Looking up dhcpd::package_name in YAML 
>>> backend
>>> DEBUG: 2016-07-18 20:49:30 -0400: Looking for data source common
>>> DEBUG: 2016-07-18 20:49:30 -0400: Cannot find datafile 
>>> /opt/local/modules/hieradata/common.yaml, skipping
>>> DEBUG: 2016-07-18 20:49:30 -0400: Looking for data source puppet_test
>>> DEBUG: 2016-07-18 20:49:30 -0400: Cannot find datafile 
>>> /opt/local/modules/hieradata/puppet_test.yaml, skipping
>>> nil
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/096a7c43-6461-4f69-a9ee-d683fb71edb9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Hiera Lookups Fail with variables

[John Baird]

If you look at the hiera debug output from the last reply I posted, it 
clearly shows that several folders with variables are not looked at when it 
should be.  Even if it doesn't find data in those folders, hiera should 
still explicitly show that it is TRYING to look there, but that doesn't 
happen.  It clearly is not searching where it should be, which is why 
everything is failing unless it's all hard-coded, which is obviously not 
ideal.

On Tuesday, July 19, 2016 at 2:16:10 AM UTC-5, John Baird wrote:
>
> Attempting to use hiera to hold all of my node-specific variables.  It has 
> been some time since I have run a puppet server, but I know it's not THAT 
> hard.  That being said, my modules run fine, but hiera is not looking them 
> up correctly.  It appears that any lines that contain any variables in the 
> hiera.yaml are ignore and are not searched.  Any assistance would be great! 
>  I'm sure it's something small, but sooo confused...
>
>
> HIERA.YAML
> --
> ---
> :backends:
>   - yaml
> :yaml:
>   :datadir: "/opt/local/modules/hieradata"
> :hierarchy:
>   - '%{calling_module}/%{::hostname}'
>   - '%{calling_module}/common'
>   - common
>
>
> hiera -d 'dhcpd::package_name' environment=production
> DEBUG: 2016-07-18 20:48:38 -0400: Hiera YAML backend starting
> DEBUG: 2016-07-18 20:48:38 -0400: Looking up dhcpd::package_name in YAML 
> backend
> DEBUG: 2016-07-18 20:48:38 -0400: Looking for data source common
> DEBUG: 2016-07-18 20:48:38 -0400: Cannot find datafile 
> /opt/local/modules/hieradata/common.yaml, skipping
> nil
>
>
> ---
> :backends:
>   - yaml
> :yaml:
>   :datadir: "/opt/local/modules/hieradata"
> :hierarchy:
>   - '%{calling_module}/%{::hostname}'
>   - '%{calling_module}/common'
>   - common
>   - puppet_test
>
> hiera -d 'dhcpd::package_name' environment=production
> DEBUG: 2016-07-18 20:49:30 -0400: Hiera YAML backend starting
> DEBUG: 2016-07-18 20:49:30 -0400: Looking up dhcpd::package_name in YAML 
> backend
> DEBUG: 2016-07-18 20:49:30 -0400: Looking for data source common
> DEBUG: 2016-07-18 20:49:30 -0400: Cannot find datafile 
> /opt/local/modules/hieradata/common.yaml, skipping
> DEBUG: 2016-07-18 20:49:30 -0400: Looking for data source puppet_test
> DEBUG: 2016-07-18 20:49:30 -0400: Cannot find datafile 
> /opt/local/modules/hieradata/puppet_test.yaml, skipping
> nil
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/7d88bb09-f707-4261-ba43-afca43823f6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Hiera Lookups Fail with variables

[John Baird]

All files should be readable as they are either 755 or 644.  Even if they 
don't exist, hiera should still attempt to "Search" that path and show me 
what directories it is searching when doing so with debug on.  Since it is 
not showing the directories with variables, it, for some reason, is 
skipping them alltogether.

another example:

---
:backends:
  - yaml
:yaml:
  :datadir: "/opt/local/modules/hieradata"
:hierarchy:
  - common1/%{calling_class}
  - common2/%{calling_class}
  - common3
  - puppet_test

hiera -d 'dhcpd::package_name' environment=production
DEBUG: 2016-07-19 13:12:49 -0400: Hiera YAML backend starting
DEBUG: 2016-07-19 13:12:49 -0400: Looking up dhcpd::package_name in YAML 
backend
DEBUG: 2016-07-19 13:12:49 -0400: Looking for data source common3
DEBUG: 2016-07-19 13:12:49 -0400: Cannot find datafile 
/opt/local/modules/hieradata/common3.yaml, skipping
DEBUG: 2016-07-19 13:12:49 -0400: Looking for data source puppet_test
DEBUG: 2016-07-19 13:12:49 -0400: Cannot find datafile 
/opt/local/modules/hieradata/puppet_test.yaml, skipping
nil

common1 and common2 are completely ignored.

On Tuesday, July 19, 2016 at 5:48:59 AM UTC-5, Rob Nelson wrote:
>
> It cannot find the files. Do they exist and are they readable to the user 
> you are running hiera/the puppet master service as?
>
> On Monday, July 18, 2016, John Baird <john.w...@gmail.com > 
> wrote:
>
>> Attempting to use hiera to hold all of my node-specific variables.  It 
>> has been some time since I have run a puppet server, but I know it's not 
>> THAT hard.  That being said, my modules run fine, but hiera is not looking 
>> them up correctly.  It appears that any lines that contain any variables in 
>> the hiera.yaml are ignore and are not searched.  Any assistance would be 
>> great!  I'm sure it's something small, but sooo confused...
>>
>>
>> HIERA.YAML
>> --
>> ---
>> :backends:
>>   - yaml
>> :yaml:
>>   :datadir: "/opt/local/modules/hieradata"
>> :hierarchy:
>>   - '%{calling_module}/%{::hostname}'
>>   - '%{calling_module}/common'
>>   - common
>>
>>
>> hiera -d 'dhcpd::package_name' environment=production
>> DEBUG: 2016-07-18 20:48:38 -0400: Hiera YAML backend starting
>> DEBUG: 2016-07-18 20:48:38 -0400: Looking up dhcpd::package_name in YAML 
>> backend
>> DEBUG: 2016-07-18 20:48:38 -0400: Looking for data source common
>> DEBUG: 2016-07-18 20:48:38 -0400: Cannot find datafile 
>> /opt/local/modules/hieradata/common.yaml, skipping
>> nil
>>
>>
>> ---
>> :backends:
>>   - yaml
>> :yaml:
>>   :datadir: "/opt/local/modules/hieradata"
>> :hierarchy:
>>   - '%{calling_module}/%{::hostname}'
>>   - '%{calling_module}/common'
>>   - common
>>   - puppet_test
>>
>> hiera -d 'dhcpd::package_name' environment=production
>> DEBUG: 2016-07-18 20:49:30 -0400: Hiera YAML backend starting
>> DEBUG: 2016-07-18 20:49:30 -0400: Looking up dhcpd::package_name in YAML 
>> backend
>> DEBUG: 2016-07-18 20:49:30 -0400: Looking for data source common
>> DEBUG: 2016-07-18 20:49:30 -0400: Cannot find datafile 
>> /opt/local/modules/hieradata/common.yaml, skipping
>> DEBUG: 2016-07-18 20:49:30 -0400: Looking for data source puppet_test
>> DEBUG: 2016-07-18 20:49:30 -0400: Cannot find datafile 
>> /opt/local/modules/hieradata/puppet_test.yaml, skipping
>> nil
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/34a20f55-02a2-49c7-88d2-28885636dab2%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/34a20f55-02a2-49c7-88d2-28885636dab2%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
>
> Rob Nelson
> rnel...@gmail.com 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/225d2505-8678-44cb-89ca-95ef1a481b56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Hiera Lookups Fail with variables

[John Baird]

Attempting to use hiera to hold all of my node-specific variables.  It has 
been some time since I have run a puppet server, but I know it's not THAT 
hard.  That being said, my modules run fine, but hiera is not looking them 
up correctly.  It appears that any lines that contain any variables in the 
hiera.yaml are ignore and are not searched.  Any assistance would be great! 
 I'm sure it's something small, but sooo confused...


HIERA.YAML
--
---
:backends:
  - yaml
:yaml:
  :datadir: "/opt/local/modules/hieradata"
:hierarchy:
  - '%{calling_module}/%{::hostname}'
  - '%{calling_module}/common'
  - common


hiera -d 'dhcpd::package_name' environment=production
DEBUG: 2016-07-18 20:48:38 -0400: Hiera YAML backend starting
DEBUG: 2016-07-18 20:48:38 -0400: Looking up dhcpd::package_name in YAML 
backend
DEBUG: 2016-07-18 20:48:38 -0400: Looking for data source common
DEBUG: 2016-07-18 20:48:38 -0400: Cannot find datafile 
/opt/local/modules/hieradata/common.yaml, skipping
nil


---
:backends:
  - yaml
:yaml:
  :datadir: "/opt/local/modules/hieradata"
:hierarchy:
  - '%{calling_module}/%{::hostname}'
  - '%{calling_module}/common'
  - common
  - puppet_test

hiera -d 'dhcpd::package_name' environment=production
DEBUG: 2016-07-18 20:49:30 -0400: Hiera YAML backend starting
DEBUG: 2016-07-18 20:49:30 -0400: Looking up dhcpd::package_name in YAML 
backend
DEBUG: 2016-07-18 20:49:30 -0400: Looking for data source common
DEBUG: 2016-07-18 20:49:30 -0400: Cannot find datafile 
/opt/local/modules/hieradata/common.yaml, skipping
DEBUG: 2016-07-18 20:49:30 -0400: Looking for data source puppet_test
DEBUG: 2016-07-18 20:49:30 -0400: Cannot find datafile 
/opt/local/modules/hieradata/puppet_test.yaml, skipping
nil

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/34a20f55-02a2-49c7-88d2-28885636dab2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.