On Monday 26 November 2012 at 18:58, Andy Parker wrote: > On Mon, Nov 26, 2012 at 8:28 AM, llowder <[email protected] > (mailto:[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.
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 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. -- 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]. 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.
