[Puppet Users] override class attributes

[TimV]

Hi -
I am trying to figure out how to best override
resource attributes for a module. I know this might not
be the best way to do things, but it's where I am at currently.

In summary:

- I have a module called Apache, that references the firewall class from
the puppetlabs/firewall module - to open ports 80/443.
- I have a few nodes, that need wordpress installed (as well as apache)
- I need to override the default fw ports 80/443 being opened, for more
selective rules.

I am trying to override these resources similar to what is described here:
https://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html#overriding-resource-attributes

Here's my code:

nodes.pp
node 'wordpress-dev.blah.example.com' {
include base
include users
include webteam
include apache
include libfw::wordpress
group { 'webteam':
ensure => present,
name => 'webteam',
members => 'sdf, sdf1, sdf3, sdf4'
}
include basicfw
include lib-wordpress
include wordpress_cli
include php
}



Apache and wordpress are two very basic modules I wrote.

apache::config
apache::config has the following:
class apache::config {
firewall { '0050 allow http and https access':
chain => 'LSO-Firewall-1-INPUT',
dport => [80, 443],
proto => tcp,
action => accept,
}
}


Then in the wordpress module, I am trying to override this setting with:

lib-wordpress::config
class lib-wordpress::firewall inherits apache::config {
Class['apache::config'] {
chain => 'LSO-Firewall-1-INPUT',
dport => [80, 443],
proto => tcp,
action => reject,
}
}

Puppet apply run's ok, but IPtables never changes. The default rule 0050,
stays as
accept. 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
(firewall)? If

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.

Thank you.

Tim

[jcbollinger]

Post by TimV
Hi -
I am trying to figure out how to best override
resource attributes for a module. I know this might not
be the best way to do things, but it's where I am at currently.
- I have a module called Apache, that references the firewall class
from the puppetlabs/firewall module - to open ports 80/443.
- I have a few nodes, that need wordpress installed (as well as apache)
- I need to override the default fw ports 80/443 being opened, for
more selective rules.
https://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html#overriding-resource-attributes
nodes.pp
node 'wordpress-dev.blah.example.com' {
include base
include users
include webteam
include apache
include libfw::wordpress
ensure => present,
name => 'webteam',
members => 'sdf, sdf1, sdf3, sdf4'
}
include basicfw
include lib-wordpress
include wordpress_cli
include php
}
Apache and wordpress are two very basic modules I wrote.
apache::config
class apache::config {
chain => 'LSO-Firewall-1-INPUT',
dport => [80, 443],
proto => tcp,
action => accept,
}
}
lib-wordpress::config
class lib-wordpress::firewall inherits apache::config {
Class['apache::config'] {
chain => 'LSO-Firewall-1-INPUT',
dport => [80, 443],
proto => tcp,
action => reject,
}
}

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.

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

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

Post by TimV
It was a mistake to shift toward casting classes as resources, and the
whole community, including PL, will be well served by re-establishment of a
clear distinction.

That trend and practice has since largely been reversed.

Post by TimV
You’re right that it’s basically impossible to escape pathological cases.

He goes on, however, to suggest implementing a scheme that he believed
would work in most cases. As far as I am aware, no such change has ever
been released.

Post by TimV
I think it’s a harder problem than you appreciate, and that it’s not just
pathological cases that will prove difficult.
[T]his is going to continue to be a sore spot as long as the structure of
the language inclines people to believe that it *should* work, all
documentation notwithstanding. Indeed, if the structure of the language
leads people to erroneously believe it should work, then that’s a flaw of
its own in the language design.

It's not now as sore as I then thought it would be, but that's to some
extent because resource overrides through class inheritance have largely
fallen out of favor. Indeed, inasmuch as the whole purpose of class
inheritance was originally to provide for such overrides, class inheritance
itself is now widely frowned upon, except for use of one of its side
effects to implement the Params Class pattern.

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.

Post by TimV
class inherits across module namespaces
Is this because I am overriding a class that references another class
(firewall)?

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.

Post by TimV
If

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.


John

[TimV]

Thank you for the detailed response.

Post by jcbollinger
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.

Post by jcbollinger

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

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

I'll take a look, but I am sure it's over my head.

Post by jcbollinger
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.

Post by TimV
class inherits across module namespaces
Is this because I am overriding a class that references another class
(firewall)?

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.

Post by jcbollinger
If

Post by TimV

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

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
reliably)?

[jcbollinger]

Post by TimV
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.

There's no mixture in that bag. Class parameter overrides do not *ever*
work in the way that you appear to have wanted. Overrides of bona fide
resources, on the other hand, work reliably as long as you satisfy the
constraints involved (those mainly being that you do not have conflicting
overrides).

Post by TimV
Looking forward, I should take advantage of modules that utilize automatic
data binding via hiera, and/or write my modules with this in mind.

Yes. Moreover, it's not hard to find such modules or to implement your
own. You can rely on all PL's modules and most other modules published on
the Forge to be fine in this regard, for sure.

Post by TimV
As it stands currently, what I am trying to do won't work (at least
reliably)?

What you are trying to do will not work the way you are trying to make it
work, and I do not expect that it ever will. You can accomplish the same
objective via various alternative approaches. In my opinion, the most
promising one revolves around automated data binding.


John