Correct way to handle node-specific variable values in puppet 2.7

[Jon Schewe]

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

[earthgecko]

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

[Jon Schewe]

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.

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

[R.I.Pienaar]

----- Original Message -----
> From: "Jon Schewe" <jpsc...@mtu.net>
> To: puppet...@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?

[jcbollinger]

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

[Jon Schewe]

2.7.6

--

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

[Jon Schewe]

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.

[Nick Fagerlund]

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?

[Jon Schewe]

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?

[Nick Fagerlund]

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. 

[Jon Schewe]

Thank you very much for your quick replies!

[Nick Fagerlund]

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.

[Felix Frank]

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

[jcbollinger]

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

[Nick Fagerlund]

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.

[jcbollinger]

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