Scope problem in 2.7.12, bug?

[Walter Heck - OlinData.com]

I was playing around with scopes, and I noticed the following
behaviour, which strikes me as odd? This was done with Puppet
Enterprise 2.5.3 which is really Puppet 2.7.12.
I'm not sure what I would expect, quite likely an error message or at
the very least 'mysql-server' package gettign installed. Instead, it
just seems to choose the top-scope variable 'mysql'

$package = 'mysql'

class mysql {
package { $mysql_server::package:
ensure => present
}
}

class mysql_server {
include mysql
$package = 'mysql-server'
}

include mysql_server


This yields:
[root@master test]# puppet apply manifests/init.pp
notice: /Stage[main]/Mysql/Package[mysql]/ensure: created
notice: Finished catalog run in 6.25 seconds


cheers,

--
Walter Heck
CEO and Founder @ OlinData (http://olindata.com)
Puppet training and consulting
--
Follow @olindata on Twitter and/or 'Like' our Facebook page at
http://www.facebook.com/olindata

[Stefan Heijmans]

No, i's not, it is correct, see http://docs.puppetlabs.com/guides/scope_and_puppet.html

At the moment you 'include mysql' only the top scope package variable is known, so there fore mysql package will be installed.

swap them around and mysql-server package will get installed.

 class mysql_server { 
  $package = 'mysql-server' 
  include mysql 

[Stefan Heijmans]

or here; http://docs.puppetlabs.com/puppet/2.7/reference/lang_scope.html

[Walter Heck - OlinData.com]

Hello,

On Sun, Nov 18, 2012 at 6:47 PM, Stefan Heijmans
<heij...@rechtspraak.nl> wrote:
> No, i's not, it is correct, see
> http://docs.puppetlabs.com/guides/scope_and_puppet.html
>
> At the moment you 'include mysql' only the top scope package variable is
> known, so there fore mysql package will be installed.
> swap them around and mysql-server package will get installed.

but I am specifically referring to _not_ the top-scope variable by
using $mysql_server::package. This is a scope that doesn't have that
variable (yet, anyway). I don't expect Puppet to just jump to a higher
level scope (top-scope in this case) to go and look for my variable
there.

[jcbollinger]

On Sunday, November 18, 2012 2:35:56 PM UTC-6, Walter Heck - OlinData.com wrote:

Hello,

On Sun, Nov 18, 2012 at 6:47 PM, Stefan Heijmans
<heij...@rechtspraak.nl> wrote:
> No, i's not, it is correct, see
> http://docs.puppetlabs.com/guides/scope_and_puppet.html
>
> At the moment you 'include mysql' only the top scope package variable is
> known, so there fore mysql package will be installed.
> swap them around and mysql-server package will get installed.
but I am specifically referring to _not_ the top-scope variable by
using $mysql_server::package. This is a scope that doesn't have that
variable (yet, anyway). I don't expect Puppet to just jump to a higher
level scope (top-scope in this case) to go and look for my variable
there.

I agree, it looks like a bug to me.  A variable reference should never evaluate a variable that doesn't match the given name.  I would file a ticket.

The issue may be less straightforward than it first appears, however.  Consider the difference between $mysql_server::package and $::mysql_server::package.  In the vast majority of cases, I would expect them to evaluate to the same thing (including manifesting the same bug in this case).  But what if there were also this class:

class mysql::mysql_server {
  $package = 'mysql-server55'
}

Assume that mysql::mysql_server is declared before class mysql.  What value do you then expect when class mysql dereferences $mysql_server::package?  That is, do you get "mysql-server" from $::mysql_server::package or "mysql-server55" from $::mysql::mysql_server::package?  I think you get the latter, and I think that's reasonable.  Moreover, I would guess that the support for that behavior is where the bug is hiding.


John

[Walter Heck - OlinData.com]

Bug reported here: http://projects.puppetlabs.com/issues/17799