munin service wont' star

[Tim Dunphy]

Hey all,

 I notice with the munin module I wrote, the munin-node service won't start on the first puppet run. Run it a second time, and the service starts no problem.

 The problem here I believe is that puppet is attempting to start the service before the package is installed. 

 So I tried to setup a dependency like this:

class munin::service {

    include munin::install

    service { "munin-node":

    ensure => running,

    require => Package["munin-node"],

   }

}

Using a require statement I tried to ensure that the munin-node package is installed before trying to start the service.

However, I'm getting the following error when I ry to run the module:

Error: Failed to apply catalog: Could not find dependency Package[munin-node] for Service[munin-node] at /etc/puppet/environments/production/modules/munin/manifests/service.pp:8

I was just wondering if I could get some help finding the right formula to get this to work?

Thanks

Tim

--
GPG me!!

gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B

[xav]

On Mon, 2014-03-03 at 21:07 -0500, Tim Dunphy wrote:


>
> Error: Failed to apply catalog: Could not find dependency
> Package[munin-node] for Service[munin-node]
> at /etc/puppet/environments/production/modules/munin/manifests/service.pp:8
>

Looks to me like puppet isn't finding the declaration for
Package['munin-node'] - is that the right package name?

Perhaps you could share the munin::install manifest where I would expect
the package install to be?

[José Luis Ledesma]

Although it is not incorrect, you should not bypass class boundaries, so it's better:

require=>Class['munin::install']

And usually you may include the diferent classes for a module in init.pp chaining them there.

Regards,

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAOZy0enEGm-W1qtaCZfJ7J-6ovMs-uD2oN8fhX-KtGfmTaO%2BKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

[jcbollinger]

On Tuesday, March 4, 2014 1:30:44 AM UTC-6, Jose Luis Ledesma wrote:

Although it is not incorrect, you should not bypass class boundaries, so it's better:

require=>Class['munin::install']

Well, that's one school of thought.  Personally, I don't have any problem with cross-class relationships within the same module, as the OP's appears to be.  In fact, I'd be willing to accept any cross-class relationship at all, provided that the class and module of the relationship target document the target as being declared by the module and available for such use.  (But no one does that.)

 

And usually you may include the diferent classes for a module in init.pp chaining them there.

Yes, that's a common approach, though one should be clear that it's not simply init.pp where the class and relationship declarations reside in that case.  Rather, such declarations would go in a module main class (in this case, Class['munin']) within init.pp.  Also, that class needs to be declared in that case.  Its mere existence is not sufficient.

Anyway, there should be no declarations in any init.pp but outside any class, definition, or node block.  In fact, that applies to almost every manifest anywhere in your manifest set.


John

[Tim Dunphy]

Hey guys,

 I've actually found the problem. It turns out that I thought I had defined the "munin-node" package definition in my install.pp (munin::install) manifest. Turns out I only had defined the "munin" package which takes care of all the dependencies for it.

Here's my main class in init.pp:

class munin {

   include munin::install, munin::config, munin::service

}

And this is my install class (install.pp):

class munin::install {

      package { "munin":

        ensure => present,

      }

}

And I removed the 'include munin::install' definition in the service.pp ( munin::service) module. And because I'm chaining the sub-classes in init.pp it all seems to work just fine.

Thanks for the opinions and commentary. All very valuable!

Cheers!

Tim

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9c5391f9-cca5-4b7c-b33f-f3cb488e305a%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[José Luis Ledesma]

On Tue, Mar 4, 2014 at 3:36 PM, jcbollinger <John.Bo...@stjude.org> wrote:

On Tuesday, March 4, 2014 1:30:44 AM UTC-6, Jose Luis Ledesma wrote:

Although it is not incorrect, you should not bypass class boundaries, so it's better:

require=>Class['munin::install']

Well, that's one school of thought.  Personally, I don't have any problem with cross-class relationships within the same module, as the OP's appears to be.  In fact, I'd be willing to accept any cross-class relationship at all, provided that the class and module of the relationship target document the target as being declared by the module and available for such use.  (But no one does that.)

 

    Perhaps it is, but I found it very useful when in the install class you have to install more than one package, if you set up the require against the install Class you don't have to care anymore about it.

 

And usually you may include the diferent classes for a module in init.pp chaining them there.

Yes, that's a common approach, though one should be clear that it's not simply init.pp where the class and relationship declarations reside in that case.  Rather, such declarations would go in a module main class (in this case, Class['munin']) within init.pp.  Also, that class needs to be declared in that case.  Its mere existence is not sufficient.

Anyway, there should be no declarations in any init.pp but outside any class, definition, or node block.  In fact, that applies to almost every manifest anywhere in your manifest set.


John

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9c5391f9-cca5-4b7c-b33f-f3cb488e305a%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
José Luis Ledesma

[jcbollinger]

On Tuesday, March 4, 2014 9:56:33 AM UTC-6, Jose Luis Ledesma wrote:

On Tue, Mar 4, 2014 at 3:36 PM, jcbollinger <John.Bo...@stjude.org> wrote:

On Tuesday, March 4, 2014 1:30:44 AM UTC-6, Jose Luis Ledesma wrote:

Although it is not incorrect, you should not bypass class boundaries, so it's better:

require=>Class['munin::install']

Well, that's one school of thought.  Personally, I don't have any problem with cross-class relationships within the same module, as the OP's appears to be.  In fact, I'd be willing to accept any cross-class relationship at all, provided that the class and module of the relationship target document the target as being declared by the module and available for such use.  (But no one does that.)

 

    Perhaps it is, but I found it very useful when in the install class you have to install more than one package, if you set up the require against the install Class you don't have to care anymore about it.

 

That's in no way inconsistent with what I said.  The central issues here for me are

1. using an appropriate level of precision in your declarations, and
   
2. public vs. private characteristics of modules.
   

Using an "appropriate" level of precision does not necessarily mean the issuing the narrowest and most precise relationship declarations possible.  You can be too specific, thereby making your manifest set brittle and making its maintenance more costly.  You can also be too general, however, thereby increasing your exposure to relationship cycles and making Puppet work harder to order resources.

How, then, should one find the best balance?  That's where the public vs. private distinction enters the picture.  Puppet DSL does not enforce any encapsulation, but I consider it a best practice to consider undocumented features of a module to be private to that module, whereas documented features are public (unless the documentation specifically says otherwise).  If the module author makes a module feature -- a class, a definition, a declared resource, a variable -- public by documenting it then he is making a commitment to keeping that feature present and consistent with the documentation, and also to document when the feature nevertheless is changed or removed.  Therefore, relying only on public module features minimizes maintenance risk.

Among public features of a module, however, one should choose the most specific relationship targets consistent with the purpose of the relationship.  If one really cares only about a specific Package, say, whose declaration is a public module feature, then that's where one should point their relationship.  If what one really wants, on the other hand, is "all the packages required for Foo to work" then it is probably more appropriate to point your relationship at some class.

The same logic applies inside a module, but although it seems common in the community to take the Puppet class as a subunit of modularity, I think that's mainly another unwarranted holdover from OO-think.  Individual classes in a multi-class Puppet module are rarely independent units in the sense that applies to well-designed classes in an OO programming language.  In Puppet, that level of unity typically applies only to modules.  Thus, within one module I consider all classes and resources fair game for relationships.  That doesn't mean that in any given case it's necessarily a good idea to point a relationship at a resource declared by a different class in the same module, but sometimes that is the best thing to do.  A flat rule against doing so is needlessly restrictive.


John

[José Luis Ledesma]

Well, it is not an unbreakable rule, but from my point referencing individual resources from another class is a source  of possible future problems.

In a simple module like the OP seems to expose, that is:
Params
Config
Install
Service

If you reference individual resources from another class will probably mean:
1. Make it difficult to read/understand for other people
2. Implenting this module for another Linux flavour will be harder (package/service name changes and so on)
3. Modifying it to add some other package/service/configuration will be harder too.

Point 2 and 3 also means possible undesired behaviors.

Just my point of view...

P.n. it is really a pleasure read all of your posts

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/63418eee-604c-468c-a680-65138be280a4%40googlegroups.com.