Puppet users - Jun 2012 - Correct way to handle node-specific variable values in puppet 2.7

I saw a post a little while back about this, but didn''t see the
details of the solution. So I''m posting to see if someone can explain
to me the correct way to do this in puppet 2.7+.

I have a variable "ldap_server" that is used inside some templates.
Some of my nodes use ldap1.company.com an some use ldap2.company.com.
So in puppet 2.6 and earlier I have:

node A {
    ldap_server = "ldap1.company.com"
    include ldap_config
}

node A {
    ldap_server = "ldap2.company.com"
    include ldap_config
}

I understand that in 2.7 this behavior is deprecated because of how
variables are looked for and this behavior will stop working in 2.8.
So what is the correct way to handle this in 2.7?

Thank you.

--
Jon Schewe | http://mtu.net/~jpschewe

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

Due to the documentation not being specifically clear with regards to node 
level variables and scoping.  In 2.7 node variables they are local scope.

Therefore in your templates you call the ldap_server variable NOT 
::ldap_server as it is not a top scope variable.

As I say, the document is not specifically clear on how to qualify 
variables in the node scope, but they appear to be in the local scope - 
http://docs.puppetlabs.com/guides/scope_and_puppet.html

If you use puppet-lint it will complain about the variables not being 
qualified.  Hopefully there will be some clarification on all the variable 
and variable interpolation issues that 2.7 has highlighted, before the 
release of 2.8/3.0

This is just what I have found that works.

G

On Tuesday, June 19, 2012 4:05:26 AM UTC+1, Jon Schewe
wrote:
>
> I saw a post a little while back about this, but didn''t see the 
> details of the solution. So I''m posting to see if someone can
explain
> to me the correct way to do this in puppet 2.7+. 
>
> I have a variable "ldap_server" that is used inside some
templates.
> Some of my nodes use ldap1.company.com an some use ldap2.company.com. 
> So in puppet 2.6 and earlier I have: 
>
> node A { 
>     ldap_server = "ldap1.company.com" 
>     include ldap_config 
> } 
>
> node A { 
>     ldap_server = "ldap2.company.com" 
>     include ldap_config 
> } 
>
> I understand that in 2.7 this behavior is deprecated because of how 
> variables are looked for and this behavior will stop working in 2.8. 
> So what is the correct way to handle this in 2.7? 
>
> Thank you. 
>
> -- 
> Jon Schewe | http://mtu.net/~jpschewe 
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/rbL86S4ibI8J.
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.

Right now I''m referencing the variable as "<%= ldap_server
%>" and puppet
is complaining on startup about dynamic scoping and telling me this will
break. So clearly this isn''t the way to go otherwise I
wouldn''t have the
warning.

On Tue, Jun 19, 2012 at 7:06 AM, earthgecko <garypwilson@gmail.com> wrote:
> Due to the documentation not being specifically clear with regards to node
> level variables and scoping.  In 2.7 node variables they are local scope.
>
> Therefore in your templates you call the ldap_server variable NOT
> ::ldap_server as it is not a top scope variable.
>
> As I say, the document is not specifically clear on how to qualify
> variables in the node scope, but they appear to be in the local scope -
> http://docs.puppetlabs.com/guides/scope_and_puppet.html
>
> If you use puppet-lint it will complain about the variables not being
> qualified.  Hopefully there will be some clarification on all the variable
> and variable interpolation issues that 2.7 has highlighted, before the
> release of 2.8/3.0
>
> This is just what I have found that works.
>
> G
>
>
> On Tuesday, June 19, 2012 4:05:26 AM UTC+1, Jon Schewe wrote:
>>
>> I saw a post a little while back about this, but didn''t see
the
>> details of the solution. So I''m posting to see if someone can
explain
>> to me the correct way to do this in puppet 2.7+.
>>
>> I have a variable "ldap_server" that is used inside some
templates.
>> Some of my nodes use ldap1.company.com an some use ldap2.company.com.
>> So in puppet 2.6 and earlier I have:
>>
>> node A {
>>     ldap_server = "ldap1.company.com"
>>     include ldap_config
>> }
>>
>> node A {
>>     ldap_server = "ldap2.company.com"
>>     include ldap_config
>> }
>>
>> I understand that in 2.7 this behavior is deprecated because of how
>> variables are looked for and this behavior will stop working in 2.8.
>> So what is the correct way to handle this in 2.7?
>>
>> Thank you.
>>
>> --
>> Jon Schewe | http://mtu.net/~jpschewe
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/rbL86S4ibI8J.
> 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.
>


-- 
Jon Schewe | http://mtu.net/~jpschewe

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

----- Original Message -----
> From: "Jon Schewe" <jpschewe@mtu.net>
> To: puppet-users@googlegroups.com
> Sent: Tuesday, June 19, 2012 1:13:09 PM
> Subject: Re: [Puppet Users] Re: Correct way to handle node-specific
variable values in puppet 2.7
> 
> Right now I''m referencing the variable as "<%= ldap_server
%>" and
> puppet is complaining on startup about dynamic scoping and telling
> me this will break. So clearly this isn''t the way to go otherwise
I
> wouldn''t have the warning.
I think this warning is gone in a slightly newer version of 2.7.x

what version are you on?

-- 
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 Tuesday, June 19, 2012 7:20:47 AM UTC-5, R.I. Pienaar wrote:
> > Right now I''m referencing the variable as "<%=
ldap_server %>" and
> > puppet is complaining on startup about dynamic scoping and telling 
> > me this will break. So clearly this isn''t the way to go
otherwise I
> > wouldn''t have the warning. 
>
> I think this warning is gone in a slightly newer version of 2.7.x 
>
Have I missed a change in plan for node variables, so that in Puppet 3 they 
remain accessible outside node declarations?  Does that form of dynamic 
scoping live on?

Whether referencing node variables is deprecated or not, there are several 
alternatives:

   - global variables can be used instead if you have an ENC to set 
   node-specific values for them, and
   - some people would recommend parameterizing your class,
   - but I would recommend putting your node-specific data in an external 
   data store and accessing them via hiera.
   
John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/uCk1FJOcTYAJ.
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 Tue, Jun 19, 2012 at 7:20 AM, R.I.Pienaar <rip@devco.net> wrote:
>
>
> ----- Original Message -----
> > From: "Jon Schewe" <jpschewe@mtu.net>
> > To: puppet-users@googlegroups.com
> > Sent: Tuesday, June 19, 2012 1:13:09 PM
> > Subject: Re: [Puppet Users] Re: Correct way to handle node-specific
> variable values in puppet 2.7
> >
> > Right now I''m referencing the variable as "<%=
ldap_server %>" and
> > puppet is complaining on startup about dynamic scoping and telling
> > me this will break. So clearly this isn''t the way to go
otherwise I
> > wouldn''t have the warning.
>
> I think this warning is gone in a slightly newer version of 2.7.x
>
> what version are you on?
>
> 2.7.6
-- 
Jon Schewe | http://mtu.net/~jpschewe

-- 
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 Tue, Jun 19, 2012 at 9:19 AM, jcbollinger
<John.Bollinger@stjude.org>wrote:
>
>
> On Tuesday, June 19, 2012 7:20:47 AM UTC-5, R.I. Pienaar wrote:
>
>> > Right now I''m referencing the variable as "<%=
ldap_server %>" and
>> > puppet is complaining on startup about dynamic scoping and telling
>> > me this will break. So clearly this isn''t the way to go
otherwise I
>> > wouldn''t have the warning.
>>
>> I think this warning is gone in a slightly newer version of 2.7.x
>>
>
> Have I missed a change in plan for node variables, so that in Puppet 3
> they remain accessible outside node declarations?  Does that form of
> dynamic scoping live on?
>
> Whether referencing node variables is deprecated or not, there are several
> alternatives:
>
>    - global variables can be used instead if you have an ENC to set
>    node-specific values for them, and
>    - some people would recommend parameterizing your class,
>    - but I would recommend putting your node-specific data in an external
>    data store and accessing them via hiera.
>
>
> Am I getting this right that instead of just leaving the functionality in
puppet I should now call out to another application to have node-specific
variables? This seems like a step in the wrong direction. It''s really
nice
that in puppet 2.6 I''ve been able to keep all of my configuration in my
nodes.pp file.


-- 
Jon Schewe | http://mtu.net/~jpschewe

-- 
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 Tuesday, June 19, 2012 11:02:55 AM UTC-7, Jon Schewe
wrote:
>
>
> Am I getting this right that instead of just leaving the functionality in 
> puppet I should now call out to another application to have node-specific 
> variables? This seems like a step in the wrong direction. It''s
really nice
> that in puppet 2.6 I''ve been able to keep all of my configuration
in my
> nodes.pp file. 
>
> No no no! Don''t worry. I''m actually in  the process of
codifying this for
the reference docs right now, but here are the "new" scoping rules:

Local scope -> inherited scope (as created by the "inherits"
keyword; these
should remain fairly rare) -> node scope -> top scope

Node scope is staying a thing, because it has to for the time being. 

- It''s unfortunately anonymous, so there''s no way to address
it directly.
You have to use the variable''s short name to get there.
- But you can most assuredly get there. 
- However, some versions in the 2.7.x series issue a false warning when 
you''re trying to get to node scope. more recent versions should have
that
fixed. 

Did that clear things up? 

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/PiDnrx-QzPMJ.
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 Tue, Jun 19, 2012 at 2:43 PM, Nick Fagerlund <
nick.fagerlund@puppetlabs.com> wrote:
>
>
> On Tuesday, June 19, 2012 11:02:55 AM UTC-7, Jon Schewe wrote:
>>
>>
>> Am I getting this right that instead of just leaving the functionality
in
>> puppet I should now call out to another application to have
node-specific
>> variables? This seems like a step in the wrong direction. It''s
really nice
>> that in puppet 2.6 I''ve been able to keep all of my
configuration in my
>> nodes.pp file.
>>
>> No no no! Don''t worry. I''m actually in  the process
of codifying this for
> the reference docs right now, but here are the "new" scoping
rules:
>
> Local scope -> inherited scope (as created by the "inherits"
keyword;
> these should remain fairly rare) -> node scope -> top scope
>
> Node scope is staying a thing, because it has to for the time being.
>
> - It''s unfortunately anonymous, so there''s no way to
address it directly.
> You have to use the variable''s short name to get there.
> - But you can most assuredly get there.
> - However, some versions in the 2.7.x series issue a false warning when
> you''re trying to get to node scope. more recent versions should
have that
> fixed.
>
> Did that clear things up?
>
>
> So what I''m currently doing is perfectly valid and should continue
to work
with 2.8, I''ve just got a version that''s giving me extra
warnings. Correct?


-- 
Jon Schewe | http://mtu.net/~jpschewe

-- 
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 Tuesday, June 19, 2012 1:24:42 PM UTC-7, Jon Schewe
wrote:
>
>
> So what I''m currently doing is perfectly valid and should continue
to work
> with 2.8, I''ve just got a version that''s giving me extra
warnings. Correct?
>
>
Yup! ...sorry about that. Implementing those warnings correctly turned out 
to be more complicated than we originally thought.  

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/dSV2jKqOiUgJ.
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 Tue, Jun 19, 2012 at 3:41 PM, Nick Fagerlund <
nick.fagerlund@puppetlabs.com> wrote:
>
>
> On Tuesday, June 19, 2012 1:24:42 PM UTC-7, Jon Schewe wrote:
>>
>>
>> So what I''m currently doing is perfectly valid and should
continue to
>> work with 2.8, I''ve just got a version that''s giving
me extra warnings.
>> Correct?
>>
>>
> Yup! ...sorry about that. Implementing those warnings correctly turned out
> to be more complicated than we originally thought.
>
>
>
Thank you very much for your quick replies!

-- 
Jon Schewe | http://mtu.net/~jpschewe

-- 
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 Tuesday, June 19, 2012 7:19:20 AM UTC-7, jcbollinger
wrote:
>
>
> Have I missed a change in plan for node variables, so that in Puppet 3 
> they remain accessible outside node declarations?  Does that form of 
> dynamic scoping live on?
>
>
Yeah, they''re effectively a tiny island of dynamic scoping in the 
otherwise-static sea. It turned out we had to do it that way -- we''re 
working on replacing node definitions as we know them with something 
better, but we couldn''t do everything in one fell swoop, so
we''re in a bit
of an awkward stage for the moment. 

What I''ve been trying to tell people is:

- node scope is special
- it overrides top scope
- everything (including classes from ENCs!) gets the combined contents of 
node and top scope
  - UNLESS it''s a class you EXPLICITLY declared outside of node scope.
- oh, and don''t ever use node inheritance.

There might be a better way to talk about that; if so, we''ll figure it
out
as we go. 

On Tuesday, June 19, 2012 7:19:20 AM UTC-7, jcbollinger
wrote:
>
>
>
> On Tuesday, June 19, 2012 7:20:47 AM UTC-5, R.I. Pienaar wrote:
>
>> > Right now I''m referencing the variable as "<%=
ldap_server %>" and
>> > puppet is complaining on startup about dynamic scoping and telling
>> > me this will break. So clearly this isn''t the way to go
otherwise I
>> > wouldn''t have the warning. 
>>
>> I think this warning is gone in a slightly newer version of 2.7.x 
>>
>
> Have I missed a change in plan for node variables, so that in Puppet 3 
> they remain accessible outside node declarations?  Does that form of 
> dynamic scoping live on?
>
> Whether referencing node variables is deprecated or not, there are several 
> alternatives:
>
>    - global variables can be used instead if you have an ENC to set 
>    node-specific values for them, and
>    - some people would recommend parameterizing your class,
>    - but I would recommend putting your node-specific data in an external 
>    data store and accessing them via hiera.
>    
> John
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/aDb4tWzEwxwJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi,

On 06/19/2012 10:24 PM, Jon Schewe wrote:
> 
>     Node scope is staying a thing, because it has to for the time being.
> 
>     - It''s unfortunately anonymous, so there''s no way to
address it
>     directly. You have to use the variable''s short name to get
there.
>     - But you can most assuredly get there.
>     - However, some versions in the 2.7.x series issue a false warning
>     when you''re trying to get to node scope. more recent versions
should
>     have that fixed.
> 
>     Did that clear things up?
> 
> 
> So what I''m currently doing is perfectly valid and should continue
to
> work with 2.8, I''ve just got a version that''s giving me
extra warnings.
> Correct?
I don''t like to be the naysayer, but I don''t like to let that
stand -
hiera is not some third party mashup you can loosely tie to puppet.
It''s
been designed by our very own R.I. Pienaar for the sole purpose of
*relieving* you from the burden of managing your data inside nodes.pp
(of course, as long as it works, you''re free to choose to do that
anyway).

My understanding is that come puppet 3.0, hiera will be a first classe
citizen and part of the puppet core proper. It''s actually a supposedly
superior way to store node data than manifest variables.

Please don''t get me wrong - everyone should find what works best for
themselves, and by all means stick to it. Only meant to point out that
hiera is an awesome concept that shouldn''t be dismissed.

Cheers,
Felix

-- 
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 Tuesday, June 19, 2012 4:07:56 PM UTC-5, Nick Fagerlund
wrote:
>
>
>
> On Tuesday, June 19, 2012 7:19:20 AM UTC-7, jcbollinger wrote:
>>
>>
>> Have I missed a change in plan for node variables, so that in Puppet 3 
>> they remain accessible outside node declarations?  Does that form of 
>> dynamic scoping live on?
>>
>>
> Yeah, they''re effectively a tiny island of dynamic scoping in the 
> otherwise-static sea. It turned out we had to do it that way --
we''re
> working on replacing node definitions as we know them with something 
> better, but we couldn''t do everything in one fell swoop, so
we''re in a bit
> of an awkward stage for the moment. 
>
Great, thanks for clearing that up.

What I''ve been trying to tell people is:
>
[...]
> - oh, and don''t ever use node inheritance.
>
Why not?  I mean, is that just to avoid the known issues with dynamic 
scope, or does node inheritance introduce special problems in this 
context?  


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/D7zQ9XCZ98QJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wednesday, June 20, 2012 6:00:04 AM UTC-7, jcbollinger
wrote:
>
>
> - oh, and don''t ever use node inheritance.
>>
>
> Why not?  I mean, is that just to avoid the known issues with dynamic 
> scope, or does node inheritance introduce special problems in this 
> context?  
>
Well... because inevitably, everyone always wants to try this: 

node ''base'' {
  $ntpserver = 0.pool.ntp.org
  include ntp
}

node ''special'' inherits ''base'' {
  $ntpserver = ntp.local.example.com 
}

See how dynamic scope is being perfectly well-behaved here, but it still 
does the exact opposite of what they were hoping for? :[ The underlying 
model of how node defs work is corrupt -- we just copied the logic we use 
for classes, and it was a bad match for that  problem space.

I think I''m convinced now that the long-term answer is to gradually
replace
node definitions with something better but just as easy to get started 
with. And we''re moving in that direction, especially now that we have
hiera
baked in. In the meantime... awkward stage. 

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/QMwONSlnGBoJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thursday, June 21, 2012 5:44:46 PM UTC-5, Nick Fagerlund
wrote:
>
>
> inevitably, everyone always wants to try this: [...]
>
I don''t!  :-)

That''s what I suspected you were getting at, so thanks for clarifying.
That node inheritance works like class inheritance has never bothered me in 
the slightest; indeed, I prefer having only one set of rules to remember.

[...] I think I''m convinced now that the long-term answer is to
gradually 
> replace node definitions with something better but just as easy to get 
> started with. And we''re moving in that direction, especially now
that we
> have hiera baked in. In the meantime... awkward stage.
>
I look forward to that new and better thing with both anticipation and 
apprehension.  Because, you know, newer isn''t always better, especially
to
a stick-in-the-mud like me.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/g42OI0w4GGgJ.
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.