On Sun, Aug 12, 2012 at 2:43 PM, Eric Shamow <e...@puppetlabs.com> wrote:
> 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 is an import concept. It is very simple to think "include" in puppet == "include" in C. No, they are much different > > 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. > > In fact, this is the best analogy. But clearly it is easy for everyone to make mistakes especially if you are following the examples of "Pro Puppet" - incidentally, this book contains the same configuration discussed in this thread that was valid for puppet 2.6 but it is not anymore for puppet 2.7 Best Regards > -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. > > -- 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.
