How to do "base" setup in a role/profile configuration

[mjus...@gmail.com]

Hi all,

I have a role/profile setup that's working quite well.  However, I'm finding that there are *super* simple things that don't really require the setup of their own module, such as installing "nano" or setting up a yumrepo {}.  Do I really need an MOTD module?  I have a profile::base class which includes things like ::ntp, which because it's a daemon and requires monitoring/service statements, etc. makes sense to keep separate.  But do I really need a yum module when I'm just calling yumrepo{} or package{} that install a few .rpm files?  And for installing general, un-managed packages like bash, nano, etc., surely I shouldn't create a component/module for each of those?  I think that'd be overkill.

I've thought about doing a few things.  Perhaps creating a "general" class that includes subclasses, like so:

include general::yum
include general::motd

Alternatively, inside the puppet "base" profile, I can have the include ::ntp statements, and then also add some package{} and yumrepo{} statements... but not sure if that's anti role/profile.

Any thoughts would be appreciated.  Thank you!

-Matt

[Jeff Bachtel]

According to Craig Dunn's original blog post on the role/profile model,
yes you should be defining modules for motd/yum repos and whatnot. I've
seen that implemented most often under the ::site namespace, but
::general would work as well. And really, it's for the best if no one
working with your code base has to worry about a ::profile class
defining non-class resources directly. And the time overhead of writing
"class site::motd { (blah blah)" is only marginally more than writing it
directly in the profile class.

No one's going to call the Puppet police if you put a yumrepo{} in a
profile class, or create a ::site class that opaquely creates a motd,
sets yumrepo, and installs nano. Eventually you might regret it and
break things out more properly, but "eventually" can be pretty far in
the future. But the level of effort to create a bunch of tiny ::general
classes for piddly stuff is really pretty small, too.

Jeff

> Any thoughts would be appreciated. Thank you!
>
> -Matt

> --
> 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...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/68770970-0fee-4b11-a6d4-8484f3867265%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[mjus...@gmail.com]

Thanks Jeff.  That all makes sense.  One final question: you suggest ::site.  Is that literally a module named site?  Or do you often see ::site replaced with the actual name of the site (IE: dfw01)?  I'd think you'd have a ::site module and then use hiera to define the actual sites and what values should be placed in each class within that module, correct?

Thank you!

[Ramin K]

I nearly lost a keyboard to coffee and "the Puppet police" this morning.
Nice job. :-)

I agree with Jeff that whatever works for you is fine. If it makes the
most sense now, you should write it, push it, and move on to getting
more work done. You may change your mind later and refactor, but that's
a fact of life in any living code base.

However I believe there are some organizational benefits to one module
being the least amount of code. This keeps the module(one use) ->
profile(many modules) -> role(many profiles) relationship intact. It
should also make your code easier to read and reason about.
Simpler modules will keep you from mixing logic between uses. If module
motd is seperate from module yum you're unlikely to create accidental
dependencies. Admittedly I can't think of any way deps could be created
between those two examples.
The other advantage of individual modules is that they are easier to
extend. Your yum module today might be just repos, but tomorrow it might
install assorted yum-* plugins, need to makecache, etc.

Ramin

[Jeff Bachtel]

On 01/02/2014 12:11 PM, mjus...@gmail.com wrote:

Thanks Jeff.  That all makes sense.  One final question: you suggest ::site.  Is that literally a module named site?  Or do you often see ::site replaced with the actual name of the site (IE: dfw01)?  I'd think you'd have a ::site module and then use hiera to define the actual sites and what values should be placed in each class within that module, correct?

Correct, literally a module named site, and correct as well regarding using hiera to customize for different sites/environments. There's probably a better or more descriptive name to use, that's just what I've seen most often. If you like ::general you should roll with it,

Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/58eb76b3-c87a-4fcb-8ce5-3f776bed8f0d%40googlegroups.com.

[mjus...@gmail.com]

Thank you to both of you for your good advice! :)