Puppet users - Jun 2012 - Restart service on ensure running ; class dependecies

Hi all,

May i get your opinion on the following two subjects?

First, for services that have ensure=>runnig and for which "service
bla status" returns not running, can puppet be convinced to call
"service bla restart" instead of "service bla start"?

Second question, about class dependencies. I have a class called
network, with a subclass networ::device, which I use to deploy the
ifcfg-* files. So, for a node, i will have an undefined number of
network::device objects. Furthermore, I have a class called
network::ipconfig2. How can I make sure that network::ipconfig2 will
be applied only after all the network::devices are applied?

Thanks.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jun 6, 2012, at 10:33 AM, Andrei-Florian Staicu
wrote:
> First, for services that have ensure=>runnig and for which "service
> bla status" returns not running, can puppet be convinced to call
> "service bla restart" instead of "service bla start"?
Would be easier to change the command used to check and see if it is running for
those processes.
> Second question, about class dependencies. I have a class called
> network, with a subclass networ::device, which I use to deploy the
> ifcfg-* files. So, for a node, i will have an undefined number of
> network::device objects. Furthermore, I have a class called
> network::ipconfig2. How can I make sure that network::ipconfig2 will
> be applied only after all the network::devices are applied?
require => Class[''network::device''] ?

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.



-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jun 6, 12:33 pm, Andrei-Florian Staicu <andrei.sta...@gmail.com>
wrote:
> First, for services that have ensure=>runnig and for which "service
> bla status" returns not running, can puppet be convinced to call
> "service bla restart" instead of "service bla start"?

That''s a very odd request.  If the service is indeed not running, then
"service bla start" is the correct way to set it running.  If
"service
bla status" is returning an incorrect result -- that is, if it
sometimes says the service is not running when actually it is -- then
fixing that would be an all-around better solution (i.e. not just for
interoperation with Puppet).  If you cannot or will not fix the
initscript, then you can use the Service''s ''status''
parameter to
provide an alternative command by which to determine whether the
service is running.

> Second question, about class dependencies. I have a class called
> network, with a subclass networ::device, which I use to deploy the
> ifcfg-* files. So, for a node, i will have an undefined number of
> network::device objects.

No, you don''t.  Perhaps you have a *defined type* network::device, but
if that were a class then each node would have it either once or not
at all.  It is important to know the difference because it affects
several aspects of how you design and write your manifests.

> Furthermore, I have a class called
> network::ipconfig2. How can I make sure that network::ipconfig2 will
> be applied only after all the network::devices are applied?

This is what resource relationships are for.  A good use in this case
would be for each declaration of a network::device instance to specify
a ''before'' parameter.  For example,

network::device { ''eth0'':
  # ...
  before => Class[''network::ipconfig2'']
}

That will do the job correctly no matter how many network::device
instances are declared (including zero), and it does not require class
network::iproute2 to know which network::device resources have been or
will be declared.  It does, however, require that
Class[''network::ipconfig2''] be already declared at the point
where the
Network::Device instance is declared (and there are several ways to
ensure that).


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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jun 7, 2012 at 4:03 PM, jcbollinger <John.Bollinger@stjude.org>
wrote:
>
>
> On Jun 6, 12:33 pm, Andrei-Florian Staicu <andrei.sta...@gmail.com>
> wrote:
>> First, for services that have ensure=>runnig and for which
"service
>> bla status" returns not running, can puppet be convinced to call
>> "service bla restart" instead of "service bla
start"?
>
>
> That''s a very odd request.  If the service is indeed not running,
then
> "service bla start" is the correct way to set it running.  If
"service
> bla status" is returning an incorrect result -- that is, if it
> sometimes says the service is not running when actually it is -- then
> fixing that would be an all-around better solution (i.e. not just for
> interoperation with Puppet).  If you cannot or will not fix the
> initscript, then you can use the Service''s
''status'' parameter to
> provide an alternative command by which to determine whether the
> service is running.
I took your advice an rebuilt the script. Thanks.
>
>
>> Second question, about class dependencies. I have a class called
>> network, with a subclass networ::device, which I use to deploy the
>> ifcfg-* files. So, for a node, i will have an undefined number of
>> network::device objects.
>
>
> No, you don''t.  Perhaps you have a *defined type* network::device,
but
> if that were a class then each node would have it either once or not
> at all.  It is important to know the difference because it affects
> several aspects of how you design and write your manifests.
>
Yes, I still have to do some heavy reading about puppet
classes/types/resources/modules a.s.o. It''s a lot to take in all at
once.
>
>> Furthermore, I have a class called
>> network::ipconfig2. How can I make sure that network::ipconfig2 will
>> be applied only after all the network::devices are applied?
>
>
> This is what resource relationships are for.  A good use in this case
> would be for each declaration of a network::device instance to specify
> a ''before'' parameter.  For example,
>
> network::device { ''eth0'':
>  # ...
>  before => Class[''network::ipconfig2'']
> }
>
> That will do the job correctly no matter how many network::device
> instances are declared (including zero), and it does not require class
> network::iproute2 to know which network::device resources have been or
> will be declared.  It does, however, require that
> Class[''network::ipconfig2''] be already declared at the
point where the
> Network::Device instance is declared (and there are several ways to
> ensure that).
>
Yes, but some nodes include network::ipconfig2, others do not. That
means that I can''t put the "before" in the network::device
class
definition; instead I''ll have to add it to each instance. And one of
the purposes is to keep the manifests as small as possible, to keep
them readable.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jun 7, 8:45 am, Andrei-Florian Staicu <andrei.sta...@gmail.com>
wrote:
> On Thu, Jun 7, 2012 at 4:03 PM, jcbollinger
<John.Bollin...@stjude.org> wrote:
[...]
> > This is what resource relationships are for.  A good use in this case
> > would be for each declaration of a network::device instance to specify
> > a ''before'' parameter.  For example,
>
> > network::device { ''eth0'':
> >  # ...
> >  before => Class[''network::ipconfig2'']
> > }
>
> > That will do the job correctly no matter how many network::device
> > instances are declared (including zero), and it does not require class
> > network::iproute2 to know which network::device resources have been or
> > will be declared.  It does, however, require that
> > Class[''network::ipconfig2''] be already declared at
the point where the
> > Network::Device instance is declared (and there are several ways to
> > ensure that).
>
> Yes, but some nodes include network::ipconfig2, others do not. That
> means that I can''t put the "before" in the
network::device class
> definition; instead I''ll have to add it to each instance. And one
of
> the purposes is to keep the manifests as small as possible, to keep
> them readable.

The example I presented doesn''t put it in the network::ipconfig2
definition, it puts it in instance declarations (only one provided),
EXACTLY to support the possibility that network::ipconfig2 is not used
(in which case you would omit the ''before'' parameter, or
assign the
value undef).  The ''before'' is a Puppet metaparameter, so
every
resource type provides it automatically; you would not need to write
code for it in your definition.

Nevertheless, it might be more convenient for you to use a collection
and resource chaining to express these relationships.  The syntax
looks like this:

  Network::Device<| |> -> Class[''network::ipconfig2'']

You would want Puppet to parse that only after all wanted
network::device instances and the ''network::upconfig2'' class
had been
declared (and thus only if class ''network::upconfig2'' was
being
declared in the first place).  Note that that will have the side
effect of realizing any virtual network::device instances you may have
declared.  For example,

class network {

  # ... declare all network::device instances ...

  if $::ipconfig2_wanted {
    include ''network::ipconfig2''
    Network::Device<| |> ->
Class[''network::ipconfig2'']
  }
}


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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi,

On 06/08/2012 03:03 PM, jcbollinger wrote:
> The ''before'' is a Puppet metaparameter, so every
> resource type provides it automatically; you would not need to write
> code for it in your definition.
sadly, this is only half true.

Yes, you can specify before, requires etc. to all instances of your
defined types. However, without extra code, it will do *nothing* (aside
from confusing you each single time you look at it ;-)

See
http://docs.puppetlabs.com/guides/language_guide.html#resource-collections.

"""
Any metaparameters used when a defined resource is declared are also
made available in the definition as variables:
[...]
The above is perhaps not a perfect example, as most likely we would know
that subversion was always required for svn checkouts, but it
illustrates how require and other metaparameters can be used in defined
types.
"""

They won''t propagate to resources inside your defined type the way
requiring a class propagates the requirement to each resource inside the
class. You''ve got to put this into code.

Regards,
Felix

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jun 8, 8:10 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:
> Hi,
>
> On 06/08/2012 03:03 PM, jcbollinger wrote:
>
> > The ''before'' is a Puppet metaparameter, so every
> > resource type provides it automatically; you would not need to write
> > code for it in your definition.
>
> sadly, this is only half true.
>
> Yes, you can specify before, requires etc. to all instances of your
> defined types. However, without extra code, it will do *nothing* (aside
> from confusing you each single time you look at it ;-)
[...]
> They won''t propagate to resources inside your defined type the way
> requiring a class propagates the requirement to each resource inside the
> class. You''ve got to put this into code.

Good catch, Felix, thanks.


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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.