On Monday, November 26, 2012 11:58:07 AM UTC-6, Andy Parker wrote:
>
> On Mon, Nov 26, 2012 at 8:28 AM, llowder <[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.
>
>
>> For 1.. there are a few ways I have been able to come up with, but none
>> they all have potentially far reaching implications.
>>
>> a) munge the class names if the class is a node
>> b) use a new scope level for nodes (this would also allow node level
>> variables to be accessible in classes, which they currently are not)
>>
>> Both of these options have potential to break things. I somewhat like
>> option a, but I am not familiar with the code to be able to be sure that
>> all access points to that name would properly munge/demunge so as to be
>> transparent / not break existing code, if that is even possible.
>>
>
> I remember we talked about this, but why can't we just make "include foo"
> do the exact same things as "class { foo: }"?
>
The question is.. how? include will check to see if the class is already
loaded, and if it is not, then it loads the class, if it has been, then it
skips it and moves on to the next.
Param syntax does not do this check, and will throw an error if the class
is already loaded.
What I don't understand is why having two classes "ubuntu" and "ubuntu"
doesn't cause an error, yet does cause the include to misfire.
One of the things that was mentioned in IRC involved checking when the
class was loaded to see if it was a node or an actual class, but I am
unsure how to do that.
In puppet/lib/puppet/parser/ast/resource.rb it has:
scope.compiler.add_resource(scope, resource)
scope.compiler.evaluate_classes([resource_title],scope,false) if
fully_qualified_type == 'class'
"fully_qualified_type" is set with the line: fully_qualified_type,
resource_titles = scope.resolve_type_and_titles(type, resource_titles)
In the include function, it just has:
klasses = compiler.evaluate_classes(vals, self, false)
I did find in the compiler where I can check the type of a resource being
added to a catalog, but not yet figured out how to use that do something
useful
>
>>
>> With option b, I also cannot think of any way to do it that would be
>> compatible with existing code.
>>
>> Does anyone have any thoughts / ideas? Is this even something that
>> "needs" to be fixed in the 2.7.x or 3.x code bases?
>>
>
> It is something that needs to be resolved at some point, but I don't think
> the timing on it is critical.
>
>
>>
>> This bug isn't something that impacts me personally - I just thought it
>> looked interesting. I don't have any uses cases that would need to do this,
>> but I can see how in some cases it would be useful, especially when it
>> comes to bootstrapping.
>>
>>
> You do like jumping in at the deep end, don't you :)
>
>
>>
>> Details of #1372 are at http://projects.puppetlabs.com/issues/1372
>>
>> --
>> 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/-/FR2eGTDbCjUJ.
>> 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/-/PIfH_fmKIowJ.
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.
