On Dec 15, 10:16 am, Sans <r.santanu....@gmail.com> wrote:
> On Dec 15, 2:08 pm, jcbollinger <john.bollin...@stjude.org> wrote:
>
> > On Dec 14, 4:37 pm, Jo Rhett <jrh...@netconsonance.com> wrote:
>
> > > Try
> > > notify => Service['autofs']
>
> > Right. As far as I know, classes do not forward signals to resources
> > they contain.
>
> Are you absolutely sure about that?
"As far as I know" was meant to convey that no, I am not absolutely
sure.
> My understanding was to use
> something like Class['zmfs::service'] only to avoid running individual
> services separately in that class.
That's understandable, but evidently it doesn't work with resource
signaling. Moreover, it's not obvious to me that that's what you
really want anyway. For instance, do you care in what order the
resources in class zmfs::service get refreshed? If so, then signaling
via the class would not be correct anyway.
> > Furthermore, you should consider whether it would be appropriate to
> > combine your two classes. That a resource belonging to one wants to
> > signal a resource belonging to the other is a hint in that direction
> > (but no more than that). I'm not seeing what you gain by defining
> > such fine-grained classes, especially with the implicit dependencies
> > among them (see next).
>
> Those three code snippets are in three different files, namely
> definition.pp, config.pp and service.pp respectively.
That's entirely beside the point, which is that resources that are
closely related to each other typically belong in the same class.
Consider: would any node ever want to include class zmfs::config but
not class zmfs::service? Would it be correct for a node to include
zmfs::service but not zmfs::config? If the anwer is no to both
questions, then why are these separate classes?
Note that as your manifests now stand, any node that includes
zmfs::config *must* also include zmfs::service, else its catalog will
not compile.
> And there is a
> "config.pp" where
>
> The "line_check" definition gets reused for various files in the
> module.
Very good, no problem with that.
> [re]Starting zmfs is not just enough, it's needs some other
> services to be restarted, "autofs" being one of the most important
> ones. So, what I want is to restart "autofs" as soon as the "/zmfs /
> etc/auto.zmfs" is added to the auto.master file, say for example for
> the very first time. "zmfs" itself still just works without restarting
> (even starting) the "autofs" but it won't be completely usable.
So what you're saying is that "notify => Service['autofs']" is
*exactly* what you want. You don't need to signal the other resources
in class zmfs::service; you only need to signal Service['autofs'].
> So, in
> fact, this is the actual service.pp file:
>
> *******************************************
> class zmfs::service {
> service {
> 'zmfs':
> enable => true,
> ensure => running,
> hasstatus => true,
> hasrestart => true,
> #status => '/etc/zmfs/service_zmfs',
> require => Package['zmfs','zmfs-init-scripts'];
>
> 'autofs':
> enable => true,
> ensure => running,
> hasstatus => true,
> hasrestart => true,
> status => 'service zmfs probe',
> require => Package['zmfs','zmfs-init-scripts'];
> }}
>
> *******************************************
>
> I wrote (at least trying to) this module to use by the several other
> sys-admins, where either "autofs" is already running and in some cases
> the "auto.master" itself is being maintained by another puppet module.
So in that case, putting Service['autofs'] in class zmfs::service is
probably harmful, unless you can be certain that every node that wants
to use autofs also wants to use zmfs, now and forever. Indeed, it is
quite strange that you contemplate managing the autofs service and one
of its configuration files in completely separate modules.
> So, I had to make sure my module must restart autofs after adding the
> appropriate line to the file. but that's not happening.
We understand what you are trying to accomplish, and it's quite
reasonable. Jo suggested a way for you to reach your objective --
notifying the Service instead of the class declaring it -- and the
more you explain, the more that suggestion seems exactly the right
thing to do.
> On the other hand, if I take the 'service autofs' out of the equation
> and use an external script (service_zmfs) with "status"
>
> ****************************************
> #!/usr/bin/perl
> # file: service_zmfs
>
> use strict;
> use warnings;
>
> my @checks = (
> "serviceautofs restart",
> "service zmfs probe",
> );
>
> for my $check ( @checks ) {
> $check .= " 2>&1 > /dev/null"; # suppress output
> system( $check ) == 0 or exit 1;}
>
> *************************************
>
> it works. Still don't fully get it.
What does one have to do with the other? If you prefer to use an
external script then fine, but that has nothing to do with how you
must write your Puppet manifests to achieve a similar result via
Service resources.
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.
