My apologies on terminology and thank you for the list of best
options. My problem is this, I want to have this os::motd::register
defined type exist in the main class of every module. Yet I don't want
to force a host to have to include os::motd. I want it as an option.
The fact that I don't want to include os::motd on each node means all
three options don't work.
I'm starting to think using the os::motd::register defined type in
every module is not the way to go. Perhaps using exported resources is
a more flexible method of achieving this?
Thanks,
Ryan
On May 3, 7:19 am, jcbollinger <john.bollin...@stjude.org> wrote:
> On May 2, 3:14 pm, Ryan Bowlby <rbowlb...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > Hi All,
>
> > I recently added the puppet-concat module in order to implement the
> > example motd use case. Now our motd includes a list of modules being
> > used on the server, which is awesome.
>
> > All the modules define an motd::register so they expect that the motd
> > module was included. When a node does not include the module all those
> > dependent modules fail. I would like to have each module first check
> > to see if the motd class has been included.
>
> > Current example:
>
> > class pulp (..
> > .....
>
> > # list this module/class in motd
> > os::motd::register {"pulp": }
>
> > }
> > Future example:
>
> > class pulp (..
> > .....
> > if defined(os::motd) {
> > # list this module/class in motd
> > os::motd::register {"pulp": }
> > }
>
> > }
>
> You are confusing me with your terminology. An entity referred to in
> a Puppet manifest as 'os::motd' is either a class or a defined type in
> module 'os', not a module itself. You can "include" or "declare" a
> class, but not a module. You can "instantiate" or sometimes "declare
> [an instance of]" a defined type, or some people "call" one. Your
> manifests cannot directly refer to a module at all, only to its
> contents.
>
> I'm not familiar with the motd module, but os::motd::register must be
> a defined type. It should be the responsibility of the definition to
> include any classes it depends on. It can and should do so unless one
> or more of those classes is parameterized, so that your own classes
> that use it Just Work. If the definition needs a parameterized class
> to have been declared, however, then it thereby leaves you hanging.
>
> > The question is whether this is the right way to go about it? Does the
> > define wait for all class declarations before checking (does order
> > matter)?
>
> No and no (and yes). Parse-order dependency is a prime reason why
> such useage of the 'defined' function is poor practice. There has
> even been some discussion of deprecating it.
>
> If 'os::motd' is an unparameterized class, then your best options are:
> 1) put "include 'os::motd'" at the begining of the body of
> os::motd::register, OR
> 2) put "include 'os::motd'" at the begining of every class that
> instantiates os::motd::register, OR
> 3) put "include 'os::motd'" at the begining of every node definition
> (or make your ENC output that class first in its class list)
>
> If 'os::motd' is a parameterized class then your best bet is to adjust
> your node declarations / ENC so that os::motd is declared first for
> every node.
>
> John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
