The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #13323

Issues with variable scoping.

Added by Trevor Vaughan about 2 years ago. Updated about 2 years ago.

Status:Needs DecisionStart date:03/22/2012
Priority:NormalDue date:
Assignee:Pieter van de Bruggen% Done:

0%

Category:language
Target version:-
Affected Puppet version:2.7.12 Branch:
Keywords:ambiguity, variable, scope

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket may be automatically exported to the PUP project on JIRA using the button below:


Description

According to http://docs.puppetlabs.com/guides/scope_and_puppet.html, we should be attempting to use fully qualified variable scoping across the board. However, I’ve run into a situation where there appear to be some serious issues.

Example:

class foo ($var1 = ‘something’) {}

class foo::baz { if $foo::var1 == ‘something’ { do something } }

class bar { $foo::var1 <– does not exist because it looks in bar::foo

class { ‘::foo’: var1 => ‘baz’ }

}

class bar::foo { stuff… }

The issue is that $::foo::var1 is NOT the same as $foo::var1 though both can be successfully declared anywhere across the manifest space. This causes very non-deterministic actions when using both variants though they should both really be the same thing.

So, what is correct? Should we always use $::variable::thing or is the code incorrect and they should both be valid at the top scope when there is no lower scope overriding that variable?

var_scoping_test.tgz - Test files for demonstrating the ambiguous variable scoping issue. (519 Bytes) Trevor Vaughan, 03/28/2012 04:35 pm

13323-1.pp (468 Bytes) Chris Price, 03/30/2012 02:54 pm

13323-2.pp (471 Bytes) Chris Price, 03/30/2012 02:54 pm


Related issues

Related to Puppet - Bug #13349: Incorrect scope behavior: single include may load multipl... Closed 03/23/2012

History

#1 Updated by Trevor Vaughan about 2 years ago

This is starting to cause quite the headache in places, any thoughts out there?

#2 Updated by Chris Price about 2 years ago

  • Status changed from Unreviewed to Investigating
  • Assignee set to Chris Price

#3 Updated by Chris Price about 2 years ago

  • File 13323.pp added
  • Status changed from Investigating to Needs More Information
  • Assignee changed from Chris Price to Trevor Vaughan
  • Priority changed from High to Normal

Trevor,

Can you perhaps attach a manifest that I can run “apply” on to illustrate the problems you’re describing? I’ve attached one that I was playing with to try to come up with a repro case, and I when I attempt to apply it I get this error:

Could not parse for environment production: Cannot assign to variables in other namespaces at /my/path/13323.pp:7 on node cosmicshame.puppetlabs.lan

I get similar errors if I try to copy and paste from the code snippets that you’ve provided here, and I want to make sure that we understand exactly where the scoping issues are impacting you before attempting to diagnose further.

Thanks!

#4 Updated by Trevor Vaughan about 2 years ago

Chris,

Try the attached.

In your node manifest:

include ‘foo’ include ‘foo::baz’ include ‘bar’ include ‘bar::foo’

If bar::foo did not exist, everything would work as expected.

See bar/init.pp for a demonstration of the issue.

#5 Updated by Trevor Vaughan about 2 years ago

  • Assignee changed from Trevor Vaughan to Chris Price

#6 Updated by Chris Price about 2 years ago

  • Status changed from Needs More Information to Investigating

#7 Updated by Chris Price about 2 years ago

  • File deleted (13323.pp)

#8 Updated by Chris Price about 2 years ago

  • File 13323-1.pp added
  • File 13323-2.pp added
  • Category set to language
  • Status changed from Investigating to Needs Decision
  • Assignee changed from Chris Price to Pieter van de Bruggen

Trevor, thanks, this helps clear up what you were seeing.

This is, currently, the expected behavior. Variable/name resolution for any variable that isn’t prefixed with a leading “::” will look in the current namespace first, and then the global namespace.

Whether or not this is the best long-term behavior is a different question; handing this off to our design team, who are scheduled to do some work on our DSL soon.

The two attached manifest files demonstrate the scope confusion; the second one is identical to the first, but with the “bar::foo” class commented out to demonstrate how the scope resolution is affected.

#9 Updated by Trevor Vaughan about 2 years ago

I definitely understand the logic behind this. My issue is that the language doesn’t appear to consistently recognize $foo::bar and $::foo::bar as the same variable depending on the scope, which leads to very confusing code.

I personally believe that this should either be consistent across the board, or a parse error at some level so that you don’t have code that behaves in an unexpected manner.

Thanks for looking into this!

Also available in: Atom PDF