Jira (PUP-7276) defined types in Puppet 4 (or 3.8 future parser) lost access to scope of calling class

[Zed Pobre (JIRA)]

Title: Message Title

Zed Pobre commented on PUP-7276   Re: defined types in Puppet 4 (or 3.8 future parser) lost access to scope of calling class I was missing a couple words that might make it clearer – edited. The defines create file resources that use templates. Those templates used to have access to the variables in the scope of the calling class. After some digging, it turns out that was officially a "bug". It is correct that the define itself never had access to those variables directly. Unfortunately the fact that this was unsupported caught me by surprise, because unless you turn future parser on, you don't even get a warning about it all the way up to Puppet 3.8.5, and if you do turn future parser on, it simply starts generating null results with no indication of why. I spent half a day debugging Hiera until I figured out the problem wasn't the lookups. The issue is that we've been relying on that bug for the better part of a decade and the assumption is built into 90% of our classes, so now we're trying to reproduce it officially, because it may be less work to fork Puppet than it is to fix our classes. I need some mechanism, any mechanism, by which I can automatically pack all variables in a calling class and pass them as a parameter to a define, then inside that define unpack them unless they conflict with an existing variable. If I can't do that, then the only way I can see to make this work is to attempt to pack all of my previous logic into a function replacing template(), which then at least lets me do: file { '/etc/something/myfile': content => manage_this_file($title,$option) } but since I'm not sure functions can see the name of the class that called them (or even the calling module name), I'm not quite sure how that would work. We cannot move forward into Puppet 4 until we can come up with a mechanism by which a helper utility, be it a defined type, native type, function, whatever, can both see the contents of the filesystem on the puppetmaster and all variables in the calling class, and can be packed into a single line, or maybe two, because right now we have tens of thousands of lines of: manage_this_file { '/etc/something/somefile': option => xxx } that abstracts all of the logic so the module developers in our organization don't have to worry about it and gain access to the autodetection, etc., that we use. (Name of the define changed for humorous effect. It's actually more boring.) Add Comment   This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.