shouldn't this be considered a bug?

[Jist Anidiot]

So I thought puppet didn't care about the order of things unless specifically told.  However I've come across one case where it apparently does care.

This "works" as expected:

node /^univ\d+\.foo\.edu$/ {

$myvar = "foo"

include module_that_uses_myvar

}


This one doesn't "work" as expected


node /^univ\d+\.foo\.edu$/ {

include module_that_uses_myvar

$myvar = "foo"

}

In the 2nd one, module_that_uses_myvar seems to think $myvar is undef or null or something that is most certainly not "foo" If it matters any, $myvar is actually used in an erb template that the module has.  Our puppet master is 2.7.12 and the client is 2.6.17.

I didn't see any bug reports about this.  Is this a known problem or just not considered a bug?

[Christopher Wood]

To the best of my knowledge, it is resources that can be applied in any order, not scoped variables.

Your puppet agent will create these files in any order, given that the file resources have no require/before dependencies:

node myserver {
file { '/tmp/1':
content => "123\n",
}
file { '/tmp/2':
content => "456\n",
}
}

But here, no file will contain the string "what":

node myserver {
file { '/tmp/1':
content => "${what}123\n",
}
file { '/tmp/2':
content => "${what}456\n",
}
$var = 'what'

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

[jcbollinger]

On Monday, November 5, 2012 2:06:09 PM UTC-6, Jist Anidiot wrote:

So I thought puppet didn't care about the order of things unless specifically told.  However I've come across one case where it apparently does care.

You had a serious misunderstanding.  Puppet has numerous sensitivities to the order in which it parses declarations in your manifests.  You were probably thinking about how Puppet does not promise to apply resources in any particular order unless you tell it otherwise by declaring relationships, but there it's you who may not care, not Puppet.

 

This "works" as expected:

node /^univ\d+\.foo\.edu$/ {

$myvar = "foo"

include module_that_uses_myvar

}


This one doesn't "work" as expected


node /^univ\d+\.foo\.edu$/ {

include module_that_uses_myvar

$myvar = "foo"

}

In the 2nd one, module_that_uses_myvar seems to think $myvar is undef or null or something that is most certainly not "foo" If it matters any, $myvar is actually used in an erb template that the module has.  Our puppet master is 2.7.12 and the client is 2.6.17.

I didn't see any bug reports about this.  Is this a known problem or just not considered a bug?

It is not considered a bug.  It is the manifest author's responsibility to ensure that any reference to a class, resource, or variable is preceded by a declaration of that entity in Puppet's parse order.

Use of dynamically-scoped variables is considered poor practice, however, including any use of node-scoped variables outside their node blocks.  Your v. 2.7 master ought to be emitting warnings about that.


John