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.
The main potential issue there would be that any parametrized-style
declaration for a given class must be the *first* declaration Puppet parses
for that class. It follows that there can only be one such declaration of
each class (whereas there can be any number of 'include' or 'require'
declarations of a class). There are many implications, among them that if
the module supports users declaring, say, mymodule::installed, then other
classes in the module (mymodule::running, for instance) must not use
parametrized-style declarations of that class. That's a bit of a catch-22,
however, because if the user *doesn't* declare the first class, then other
classes in the module may need to declare it with parameters.
Alternatively, if the example42 modules are truly subclassing (which is not
inherently implied by namespace nesting ala "classname::blah") then the
perception may just be that conditionalizing resource declarations based on
class parameters is preferable to inheriting/overriding resources. There
are valid arguments for that position, but I think the jury is very much
still out.
>
> Like everybody, I'd like to write my module using the best and most
> flexible way so it will be easy to modify and to maintain. I don't like
> to redo my modules from scratch each time :)
>
> So, any inputs/insights are welcome. What direction should I/we take ?
>
It's just too broad a question. I don't think there are very many rules
that would reasonably apply to every module in every context. Here are two
that you should consider adopting, however:
- Declarations of interface classes (those intended to be declared
outside the module) should be performed via the 'include' or 'require'
function, as appropriate, not via the newer parametrized-style class
declaration syntax. Such classes should rely on hiera for any needed
customization data. In Puppet 2.x, that probably means avoiding
parametrizing such classes in the first place.
- Class, definition, and parameter names should be nouns or noun phrases
to emphasize that they describe state, not the actions required to achieve
that state. Good: "apache", "apache::installed", "apache::disabled". Bad:
"tomcat::remove", "perl::update". Exceptions may be made for Exec resources.
>
> I really believe that puppetlabs or a set of gurus should set these
> guidelines so everybody would develop the same way. At the moment, it's
> like "there is more than one way to do it" (perl) but a lot of people
> are after a "this is the best way to do it", to not be confused with
> "there is only way to do it" :)
>
>
That's just not going to happen. That is, Puppetlabs or some group of
gurus might produce such a document, but it would be unlikely to garner
universal support, much less universal compliance. The best I think you
can do is come up with standards for your own organization.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/yCim_UTPeCwJ.
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.
