On 10/22/2012 06:17 PM, jcbollinger wrote:
>
>
> On Monday, October 22, 2012 2:33:18 AM UTC-5, Thomas Guthmann wrote:
>
> Hi,
>
> My dilemma is how should I write my module to be "next-gen" ?
> Not from a code point of view but from a design/layout point of view.
>
>
>
> I don't think much has changed in that area in a long time. Styles have
> come and gone, but the only new thing I can think of since 0.24 that had
> much impact on the fundamental questions is hiera.
>
>
>
>
> We wrote our modules for 2.6.x like every beginner would have done:
> write everything in init.pp.
>
> But now, the fashion is to use parameterized classes and Hiera which we
> will use with puppet 2.7.x.
>
>
>
> It would be wise to make your decisions based on an evaluation of
> technical merit, not based on what happens to be fashionable in some
> segment of the Internet at the moment. And naturally, you should be
> wary of taking advice from random people on the 'net. (Except me -- I'm
> TOTALLY reliable. :-))
>
>
>
>
> I mainly followed/watched what Example42 was doing. They were using
> $classname::{install|remove|disable|blah} to actually call an action in
> their old modules. It was almost a sub class ($subclass.pp) per action.
> It was easy to read and possibly to maintain.
>
>
>
> I am all for modular code (including inside Puppet 'modules'), but what
> I think you're asking about here is not so much module implementation,
> but rather modules' interfaces to the rest of Puppet. Thus I take it as
> a question about whether to convey information about the desired
> configuration details via class names or data (parameters or external
> data). The two approaches provide different advantages.
>
> Controlling everything via data (meaning either / both class parameters
> and external data) can make your main manifests very simple, and / or it
> may have advantages for the design of complementary ENCs. On the other
> hand, putting information into class names can enable class dependencies
> to depend on that information. For example: "Class['tomcat::running']
> -> Class['mywebapp::running']". As you say, using class names in that
> way also can make manifests clearer to human readers.
>
>
>
>
> But now Alessandro from Example42 seems to put everything back in
> init.pp with his nextgen modules...
>
> I like the idea of segregating types or action per files to avoid
> mistakes during edits but at the same time I am wondering why this
> change for example42, is it a limitation for parameterized classes ?
>
>
>
> I cannot speak for Example42, but if you've been following this group
> you will know by now that my technical opinion of parametrized classes
> is that you should not write them, and as much as possible you should
> avoid using them (unless via the 'include' or 'require' function). I
> have not studied the Example42 modules, but it is conceivable that some
> of the technical limitations of parametrized classes influenced the
> decision to move to unitary interfaces.
IMHO it's OK to write them as long as you don't declare them as
resources. Benefits:
- backwards compatible
- no direct hiera calls in classes
- "class::params" has all the defaults
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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.
