On Aug 25, 2:52 pm, Ricardo Bartolome Mendez <rica...@tuenti.com>
wrote:
> Hello guys,
>
> I use stages for defining a kind of order about how the things are done in
> my automations. I’ve defined four different stages: boot, os, service and
> online. We also have Main stage. The issue I found today may be derived from
> a incorrect usage of class inheritance, or run stages. Let me show you an
> example:
>
> We use rsyslog for both systems logging and application logging. So,
> depending of the facilities and so on, we transport operating systems logs
> to a syslog receiver, or stats to a data analysis cluster. So, given that is
> the same piece of software I decided to create a module called “rsyslog” and
> inside init.pp describe all the necessary stuff for having the operating
> systems syslog configured, what is a must in any of my nodes. I also defined
> inside stats.pp a new class named “rsyslog::stats” that inherits rsyslog.
It's not clear that this is a good use case for class inheritance.
Does Class['rsyslog::stats'] override the properties of any resources
inherited from Class['rsyslog']? From your description, it's not
obvious that it would need to do. If indeed it doesn't, then you are
using inheritance where you should instead be aggregating (more on
that below).
> So, then, in my node class named “frontend” where I need both configurations
> I define the rsyslog class it in this way:
>
> include stages
>
> class { ‘rsyslog::stats’: stage => ‘os’ }
>
> But today I found (using debug option) that the things explicitly defined in
> “rsyslog::stats” are done in the stage “os”, but the things defined in the
> class “rsyslog” are done in Main [1]. What I expect? I expect that given
> that “rsyslog::stats” was defined in the Stage “os”, the inherited one, too.
I would not have anticipated that result either, but in hindsight I
don't find it altogether surprising. That doesn't mean you shouldn't
file a ticket about it, though. Or it wouldn't, but it looks like
there are already at least three separate tickets describing this
issue (5349, 6019, 7533).
An important question arises at this point: is this something you
actually need to fix? I mean, was anything actually breaking? If
not, then you should consider just ignoring the issue.
> I’ve fixed this by defining the class in the node like:
>
> include stages
>
> class { ‘rsyslog’: stage => ‘os’ }
>
> class { ‘rsyslog::stats’: stage => ‘os’ }
>
> But this means repeating lines and it’s quite ugly.
I think that's your best alternative at the moment. Also, although
the need to do that is a bit surprising, it makes a certain amount of
sense if you look at it from the right angle. For one thing, it's
valid to do that in the first place. For another, it is possible to
do that and specify different stages for base- and subclass. For a
third, consider what would happen if you wanted to put two different
subclasses of the same class into different stages.
Moreover, if the stats collection is in addition to rsyslog reporting,
as opposed to being a modified form of the same, then I think the form
you found is what you should have been doing all along. In that case,
the fact that stats collection relies on rsyslog is better modeled via
an ordinary relationship than via class inheritance. That might even
allow you to make some of Class['rsyslog:stats'] implementation a
little cleaner, depending on what resource-level relationships you may
have declared.
> I don’t know if that’s
> the proper way of doing what I’m doing. I’m using class inheritance because
> there are servers that are running rsyslog for systems logs, but they don’t
> need the stats configuration (a database server, for example), so including
> just “rsyslog” class and defining its run stage should be enough.
I agree that it's good form for your Class['rsyslog'] to not contain
the stats stuff itself. I'm still doubtful, however, that it's
appropriate to make Class['rsyslog::stats'] a subclass. As a bonus,
if you make it a top-level class then maybe you won't be so
dissatisfied about declaring both classes in your node class.
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.
