[Puppet Users] Feedback on module pattern?

Hi Ken,

I'm not sure I fully understood the purpose of each class, and until then
I'm not pointing out issues. But if my interpretation is correct then you
may get something useful from this other pattern:

# it's probaby your mod::defaults and mod::settings together
class mod::params {
   $setting1 = 1
   $setting2 = 'a'
}

# entry point
class mod(
   $setting1 = $mod::params::setting1,
   $setting2 = $mod::params::setting2
) {
   class {'mod::install': } ->
   class {'mod::config':} ~>
   class {'mod::service':} ->
   Class['mod']
}

# the classes below reference parameters
# as $mod::setting1
class mod::install {
}

class mod::config {
}

class mod::service {
}

this can be expanded to more than one entry point.

Hope that helps.

El lunes, 6 de mayo de 2013 12:25:30 UTC-5, Ken Coar escribió:

Hmm. That seems.. confusing.. to me, probably because I'm a
beginning-to-intermediate user. I'm not even sure what the hell is going
on, in fact. :-)

Find a better explanation here:
http://www.devco.net/archives/2012/12/13/simple-puppet-module-structure-redux.php

El martes, 7 de mayo de 2013 10:42:47 UTC-5, Ken Coar escribió:

This looks great.
Some constructive criticism:

I think “defaults" and “settings” are redundant.
Use one.
I kind of like the term “params”, but they all do the same thing.

Hi Ken,

I'm happy to give my $.02, FWIW.

I've found immense benefit from the overall paradigm described in Craig
Dunn's blog post here:
http://www.craigdunn.org/2012/05/239/

That paradigm, combined with modules which have all of their variables
placed as module::variable_name parameters which default to
module::params::variable_name allows for much flexibility:

- easy unit test creation. (avoiding trying to get hiera to work with unit
tests made this incredibly attractive to us)

- clear delineation between 'do-stuff' modules and 'implementation of the
do-stuff module in my environment' profiles.

This makes the 'do-stuff' modules more re-usable and generally communally
consumable, as there are as few as possible environment-specific bits in
the 'do-stuff' modules.

Depending on the environment, this can also serve as a line in the sand as
to which modules can be shared with the world and which contain secret
sauce.


This also has the added benefit of creating tiers of complication.
You can allow your more junior people to orchestrate role modules onto
servers, and provision servers.
You can have your intermediate admins write, or improve profile modules.
A select few can work on your do-stuff modules and help fill out other
needs as they arise.

This, again, is just my $.02. I'm sure there are many others whose opinions
are equally as interesting and may contain more relevant suggestions for
your specific implementation.

I'll check it out in light of your comments. Thanks!

Mine, or Gerardo's?

Some constructive criticism:
Actually, though, IMHO they're not. 'Defaults' are what you get if they
aren't overridden. 'Settings' are what you use in the main code; they
might be the default values, or they might be explicitly overridden/set.

I kind of like the term “params”, but they all do the same thing.
>

'params' *versus* 'settings'.. yah, could go either way. Except I
personally think of 'params' as things that are explicitly passed in to
something, and 'settings' being more in the environment.

Thanks for the feedback!

I think there's a great advantage to using a consistent module structure,
whatever that happens to be. Of course, some structures are more helpful
than others. I'm still trying to wrap my head around the particulars you
present, but I'll see what I can come up with.



Not to be dense, but that class is mod::settings?



And that one is mod::defaults?



And mod::base? Or is this mod?


That resource defaults are so important to you that you make special
provision for them in your standard module structure seems a bit
questionable to me. Given reliance on module-wide resource defaults, I
guess having classes inherit those from a parent class is a decent
approach, but I would advise you to avoid defaults as much as possible in
the first place. If you do so then few, if any, modules should need
classes for resource defaults.

Which, if any, of these classes are parameterized? Not mod::defaults, I
presume, because parameterized base classes are not supported (though they
don't automatically fail). Are any of the others allowed to be
parameterized? This makes a great difference to the analysis.

If class 'mod' is going to declare any other classes of the module, then
those particular classes cannot follow your "all other classes" pattern.
Otherwise, you would have a parse-order dependency loop: mod::other ==> mod
==> mod::base ==> mod::other. If catalog compilation nevertheless
succeeds, you probably will not get the results you expect. I think that
pattern is suitable only for external-facing classes of a "multi-function"
module.

Class mod::base is confusingly named. It undoubtedly makes sense to you,
but to me it strongly suggests a base class for class inheritance. If your
module structure needs to be easy for anyone other than you to grasp, now
or in the foreseeable future, then I recommend choosing a different name.

Or possibly, just dispense with class mod::base altogether. I'm not sure
what the "any other things" that it provides for might tend to be, but I'm
guessing little, if anything. And what there is could be moved to class
'mod' without disturbing your scheme, since mod::base includes mod. That
leaves just

    - inheriting mod::defaults, which does not help other classes because
    they inherit mod::defaults themselves
    - including class 'mod', which is a possible problem in some modules, as
    discussed above
    - including mod::settings, which is not harmful, but also not useful,
    because parent class mod::defaults also includes mod::settings.

Thus, I'd either remove class mod::base, or restructure its pattern. If
you make class mod include mod::base instead of the other way around, then
perhaps mod::base could have a role in keeping the pattern consistent
between single-function and multi-function modules. Even then, however,
I'm not seeing much advantage.

I think it might help to re-cast your pattern categories. In particular,
"all other classes" is probably too broad a category, and class 'mod' may
not deserve to be in a category by itself. It might be to your advantage
to draw the line between outward-facing classes and other classes, instead.


John

D'accord! Hence this attempt.
Correct.

resource declaration defaults into another,
Correct.

and the module top-level namespace and every-class-needs-this stuff into a
A combination. The namespacing is both (since mod::base includes mod), and
the 'common stuff' is mod::base.

I understand. However, there are some significantly involved resource
declarations that only change a few parameters (if any) in other classes --
but to retain the defaults means using 'inherits'. (I first started
messing about with 'inherits' to get the variables from mod::settings
imported into the top -- and each class local -- namespace, but I was shown
some problems there.

In the current iteration, only mod might be parameterised -- and it usually
isn't. Hence all sorts of selectors in mod::settings to derive operating
values from the global scope (node manifest, facts), defaults, and possibly
parameters to mod if they're supported.

Moving from global parameters in the node manifests to parameterised
classes is in the plan.

If class 'mod' is going to declare any other classes of the module, then
I don't do any class-defines-other-classes stuff. I prefer (because I
understand and hence am more comfortable with) one class *per* file.

Good point.

Or possibly, just dispense with class mod::base altogether. I'm not sure
Not exactly; other modules might need settings from module mod. Explicitly
including it or letting it be autoloaded will get the settings without any
side-effect actions being taken.

defaults can be overridden by values determined by mod::settings. That's
the only reason.

Thanks, I'll ruminate on that.

I commend you on that approach, but it's not what I was talking about. To
"declare" a class is to use the 'include' function, the 'require' function,
or a paramterized-style class declaration to assign it to the target node.
This is something you say class 'mod' may do in a single-function module,
but you cannot rely on it to work correctly if the declared (included)
class follows your "all other classes" pattern.



Ok, though that's only relevant to multi-function modules. I do think you
may be overengineering this a bit. My gut feeling is that you have at
least one class too many in your model framework.



So I guessed. I'm not saying mod:defaults should not include
mod::settings, nor either that mod::base should not do so. I am merely
saying that that aspect of mod::base does nothing to help other classes
that themselves inherit from mod::defaults and include mod::base, according
to the pattern you set out. Overall, my point is that mod::base isn't
really doing much for you at all.


Cheers,

John

Considering this area further, I don't think that use is feasible if class
mod is parameterized, as some of yours already are, and as you say more
eventually will be. One module cannot then safely reference class mod
without either assuming that it has already been declared (with correct
parameters) or assuming that it must be declared (in which case the needed
parameters must be provided). Neither assumption is safe in general unless
you put in a lot of work to make it so.

That's more an indictment of the state of parameterized classes in Puppet
2.7 than of your architecture, but you should nevertheless take it into
account as you plan how your modules will be structured.


John