On Tue, Nov 27, 2012 at 12:17 PM, Erik Dalén <[email protected]>wrote:
> On Tuesday 27 November 2012 at 20:17, llowder wrote: > > > > > > On Tuesday, November 27, 2012 1:10:02 PM UTC-6, Andy Parker wrote: > > > On Tue, Nov 27, 2012 at 1:26 AM, Erik Dalén > > > <[email protected](javascript:)> wrote: > > > > On Monday 26 November 2012 at 18:58, Andy Parker wrote: > > > > > On Mon, Nov 26, 2012 at 8:28 AM, llowder > > > > > <[email protected](javascript:) (mailto: > [email protected] (javascript:))> wrote: > > > > > > After doing some digging and poking around, I have found out why > it is doing what it is doing, and why include and param syntaxes work > differently. > > > > > > > > > > > > There are a few different ways to fix this, but the implications > are somewhat wide reaching and there isn't an easy fix. > > > > > > > > > > > > The basic problem is that nodes get loaded as classes - "node > ubuntu" and "node /ubuntu/" both load a class named "ubuntu" while "node > /ubunt./" loads a class named "ubunt.". > > > > > > > > > > > > Using param syntax ( class { 'ubuntu': } ) the class gets loaded > regardless of which type of node def you use, while using include syntax, > it only gets loaded for the wild card regex node name ( node /ubunt./ ). > > > > > > > > > > > > There are two general ways this can be fixed. > > > > > > > > > > > > 1) Make include syntax work like param syntax, where the class > always gets loaded. > > > > > > 2) Disallow nodes and classes to have the same name all together > > > > > > > > > > > > 2 isn't that good of an option, and would not be an option in > the 2.7 or 3.x lines under SemVer, as it would be backwards incompatible, > so 4.x would be the minimum target for it. > > > > > > > > > > Yeah, option 2 doesn't seem ideal. It also doesn't seem right that > we put in a restriction like that simply because the internals can't tell > things apart. Bad UX. > > > > > > > > Well, as you can reference a variable in the node ubuntu using > $ubuntu::variable and you can reference a variable in the class ubuntu > using $ubuntu::variable I don't see how you could allow both at the same > time. > > > > > > I don't seem to be able to reference a node variable directly: > > > > > > > bundle exec puppet apply -e 'node aparker { > > > $a = "node" > > > include foo > > > } > > > class foo { notice($aparker::a) } > > > ' > > > Warning: Scope(Class[Foo]): Could not look up qualified variable > 'aparker::a'; class aparker could not be found > > > Scope(Class[Foo]): > > > Finished catalog run in 0.03 seconds > > > > > > > > > > > You can't. A while back there appearantly some discussion as to whether > or not top scope or node scope should be used when $::foo was used. Top > scope won, and node scope became only accessible in that actual node - > outside of classes. > > > > It would be nice if there was a way to access $node::foo though, but I > think hiera now provides a much cleaner way of providing that sort of > thing, at least for all the use cases I can think of (node level 'global' > defaults that differ from node to node enough to not be a pure topscope > global) > > > > I was sure that worked, been a while since I used nodes at all :) > > But it seems you can lookup a node scope variable outside of the node > scope. But I think it is a bit confusing design that a variable defined in > a node scope doesn't work the same as a variable defined for the node in a > ENC. Can also make it a bit trickier to switch between the two. > Example from http://docs.puppetlabs.com/guides/scope_and_puppet.htmlwhich > seems to work. > > $var = "from topscope" > node default { > $var = "from node" > include lookup_example > } > class lookup_example { > notify { $var: } # will be "from node" > notify { $::var: } # will be "from topscope" > } > Yes, that is the expected behavior. There is a lot of historical reason for this and also the reason that the current scoping algorithm is getting called "2-step scoping" internally :) The rules for looking up a variable boil down to: * if the variable contains '::' then split it into the class name and the variable name. Lookup the class and then read the variable out of that classes scope object (yes, there are some odd things you can do with that) * otherwise look up by walking scopes in the following order looking for the first definition found: current scope, inherited class scopes (all the way up inheritance), bound node scope, inherited node scopes, topscope. All in all, this doesn't pose a problem for the issue being discussed, since you can't directly reference a node scope and so the collision between node and class should be able to be cleared up without problem (at least from that perspective) > > > > > > > > > > I think we either have to always rename the node scope to something > like "node" and not allow classes with that name (would also make it easy > to reference variables in the node scope as it has a fixed name). > > > > > > > > Or skip having a special node scope and just merge it with the top > scope, which would also make variables in it work more like variables in a > ENC. > > > > > > > > Neither of these options are entirely backwards compatible though, > but I'm not sure any solution to this problem can be entirely backwards > compatible. > > > > > > There are all sorts of problems with combining top and node scope. A > few months ago I proposed that, but it is a large change that breaks things > that people depend on. > > > > > > > -- > > > > Erik Dalén > > > > > > > > > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > Groups "Puppet Developers" group. > > > > To post to this group, send email to > > > > [email protected](javascript:). > > > > To unsubscribe from this group, send email to > [email protected] (javascript:). > > > > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "Puppet Developers" group. > > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-dev/-/v1HFPFu99acJ. > > To post to this group, send email to [email protected](mailto: > [email protected]). > > To unsubscribe from this group, send email to > [email protected] (mailto: > [email protected]). > > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
