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 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].
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.

Reply via email to