Thank you to both of you for your good advice! :) On Thursday, January 2, 2014 9:49:30 AM UTC-8, Ramin K wrote: > > On 1/2/2014 6:47 AM, Jeff Bachtel wrote: > > > > On 01/01/2014 08:38 PM, [email protected] <javascript:> wrote: > >> 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. > >> > > > > 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 > > 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 >
-- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/705d8813-80cd-49df-ae18-f00bdcbe45d9%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
