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!
On Thursday, January 2, 2014 6:47:02 AM UTC-8, Jeff Bachtel wrote:
>
>
> On 01/01/2014 08:38 PM, mjus...@gmail.com <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
>
> > 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 <javascript:>.
> > 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.
>
>
On Thursday, January 2, 2014 6:47:02 AM UTC-8, Jeff Bachtel wrote:
>
>
> On 01/01/2014 08:38 PM, mjus...@gmail.com <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
>
> > 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 <javascript:>.
> > 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.
>
>
On Thursday, January 2, 2014 6:47:02 AM UTC-8, Jeff Bachtel wrote:
>
>
> On 01/01/2014 08:38 PM, mjus...@gmail.com <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
>
> > 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 <javascript:>.
> > 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.
>
>
On Thursday, January 2, 2014 6:47:02 AM UTC-8, Jeff Bachtel wrote:
>
>
> On 01/01/2014 08:38 PM, mjus...@gmail.com <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
>
> > 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 <javascript:>.
> > 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.
>
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/58eb76b3-c87a-4fcb-8ce5-3f776bed8f0d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
