On Mon, Nov 26, 2012 at 8:28 AM, llowder <[email protected]> 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: }"?
>
> 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].
> 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.
