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.html which 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" } > > > > > > > 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.
