On Monday, March 14, 2016 at 4:36:18 PM UTC-5, TimV wrote: > > 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, > } > } > >
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. > 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 a few highlights: Me: > 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. Luke: > 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. My own opinion at the time was: > I think it’s a harder problem than you appreciate, and that it’s not just > pathological cases that will prove difficult. > And to bring it back around to the present question, I predicted: > [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. 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)? > 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. > If > 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. 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/f6218eb7-b590-4534-8ff8-82997304795b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
