First off, it's important to distinguish import from include. They "feel" like similar concepts but they're not - import goes and physically loads a file. Include says "ensure that this class is part of this host's resource graph."
It's important not to think of Puppet in procedural, top-down terms. We haven't just said, "give me all the stuff in this class, and now do these things." Rather we are building a model of a server, and manifest code simply informs pieces of that model. So by saying "include <class>" you are really saying, "Puppet, if you haven't already, make sure this class is part of the overall resource graph." The better model for this example is, rather than a box inside of a box, you are looking at two sealed boxes sitting side by side. When you include the first group, it is added to the list of boxes used. Within the first box, when you then say "give me the second box," that second box is placed *alongside* the first. Thus in order to grab anything from it, you have to specify "I need the stuff from box 2." Does that analogy help a bit more? The reason for this is that, as your number of classes grows, so too will your variables. If they share a single global namespace, the likelihood of a global variable name being used more than once increases. This can lead to really unexpected changes and ambiguity in building the graph. An example: suppose is this module you say $puppetmaster = "myserver.local" and in another module, you want to only run on a puppet master and so say $puppetmaster = true. When Puppet assembles the model of your system, which of the two is to be applied where? Dynamic scoping tried to guess at this. The idea here is to say, eliminate ambiguity - tell us exactly which one you want. -Eric -- Eric Shamow Professional Services http://puppetlabs.com/ ©631.871.6441 Join us for PuppetConf 2012 at the Mission Bay Convention Center in San Francisco, California on September 27th and 28th --> http://bit.ly/pcsig12 On Sunday, August 12, 2012 at 2:35 AM, Zachary Alex Stern wrote: > So, your explanation makes sense to me - but that doesn't exactly explain to > me why the "include" statement isn't enough. > > E.g. when I'm "including the puppet::params class in the puppet::config > class, what affect is it having at all, if not setting things like the > variables included in the original puppet::params class? > > How can I change variables on the fly effectively, if I can't just do the > import and then have the variable $puppetserver equal the one from the > imported class? I'm having a hard time grasping what import does, if not this. > > On Saturday, August 11, 2012 10:36:48 PM UTC-4, Eric Shamow wrote: > > The best reference to explain how variable scoping works in Puppet is this > > one - > > > > http://docs.puppetlabs.com/guides/scope_and_puppet.html > > > > Scoping has changed with 2.7, so you may find some confusing references > > online that follow the pre-2.7 rules. In general the 2.7 changes are > > designed to introduce some sanity to variable scopes and eliminate dynamic > > scoping, which causes all kinds of pain. > > > > The easiest way to think about scoping in general is that a scope is > > defined by its container. If I put something physical in a box, I have > > access to it the moment I open the box, and other objects inside the box > > can interact with it. If, however, I now put that box inside a second box, > > the objects in the second box cannot interact directly with the objects in > > the first - the first object is protected by its container. > > > > Scoping mostly works the same way. The right way to get at the variable is > > to always explicitly scope, as you began to get at below with your > > scope.lookupvar example. As that can be a bit of a pain to repeat, you can > > always copy the value into a local variable: > > > > class puppet::config { > > include puppet::params > > $puppetserver = puppet::params::puppetserver > > … > > } > > > > -Eric > > > > -- > > > > Eric Shamow > > Professional Services > > http://puppetlabs.com/ > > ©631.871.6441 > > > > Join us for PuppetConf 2012 at the Mission Bay Convention Center in San > > Francisco, California on September 27th and 28th --> http://bit.ly/pcsig12 > > > > > > On Saturday, August 11, 2012 at 8:45 PM, Zachary Stern wrote: > > > > > I'm having a really hard time grasping how variables are scoped in > > > puppet (not really much of a programmer). > > > > > > I've got a manifest that looks like this: > > > ### > > > class puppet::config { > > > include puppet::params > > > file { '/etc/puppet/puppet.conf': > > > ensure => present, > > > content => template('puppet/puppet.conf.erb'), > > > owner => 'root', > > > group => 'admins', > > > require => Class['puppet::install'], > > > notify => Class['puppet::service'], > > > } > > > } > > > ### > > > > > > > > > I've then got a manifest like this, which has a class being included > > > above: > > > ### > > > class puppet::params { > > > $puppetserver = 'command.enterawesome.com > > > (http://command.enterawesome.com) (http://command.enterawesome.com)' > > > } > > > ### > > > > > > The template being used in the first class includes the variable > > > $puppetserver, but somehow, the include statement isn't enough for the > > > variable to be defined within the scope of the manifest/template > > > above. > > > What gives? > > > It works just fine if I include a statement like this in the erb file: > > > <%= scope.lookupvar('puppet::params::puppetserver') %> > > > > > > But I'd really like to understand scoping better. What is it I need to > > > do to just refer to the variable by name? Why isn't the include > > > statement enough? Isn't in including the puppet::params class inside > > > the puppet::config class, and therefore having the variable defined in > > > that context? Apparently not. But I don't understand why. I wan't to > > > end up at a point where the variable is in the proper scope, such that > > > I can just have a statement like <%= puppetserver %> inside of the > > > template I'm using. > > > > > > Thanks in advance! > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Puppet Users" group. > > > To post to this group, send email to puppet...@googlegroups.com > > > (javascript:) (mailto:puppet...@googlegroups.com (javascript:)). > > > To unsubscribe from this group, send email to > > > puppet-users...@googlegroups.com (javascript:) > > > (mailto:puppet-users+unsubscr...@googlegroups.com (javascript:)). > > > For more options, visit this group at > > > http://groups.google.com/group/puppet-users?hl=en. > > > > -- > 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/-/LcHGaFjy9JkJ. > To post to this group, send email to puppet-users@googlegroups.com > (mailto:puppet-users@googlegroups.com). > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com > (mailto:puppet-users+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
