On May 4, 1:54 am, Dan Carley <dan.car...@gmail.com> wrote:
> On 3 May 2012 23:32, jcbollinger <john.bollin...@stjude.org> wrote:
>
>
>
> > Hmm. I guess I misunderstood your objective. It is still true that
> > 'defined' is not a good approach, however, and also that
> > os::motd::register is a bit rude to not take care of declaring its
> > dependencies itself.
>
> > It might work to declare all your os::motd::register instances
> > virtually, right where they now are, and then collect them at the end
> > of each node definition. I suspect, though, that you would end up
> > with the same problem you already have.
>
> > Generally, I recommend replacing "is foo defined?" conditions with "is
> > foo *supposed to be* defined?". The latter can be evaluated based on
> > global or class variables, or (better) external data.
>
> It's a fine use case for virtual resources. Each class would declare the
> virtual:
>
> class pulp {
> @os::motd::register { $name: }
> ...
> }
>
> Then os::motd would, when included in the catalog, collect/realize
> everything available:
>
> class os::motd {
> Os::Motd::Register <| |>
> ...
> }
Yes, that's similar to what I suggested. I suspect, however, that it
will not solve the OP's problem of wanting to avoid declaring class
os::motd on some nodes, given that os::motd::register depends on that
class having been declared. Under those circumstances, I expect that
even a virtual declaration of os::motd::register will fail if os::motd
is not (already) declared, regardless of whether the virtual resources
are ever collected.
Also, I strongly suspect that collecting os::motd::register instances
in os::motd would not work, because no such instances can have been
declared at the time that the collection declaration is parsed.
That all does suggest another possible approach, though: the situation
would be much improved if os::motd::register's dependency on os::motd
could be removed. Without seeing the code I can only speculate, but
it may be that os::motd could be refactored to make that possible.
For instance, if os::motd::register's need is merely for class
variables from os::motd, then perhaps those can be extracted into a
separate os::motd::params class that os::motd::register would use
instead.
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.
