Thank you for the detailed response.

Side note: class names should not contain hyphens. It may or may not
cause actual breakage in your particular version of Puppet, but I advise
you to change it to an underscore, or to simply remove it.
noted. I'll update the name.

Puppet apply run's ok, but IPtables never changes. The default rule
0050, stays as

Although one of the options for declaring classes has a syntax like that
of a resource declaration, and although Puppet's catalog builder accepts
declarations that purport to override class parameters via the
resource-parameter override syntax, such class parameter overrides are not
useful. I almost wrote "not effective", but that's actually a open to
interpretation. This is the subject of PUP-1367
<https://tickets.puppetlabs.com/browse/PUP-1367>, but you really ought to
read the (extended) discussion associated with the equivalent ticket in
the old bug tracker <http://projects.puppetlabs.com/issues/5517>. There
is a lot of good information there, but I draw your attention specifically
the exchange between Luke Kanies and myself, starting at comment #35. Here
are a few highlights:
I'll take a look, but I am sure it's over my head.

Since its introduction in Puppet 3.0, automatic data binding (via Hiera)
has been the best mechanism for assigning non-default values to the
parameters of any and every module's public classes. Relying on data
binding solves several kinds of problems, including yours. In fact, yours
is the bread & butter use case for data binding; I'm more used to arguing
others of its merits. If your manifest set is not built with automated
data binding in mind, however, then it might require an uncomfortable
amount of reorganization to take advantage of it.

I also noticed with puppet-lint this warning:
class inherits across module namespaces

Is this because I am overriding a class that references another class

It is because a class belonging to one module (lib-wordpress) inherits
from a class belonging to a different module (apache). This is allowed,
but it is widely considered poor form, because it creates an
inappropriately strong coupling between the modules involved. If you use
data binding effectively then you do not need to do this sort of thing.

Strongly coupled modules are bad. I understand this.

so, how should I avoid this? I might be running up against this bug:
Note: If a base class declares other classes with the resource-like
syntax, a class derived from it cannot override the class parameters of
those inner classes. This is a known bug.
Yes, that seems to be describing PUP-1367, but it's a bit off. In the
first place, the problem has nothing directly to do with the syntax used by
the parent class to declare the class whose parameters you hope to be able
to override. Use of the resource-like syntax simply tends to give the
impression that an override should work. In fact, at least in some Puppet
versions, it *does* work, in the sense that from Puppet's perspective,
the parameter values indeed are changed. The root of the problem, however,
is that such changes take effect too late to make any practical difference
in the catalog that is produced. That's why I was careful to say at the
beginning that such overrides are "not useful".

In the second place, the summary gives the impression that the bug is in
the fact that the parameter overrides do not have the desired effect. This
is by no means settled, and that may be why the issue is still open. I'm
inclined to say (and *did* say among my comments on the issue) that the
bug is that the existence of resource-like class declaration syntax
promotes the false expectation that overrides will have an observable
effect on the catalog, and in the fact that the catalog builder accepts the
declarations without even a warning.

Again, thanks for the reply. If I understand you correctly, trying to
accomplish an override such as I've setup, is a mixed bag - it might work,
but it's generally not the correct way to do things.
Looking forward, I should take advantage of modules that utilize automatic
data binding via hiera, and/or write my modules with this in mind.

As it stands currently, what I am trying to do won't work (at least

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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/a24187c3-4d1a-406b-8647-df5ede4891a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 4 | next ›
Discussion Overview
grouppuppet-users @
postedMar 14, '16 at 9:36p
activeMar 16, '16 at 1:13p

2 users in discussion

Jcbollinger: 2 posts TimV: 2 posts



site design / logo © 2022 Grokbase