Issue #5152 has been updated by Markus Roberts. Subject changed from Module autoloader behaviour needs better definition to Module autoloader behaviour needs better documentation Category set to documentation Status changed from Unreviewed to Accepted
I'm accepting this as a documentation since that much is clearly needed, sorting out if there actually is a problem beyond what's covered by other tickets, well... ---------------------------------------- Bug #5152: Module autoloader behaviour needs better documentation https://projects.puppetlabs.com/issues/5152 Author: eric sorenson Status: Accepted Priority: Normal Assignee: Category: documentation Target version: Affected Puppet version: Keywords: Branch: A few times recently we've run into problems that seem to be in the module autoloader (this is the DSL-level loader, not the file resolution autoloader for types/providers). The docs at http://docs.puppetlabs.com/guides/modules.html are glib, inaccurate and incomplete: <blockquote> With namespaces, some additional magic is also available. Let’s say your autofs module has a class defined in init.pp but you want an additional class called craziness. If you define that class as autofs::craziness and store it in file craziness.pp under the manifests directory, then simply using something like include autofs::craziness will trigger puppet to <i>search for a class called craziness</i> in a file named craziness.pp in a module named autofs in the specified module paths. Hooray! </blockquote> The italicised phrase is wrong because puppet actually searches for 'class autofs::craziness', and it's incomplete because the third-level submodule loading seems to behave somewhat differently. (Not much else I can say about the glibness :) ) Keeping with the example above, the classes autofs::craziness::morecrazy and autofs::craziness::craziest might either: <ul> <li> also be defined in craziness.pp</li> <li> require a subdirectory autofs/manifests/craziness/, where they might <ul> <li> reside together in init.pp </li> <li> reside separately in morecrazy.pp and craziest.pp , respectively. </ul></li> </ul> The weird stuff seems to happen when there is both an autofs/manifests/craziness.pp *and* a directory autofs/manifests/craziness/; errors that look like syntax rejection are logged: <pre> Oct 28 19:17:22 puppetmaster001 puppetmasterd[2361]: Could not find class x::y::z for host.mydomain.com </pre> But the files individually pass syntax checks. Could someone please: - tell me if my expectation is wrong about how this ought to work - take a pass at the paragraph I quoted above to extend it to describe the actual code-path for deeper-nested classes. I'd be happy to work up a test set of modules if that's helpful, but maybe I'm just plain wrong about something and can be set straight quickly. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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-bugs?hl=en.
