Re: [Puppet Users] suppressing undefined variable warnings in PE2016.1
This is a hiera design i inherited -- each node can define a 'contextN' (1
through 6) in a contexts parameter in its hosts/${fqdn}.yaml, which is then
in the tree like:
contexts/.yaml
then the site.pp pulls in the 'contexts', sets $context1-6 and hiera uses
them as part of the lookup tree:
contexts/${context1}.yaml
contexts/${context2}.yaml
...
The initial lookup call to retrieve the contexts variable generates the
undefined warning. (since they aren't set yet)
-Ben
On Wednesday, February 15, 2017 at 7:40:22 PM UTC-8, Rob Nelson wrote:
>
> I believe that your hiera lookups won't be a problem. This is looking for
> the usage of previously undefined variables more than the content of the
> variables. If, however, it is truly undefined at that point due to some
> ordering error, it seems like you'd want it to flag instead of be
> nil/undef/etc.
>
> On Wed, Feb 15, 2017 at 10:19 PM Ben Hines <bhi...@gmail.com >
> wrote:
>
>> I would be really cool if warnings could be disabled (And re enabled)
>> from code, like like pragmas in C++. That would let me keep the undefined
>> variables warning where it's needed, but ignore for other areas. (like
>> third party modules i may not care about)
>>
>> In my case, i am using hiera lookup paths that use variables that aren't
>> defined until later. (because they come out of hiera itself) The lookup
>> call that gets them warns that they are undefined, until later when i pull
>> them in. Perhaps that could be fixed on the lookup side, alternatively.
>>
>> -Ben
>>
>> On Friday, May 6, 2016 at 6:55:22 PM UTC-7, Henrik Lindberg wrote:
>>>
>>> On 06/05/16 21:00, Vince Skahan wrote:
>>> >
>>> > Is there a way to shut up the undefined variable warnings in PE2016.1
>>> ?
>>> >
>>> This is https://tickets.puppetlabs.com/browse/PUP-1780
>>> Which was released in Puppet 4.4.0, and is thus in all PE2016.1
>>> versions.
>>>
>>> The input to docs (in the ticket) says:
>>>
>>> "All references to non existing variables will now generate a warning.
>>> Earlier puppet only warned about non existing qualified variables with
>>> more than one namespace segment.
>>>
>>> It is possible to disable these warnings by adding 'undefined_variables'
>>> to the setting 'disabled_warnings'.
>>>
>>> Note that in most cases there is no file/line information available, and
>>> this was one reason why only some cases were reported earlier. We expect
>>> to correct this in the next major version as it requires API breaking
>>> changes."
>>>
>>> Thus - you can get rid of those warnings by disabling that particular
>>> warning.
>>>
>>> Hope that helps
>>>
>>> Best,
>>> - henrik
>>>
>>> > Here's a trivial example:
>>> >
>>> > # puppet apply -t --noop -e 'notice("this should print just a 'x' =>
>>> > x${foo}")'
>>> > Info: Loading facts
>>> > Info: Loading facts
>>> > Info: Loading facts
>>> > Info: Loading facts
>>> > Info: Loading facts
>>> > Info: Loading facts
>>> > Info: Loading facts
>>> > Info: Loading facts
>>> > Info: Loading facts
>>> > Info: Loading facts
>>> > Info: Loading facts
>>> > Info: Loading facts
>>> > Warning: Undefined variable 'foo';
>>> >(file & line not available)
>>> > Notice: Scope(Class[main]): this should print just a x => x
>>> > Notice: Compiled catalog for myhostname.com in environment production
>>> in
>>> > 0.04 seconds
>>> >
>>> > I see there is a --strict-variables where I can make compilation fail.
>>> > It seems that throwing the warning is the current default
>>> > I'm looking for a "yes I have a good reason so please just quit
>>> whining
>>> > about what I am doing" switch :-)
>>> >
>>> > Alternately, is there a way to check for the fact being not defined ?
>>> > I can not find any syntax that works in the 2016.1 parser.
>>> >
>>> > something along the lines of notionally the following:
>>> > if $whatever is defined print out 'whatever = $whatever'
>>> > if $whatever is not defined print out 'whatever is not defined' or
>>> null
>>> > or undef or whatever it evaluates to currently.
>>> >
>>>
Re: [Puppet Users] suppressing undefined variable warnings in PE2016.1
I would be really cool if warnings could be disabled (And re enabled) from
code, like like pragmas in C++. That would let me keep the undefined
variables warning where it's needed, but ignore for other areas. (like
third party modules i may not care about)
In my case, i am using hiera lookup paths that use variables that aren't
defined until later. (because they come out of hiera itself) The lookup
call that gets them warns that they are undefined, until later when i pull
them in. Perhaps that could be fixed on the lookup side, alternatively.
-Ben
On Friday, May 6, 2016 at 6:55:22 PM UTC-7, Henrik Lindberg wrote:
>
> On 06/05/16 21:00, Vince Skahan wrote:
> >
> > Is there a way to shut up the undefined variable warnings in PE2016.1 ?
> >
> This is https://tickets.puppetlabs.com/browse/PUP-1780
> Which was released in Puppet 4.4.0, and is thus in all PE2016.1 versions.
>
> The input to docs (in the ticket) says:
>
> "All references to non existing variables will now generate a warning.
> Earlier puppet only warned about non existing qualified variables with
> more than one namespace segment.
>
> It is possible to disable these warnings by adding 'undefined_variables'
> to the setting 'disabled_warnings'.
>
> Note that in most cases there is no file/line information available, and
> this was one reason why only some cases were reported earlier. We expect
> to correct this in the next major version as it requires API breaking
> changes."
>
> Thus - you can get rid of those warnings by disabling that particular
> warning.
>
> Hope that helps
>
> Best,
> - henrik
>
> > Here's a trivial example:
> >
> > # puppet apply -t --noop -e 'notice("this should print just a 'x' =>
> > x${foo}")'
> > Info: Loading facts
> > Info: Loading facts
> > Info: Loading facts
> > Info: Loading facts
> > Info: Loading facts
> > Info: Loading facts
> > Info: Loading facts
> > Info: Loading facts
> > Info: Loading facts
> > Info: Loading facts
> > Info: Loading facts
> > Info: Loading facts
> > Warning: Undefined variable 'foo';
> >(file & line not available)
> > Notice: Scope(Class[main]): this should print just a x => x
> > Notice: Compiled catalog for myhostname.com in environment production
> in
> > 0.04 seconds
> >
> > I see there is a --strict-variables where I can make compilation fail.
> > It seems that throwing the warning is the current default
> > I'm looking for a "yes I have a good reason so please just quit whining
> > about what I am doing" switch :-)
> >
> > Alternately, is there a way to check for the fact being not defined ?
> > I can not find any syntax that works in the 2016.1 parser.
> >
> > something along the lines of notionally the following:
> > if $whatever is defined print out 'whatever = $whatever'
> > if $whatever is not defined print out 'whatever is not defined' or null
> > or undef or whatever it evaluates to currently.
> >
> > I'm probably in interpreted language overload among perl/python/bash and
> > the Puppet DSL is just not grokking.
> >
> > --
> > 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/dcfb928f-6e74-4974-9505-88d446c682f9%40googlegroups.com
>
> > <
> https://groups.google.com/d/msgid/puppet-users/dcfb928f-6e74-4974-9505-88d446c682f9%40googlegroups.com?utm_medium=email_source=footer>.
>
>
> > For more options, visit https://groups.google.com/d/optout.
>
>
> --
>
> 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/aedd4f90-c872-4e1a-8144-b6603b9a3cc6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Hiera 5 calling_class
Okay, thanks! From reading changelogs in git it looked like it was intended
to be supported. It might be worth mentioning in the release notes.
Anyway in my case i can work around with module data.
thanks!
-Ben
On Fri, Feb 10, 2017 at 1:39 PM, Henrik Lindberg <henrik.lindb...@puppet.com
> wrote:
> On 08/02/17 17:55, Ben Hines wrote:
>
>> Perhaps this is just a bug, but does %{calling_class} function with
>> Hiera 5? I haven't been able to get it to function. Perhaps it has a
>> new syntax?
>>
>>
> It is deliberately not supported in the hiera 5 format.
>
> - henrik
>
> Notice it's blank:
>>
>> ==> test: Hierarchy entry "calling_class"
>> ==> test: Path
>> "/tmp/vagrant-puppet/environments/myenv/data/classes/.yaml"
>> ==> test: Original path: "classes/%{calling_class}.yaml"
>> ==> test: Path not found
>>
>>
>> hiera.yaml looks like: (per the 'prerelease documention' :)
>>
>>
>> version: 5
>> hierarchy:
>> - name: "calling_class"
>> path: classes/%{calling_class}.yaml
>>
>> defaults:
>> datadir: data
>> data_hash: yaml_data
>>
>>
>> -Ben
>>
>> --
>> 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
>> <mailto:puppet-users+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/2083ae8f-5437
>> -43c3-8c40-075c3b7abf57%40googlegroups.com
>> <https://groups.google.com/d/msgid/puppet-users/2083ae8f-543
>> 7-43c3-8c40-075c3b7abf57%40googlegroups.com?utm_medium=email
>> _source=footer>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> Visit my Blog "Puppet on the Edge"
> http://puppet-on-the-edge.blogspot.se/
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/puppet-users/UYvmlCaOqLc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/puppet-users/8616db10-6e15-f71d-a999-c663d8d2bfe3%40puppet.com.
>
> 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/CABGPr5m-s3MvwgrY-4yih4VSpMqnNq%3DcWnvW6EzJc2SRF%2BkGqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Hiera 5 calling_class
Perhaps this is just a bug, but does %{calling_class} function with Hiera
5? I haven't been able to get it to function. Perhaps it has a new syntax?
Notice it's blank:
==> test: Hierarchy entry "calling_class"
==> test: Path
"/tmp/vagrant-puppet/environments/myenv/data/classes/.yaml"
==> test: Original path: "classes/%{calling_class}.yaml"
==> test: Path not found
hiera.yaml looks like: (per the 'prerelease documention' :)
version: 5
hierarchy:
- name: "calling_class"
path: classes/%{calling_class}.yaml
defaults:
datadir: data
data_hash: yaml_data
-Ben
--
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/2083ae8f-5437-43c3-8c40-075c3b7abf57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] hiera calling_class files fail with yaml provider on Windows
Howdy,
My organization has a pre-existing hiera configuration which uses
{calling_class}.yaml configuration files, like:
classes/base::openldap.yaml
Which get pulled into hiera via this path in the hierarchy.
:hierarchy:
...
- %{environment}/classes/%{calling_class}
This does not work on Windows. Windows does not support colons in filenames
so the .yaml can't even be checked out from source control. This presents
issues when developing our puppet manifests on windows and sharing them
with a Vagrant VM, for example.
It'd be really nice if hiera supported reading calling_class files from
files which did not use colons as separators. Perhaps it could look up the
class via a 'backup' parameter if the colon version does not exist? (and
it'd have to do this on every OS.. since the problem is a directory which
is checked out on both windows and linux.. perhaps could be an option?)
As a workaround i was considering implementing a custom Hiera backend, but
i'm not sure if there is an easier method.
Thanks
-Ben
--
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/92780abb-f43b-4ac7-a339-657fd503e562%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
