> Once again, I hit a "documentation is lacking" problem. > > The above command generates a whole BUNCH of files: > ./tests/init.pp > ./README > ./Modulefile > ./spec/spec.opts > ./spec/spec_helper.rb > ./metadata.json > ./manifests/init.pp
Yeah - my bad, I'm sorry - try 'puppet module build' after creating a Module file. Puppet module generate wasn't what you wanted - although you've seen now how it can be used to generate at least a basic template. > But the README is utterly useless in mentioning what the contents of each of > those files is supposed to be. > > Also... my earlier assumption seems to be correct. In principle, at least. > Just looking at the "best practices layout" autogenerated there... this > seems to be primarily geared towards *classes*, and end user "modules". > Not back end "here's a whole new resource type" code. I think we aim there for the common case. See my comments at the end of the email. > And IMO, that's as it should be. Back end ruby language code should be held > separate from regular "puppet language code" stuff. I'm still not convinced, but I'm open to being convinced :-). Both have 'backend' in this sense surely - however the water is a lot more murky and not so black & white as you might think. Puppet DSL (classes & defines resources) compile on a server, resource types at least run on the server - whereas resource providers are executed on the client. Facts are client side, functions are server side (usually). But the goal is to have a bundle so when its loaded onto the master, client & server side bits are in one place - and the 'client' side bits are distributed correctly. A complete module, might contain some resource types + some classes to help install it. The puppetlabs-opennebula module at least contains components of all kinds: facts, resources, and DSL. These are all needed to support 'opennebula' and while they could be separated - the entire suite is kind of needed for things to function. I don't think functionally it would make sense it breaks this up at all ... I think you can't make clear divisions about the language as to how it gets sliced up either - things get sliced up in the real world on functionality not language type ... take functions for example. These are ruby extensions, but more often then not I'm combining them with a module to provide functionality specific to that module. A fact about the version of opennebula for example - well it belongs next to the Opennebula setup class - because its the consumer surely? > But that doesn't leave me a clear path for how to have my svcprop resource > shared out to others. > > As a suggestion.. if you guys INSIST on overloading the term "module", to > cover both user-level code, and back-end code, then I would recommend you > add an additional, separate subcommand to puppet-module, that generates > back-end templating, instead of the default user-side templating. > Dumping both types of templating as the default, would make things more > confusing to the general-case user. > It's confusing enough (with all the extra junk like "metadata.json" and > "./spec/spec.opts") without making it more so. This is a fair enough feature request - I would presume there are almost 'template styles' that one would want. ie. Generate a templated resource, generate a class, generate a fact or function etc. So that way, you could almost have people defining their own set of templates as well. I often find that would help a customer, when they have finally decided on a preferred template - giving them the capability to keep their own library would be awesome. What do you think? ken. -- 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.
