if ! ( $ec2_instance_type in [$ec2_inst_type_allow]) {
notice("NOT ALLOWED")
} else {
notice("ALLOWED")
}
2012-08-20T02:39:10.537134+00:00 truth puppet-master[24080]: Dynamic
lookup of $ec2_instance_type at /truth/sauce/env/prod/modules/rol
e/manifests/validate_server.pp:12 is deprecated. Support will be
removed in Puppet 2.8. Use a fully-qualified variable name (e.g., $
classname::variable) or parameterized classes.
Line 12 is the if statement. However, on the same client system...
> if ! ( $ec2_instance_type in [$ec2_inst_type_allow]) {
> notice("NOT ALLOWED")
> } else {
> notice("ALLOWED")
> }
> 2012-08-20T02:39:10.537134+00:00 truth puppet-master[24080]: Dynamic
> lookup of $ec2_instance_type at /truth/sauce/env/prod/modules/rol
> e/manifests/validate_server.pp:12 is deprecated. Support will be
> removed in Puppet 2.8. Use a fully-qualified variable name (e.g., $
> classname::variable) or parameterized classes.
> Line 12 is the if statement. However, on the same client system...
> It's a facter variable. What's it complaining about?
> Doug.
> -- > 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 Sun, Aug 19, 2012 at 7:48 PM, Eric Shamow <e...@puppetlabs.com> wrote:
> Facts exist at top scope, as indicated in the scoping doc several people have referred you to on this list. Use $::ec2_instance_type
> Sent from my iPad
> On Aug 19, 2012, at 10:44 PM, Douglas Garstang <doug.garst...@gmail.com> wrote:
>> I don't get it...
>> if ! ( $ec2_instance_type in [$ec2_inst_type_allow]) {
>> notice("NOT ALLOWED")
>> } else {
>> notice("ALLOWED")
>> }
>> 2012-08-20T02:39:10.537134+00:00 truth puppet-master[24080]: Dynamic
>> lookup of $ec2_instance_type at /truth/sauce/env/prod/modules/rol
>> e/manifests/validate_server.pp:12 is deprecated. Support will be
>> removed in Puppet 2.8. Use a fully-qualified variable name (e.g., $
>> classname::variable) or parameterized classes.
>> Line 12 is the if statement. However, on the same client system...
>> It's a facter variable. What's it complaining about?
>> Doug.
>> --
>> 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.
> --
> 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.
<doug.garst...@gmail.com> wrote:
> Oh god that's ugly.
Yes it is, and it was an unwitting bug with the deprecation warning
that is resolved in later versions.
Facts were supposed to be able to be referenced as $factname without
throwing the deprecation warning in your release, it's been fixed in
later versions.
> On Sun, Aug 19, 2012 at 7:48 PM, Eric Shamow <e...@puppetlabs.com> wrote:
>> Facts exist at top scope, as indicated in the scoping doc several people have referred you to on this list. Use $::ec2_instance_type
>> Sent from my iPad
>> On Aug 19, 2012, at 10:44 PM, Douglas Garstang <doug.garst...@gmail.com> wrote:
>>> I don't get it...
>>> if ! ( $ec2_instance_type in [$ec2_inst_type_allow]) {
>>> notice("NOT ALLOWED")
>>> } else {
>>> notice("ALLOWED")
>>> }
>>> 2012-08-20T02:39:10.537134+00:00 truth puppet-master[24080]: Dynamic
>>> lookup of $ec2_instance_type at /truth/sauce/env/prod/modules/rol
>>> e/manifests/validate_server.pp:12 is deprecated. Support will be
>>> removed in Puppet 2.8. Use a fully-qualified variable name (e.g., $
>>> classname::variable) or parameterized classes.
>>> Line 12 is the if statement. However, on the same client system...
>>> It's a facter variable. What's it complaining about?
>>> Doug.
>>> --
>>> 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.
>> --
>> 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.
> --
> 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] Dynamic Lookup of facter variable., Nigel...:
> On Sun, Aug 19, 2012 at 8:00 PM, Douglas Garstang
> <doug.garst...@gmail.com> wrote:
>> Oh god that's ugly.
> Yes it is, and it was an unwitting bug with the deprecation warning
> that is resolved in later versions.
> Facts were supposed to be able to be referenced as $factname without
> throwing the deprecation warning in your release, it's been fixed in
> later versions.
Can you expound on this, Nigel?
Are you saying that we do *not* need to reference facts as $::factname
in all our classes, not even in preparation for puppet 3.x? What if
we *are* referencing them that way, now?
>> On Sun, Aug 19, 2012 at 7:48 PM, Eric Shamow <e...@puppetlabs.com> wrote:
>>> Facts exist at top scope, as indicated in the scoping doc several people have referred you to on this list. Use $::ec2_instance_type
>>> Sent from my iPad
>>> On Aug 19, 2012, at 10:44 PM, Douglas Garstang <doug.garst...@gmail.com> wrote:
>>>> I don't get it...
>>>> if ! ( $ec2_instance_type in [$ec2_inst_type_allow]) {
>>>> notice("NOT ALLOWED")
>>>> } else {
>>>> notice("ALLOWED")
>>>> }
>>>> 2012-08-20T02:39:10.537134+00:00 truth puppet-master[24080]: Dynamic
>>>> lookup of $ec2_instance_type at /truth/sauce/env/prod/modules/rol
>>>> e/manifests/validate_server.pp:12 is deprecated. Support will be
>>>> removed in Puppet 2.8. Use a fully-qualified variable name (e.g., $
>>>> classname::variable) or parameterized classes.
>>>> Line 12 is the if statement. However, on the same client system...
On Mon, Aug 20, 2012 at 1:33 PM, Tim Mooney <Tim.Moo...@ndsu.edu> wrote:
> In regard to: Re: [Puppet Users] Dynamic Lookup of facter variable.,
> Nigel...:
>> On Sun, Aug 19, 2012 at 8:00 PM, Douglas Garstang
>> <doug.garst...@gmail.com> wrote:
>>> Oh god that's ugly.
>> Yes it is, and it was an unwitting bug with the deprecation warning
>> that is resolved in later versions.
>> Facts were supposed to be able to be referenced as $factname without
>> throwing the deprecation warning in your release, it's been fixed in
>> later versions.
> Can you expound on this, Nigel?
> Are you saying that we do *not* need to reference facts as $::factname
> in all our classes, not even in preparation for puppet 3.x? What if
> we *are* referencing them that way, now?
There's no harm in going that extra mile and being explicit that
you're looking at a top scope variable fact, rather than a local
variable of the same name, so you can continue to reference them as
$::factname if you would like to do so.
Requiring that wasn't an original goal, as it was deemed too high a
cost for the most common case to force that rather ugly syntax on
everyone. It was a bug in the deprecation warning code.
>>> Facts were supposed to be able to be referenced as $factname without
>>> throwing the deprecation warning in your release, it's been fixed in
>>> later versions.
>> Are you saying that we do *not* need to reference facts as $::factname
>> in all our classes, not even in preparation for puppet 3.x? What if
>> we *are* referencing them that way, now?
> There's no harm in going that extra mile and being explicit that
> you're looking at a top scope variable fact, rather than a local
> variable of the same name, so you can continue to reference them as
> $::factname if you would like to do so.
> Requiring that wasn't an original goal, as it was deemed too high a
> cost for the most common case to force that rather ugly syntax on
> everyone. It was a bug in the deprecation warning code.
> Does that help?
It does help, thank you.
It's one of those things that I wish I had known before I spent hours
changing our modules in preparation for what I thought was going to
be a requirement for puppet 3.x, but better late than never. :-)
I appreciate the clarity you've provided on this.
Tim
-- Tim Mooney Tim.Moo...@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
On Mon, Aug 20, 2012 at 9:50 PM, Tim Mooney <Tim.Moo...@ndsu.edu> wrote:
> In regard to: Re: [Puppet Users] Dynamic Lookup of facter variable.,
> Nigel...:
>>>> Facts were supposed to be able to be referenced as $factname without
>>>> throwing the deprecation warning in your release, it's been fixed in
>>>> later versions.
>>> Are you saying that we do *not* need to reference facts as $::factname
>>> in all our classes, not even in preparation for puppet 3.x? What if
>>> we *are* referencing them that way, now?
>> There's no harm in going that extra mile and being explicit that
>> you're looking at a top scope variable fact, rather than a local
>> variable of the same name, so you can continue to reference them as
>> $::factname if you would like to do so.
>> Requiring that wasn't an original goal, as it was deemed too high a
>> cost for the most common case to force that rather ugly syntax on
>> everyone. It was a bug in the deprecation warning code.
>> Does that help?
> It does help, thank you.
> It's one of those things that I wish I had known before I spent hours
> changing our modules in preparation for what I thought was going to
> be a requirement for puppet 3.x, but better late than never. :-)
> I appreciate the clarity you've provided on this.
> Tim
I do apologize for us messing up the deprecation warning.
It's caused a lot of unnecessary churn for everyone, and it's
frustrating for everyone involved :(
In regard to: Re: [Puppet Users] Dynamic Lookup of facter variable., Nigel...:
>> It's one of those things that I wish I had known before I spent hours
>> changing our modules in preparation for what I thought was going to
>> be a requirement for puppet 3.x, but better late than never. :-)
>> I appreciate the clarity you've provided on this.
> I do apologize for us messing up the deprecation warning.
> It's caused a lot of unnecessary churn for everyone, and it's
> frustrating for everyone involved :(
puppet's a moving target, and I think that most people that follow
the list understand that this kind of thing is going to happen on
occasion, especially when a major release is in the works. I certainly
do.
The trick is going to be stamping out places where "you must top-scope
facts" may have already crept into documentation or people's puppet
idioms.
Tim
-- Tim Mooney Tim.Moo...@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
