On Mon, Jul 5, 2010 at 7:11 AM, Thomas Bellman <bell...@nsc.liu.se> wrote:
> On 2010-07-03, Jeff McCune wrote:
>
>> In this module, if you use the following orginization puppet will
>> autoload everything:
>>
>> manifests/init.pp contains class apache { }
>> manifests/disable.pp contains class apache::disable inherits apache {}
>> manifests/virtualhost.pp contains define apache::virtualhost(){}
>
> Yuck! Forcing each class or define into its own file sucks royally.
> No sane person wants their code organized like that.
What I have described is the recommended method of organizing
manifests. This recommendation comes from years of experience of many
in the puppet community, myself included. There is relatively healthy
adoption of this standard within the community.
I'm working from the assumption you're organizing your manifests in
modules. If you're not, I recommend re-factoring into modules for
maintainability and reuse.
There are a number of advantages to adopting this organization standard:
Most important in my opinion; with no other information than the
resource or class name you know where it lives in the file-system. If
you and I both follow the standard and I give you something named
jeff::shirt::red, you know it lives in the jeff module in the
manifests/shirt/red.pp file. Without the standard, I'm forcing you to
spend time and effort hunting for my code. This quickly becomes a
heavy burden at scale with multiple people involved.
Second, puppetdoc works nicely with this standard to create
self-documented manifests.
Third, this standard is common and familiar to those who have used
other high level languages like ruby, python, etc...
Fourth, this is the standard we are recommending for modules posted
publicly to the module forge.
Ultimately, any standard is preferable to no standard.
>> If you want additional namespaces, they go in directories.
>> class apache::service::disable would go in manifests/service/disable.pp
>>
>> I highly recommend against using import today and in the future.
>
> The cure is in this case worse, *much* worse, than the illness of having
> to do explicit imports. I'd rather have two dozen import lines in site.pp
> (which is what I have now) than having to split my classes and defines into
> almost 200 files in two dozen directories.
Why is splitting classes and definitions into discrete files a problem?
--
Jeff McCune
http://www.puppetlabs.com/
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
