FAQ

On Tuesday, May 7, 2013 10:25:05 AM UTC-4, jcbollinger wrote:
I think there's a great advantage to using a consistent module structure,
whatever that happens to be.

D'accord! Hence this attempt.
1. mod::defaults (defaults.pp)
- does *not* inherit from anywhere
- 'include mod::settings'
- references module variables with $mod::settings::varname
2. mod::base (base.pp)
- 'inherits mod::defaults'
- 'include mod'
- 'include mod::settings'
- any other things which apply to all classes in the module
3. mod::settings (settings.pp)
- does *not* inherit from anywhere
- has responsibility for resolving and normalising any global or
mod() class variables into sane values
4. mod (init.pp)
- 'inherits mod::defaults'
- 'include mod::settings'
- imports all $mod::settings::<varname> definitions into the $mod
namespace
- if it's a multi-function module (*i.e.*, classes may be
selectively called out for use), this is all it does.
- if it's a single-purpose module, the rest of its work can go
here -- or in other classes it includes
5. all other classes
1. 'inherits mod::defaults'
2. 'include mod::base'
3. does whatever else it's suppposed to do.

The ideas I'm working from are to abstract all the parameter selectors
and such into one class,

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

resource declaration defaults into another,
And that one is mod::defaults?
Correct.

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

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.
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.

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.
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
those particular classes cannot follow your "all other classes" pattern.
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.

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.
Good point.

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.
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.

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.

mod::defaults includes mod::settings so that aspects of the resource
defaults can be overridden by values determined by mod::settings. That's
the only reason.

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.
Thanks, I'll ruminate on that.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 9 of 12 | next ›
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMay 6, '13 at 5:25p
activeMay 7, '13 at 10:12p
posts12
users5
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase